Fix z.ai overview submenu recursion

[RajvardhanPatil07]

Summary

• Keep overview rows with detail submenus on the passive submenu action path.
• Add z.ai regression coverage that ensures submenu activation does not switch into provider detail.
• Keep existing provider-selection coverage on a plain overview row fixture.

Why

Hovering the z.ai overview row could open a nested full menu because the row had both a detail submenu and a provider-selection action. Rows with submenus should let hover open only the detail submenu; plain rows still keep the selection action.

Fixes #1246.

Reviewer validation

A contributor reviewed and tested this locally on macOS with Swift 6.3.2 / Xcode 26.5.

This PR passed:

PASS overview row submenu action does not switch provider detail (0.092s)
PASS selecting overview row switches to provider detail (0.119s)
PASS Test run with 4 tests in 1 suite (0.594s)

Base check, with only the source fix reverted while keeping the new test, failed as expected:

FAIL mergedMenuLastSelectedWasOverview became false
FAIL selectedMenuProvider became .zai instead of staying .claude
FAIL overviewRow-zai disappeared after the rebuild

Restoring the fix made the test green again. The test performs the row action on a z.ai overview row with a confirmed non-nil submenu, so it covers the path that previously rebuilt the menu mid-interaction. The reviewer also reported SwiftFormat and SwiftLint clean on the three changed files.

Unrelated note from local validation: closed attached menu preparation waits for store refresh to finish failed under a parallel run but passed in isolation; that test is not touched by this PR and appears to be a pre-existing timing flake.

Validation

• git diff --check
• .build/lint-tools/bin/swiftformat Sources Tests --lint
• GitHub CI passed: macOS lint/build/test, Linux x64 build, Linux arm64 build, and security.
• swift test --filter StatusMenuTests/selecting_overview_row_switches_to_provider_detail was blocked locally before project code compiled: the Command Line Tools install cannot load PreviewsMacros for the KeyboardShortcuts dependency #Preview declarations.
• make check ran SwiftFormat successfully, then was blocked when portable SwiftLint trapped loading sourcekitdInProc.framework under the local Command Line Tools install.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed June 5, 2026, 12:48 AM ET / 04:48 UTC.

Summary
This PR stops overview rows with detail submenus from overriding the submenu no-op action, adds z.ai regression coverage for submenu activation staying in overview, and updates the provider-selection test to use a plain overview row.

Reproducibility: yes. Source inspection and the reported red/green focused test path show current main can put z.ai overview rows in a state with both a detail submenu and a provider-selection action, though I did not run a live app hover reproduction.

Review metrics: 2 noteworthy metrics.

• Files changed: 1 source file, 2 test files. The behavioral surface is small, but it sits in menu interaction code where selector changes affect mouse, keyboard, and accessibility paths.
• Real app proof artifacts: 0 screenshots, recordings, or packaged-app logs. The PR has useful red/green test output, but the visible hover regression still needs real behavior proof before merge.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add redacted real app proof showing z.ai hover opens only the intended detail submenu and does not open a nested full menu.
• [P1] Call out whether submenu-backed overview rows are intended to be submenu-only on keyboard/accessibility activation, or add a preserved explicit activation path if not.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body and later comment provide red/green Swift test output, but no real packaged-app screenshot, recording, runtime log, or desktop proof showing the z.ai hover/submenu behavior after the fix. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Mantis proof suggestion
A short desktop proof would materially verify the visible z.ai overview hover/submenu behavior that unit tests cannot fully show. A maintainer can ask Mantis to capture proof by posting a new PR comment that starts with the OpenClaw Mantis account mention, followed by:

visual task: verify the z.ai overview row opens only its MCP/detail submenu on hover and does not open a nested full menu.

Risk before merge

• [P1] Real packaged-app proof is still missing for the visible z.ai hover/submenu behavior; the current evidence is source inspection, CI, and focused test output.
• [P1] The selector change leaves submenu-backed overview rows on menuCardNoOp; if maintainers still expect keyboard or accessibility activation to switch to provider detail, that contract needs an explicit alternative or acceptance before merge.

Maintainer options:

1. Add visible menu proof before merge (recommended)
   Require a short packaged-app recording, screenshot sequence, or desktop proof showing z.ai hover opens only the MCP/detail submenu and does not select z.ai or spawn a nested full menu.
2. Preserve activation if required
   If keyboard or accessibility activation of submenu-backed overview rows must still switch provider detail, adjust the patch to provide that explicit path and cover it with focused tests.
3. Accept submenu-only rows
   Maintainers can accept that overview rows with detail submenus are submenu-only on item activation because that matches the existing makeMenuCardItem submenu no-op behavior.

Next step before merge

• [P1] This needs contributor real behavior proof plus maintainer acceptance of the submenu-backed row activation contract, not an automated repair PR.

Security
Cleared: The diff only changes Swift menu behavior and focused tests; it does not touch secrets, dependency resolution, CI, release scripts, or other supply-chain surfaces.

Review details

Best possible solution:

Land the narrow guard after a redacted real app proof shows the z.ai overview row opens only its detail submenu, with maintainers explicitly accepting or preserving the submenu-row activation contract.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection and the reported red/green focused test path show current main can put z.ai overview rows in a state with both a detail submenu and a provider-selection action, though I did not run a live app hover reproduction.

Is this the best way to solve the issue?

Mostly yes. The source patch is narrow and matches the existing submenu no-op helper, but merge should wait for real app proof and maintainer acceptance of the submenu-row activation contract.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 65e39f4dcb3a.

Label changes

Label justifications:

• P2: This is a normal-priority user-visible menu bug fix with limited provider/UI blast radius and no evidence of data loss, security impact, or app-wide outage.
• merge-risk: 🚨 compatibility: The patch changes activation behavior for overview rows that have detail submenus, which can affect existing keyboard or accessibility workflows unless maintainers accept that contract.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body and later comment provide red/green Swift test output, but no real packaged-app screenshot, recording, runtime log, or desktop proof showing the z.ai hover/submenu behavior after the fix. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its guidance on focused menu-state tests, avoiding keychain/live provider prompts, and validating UI/runtime behavior when needed applies to this menu behavior PR. (AGENTS.md:1, 65e39f4dcb3a)
• Current main has the conflicting selector path: Current main creates overview rows with a possible detail submenu and then unconditionally assigns selectOverviewProvider, which is the source-level path behind the reported z.ai hover recursion. (Sources/CodexBar/StatusItemController+Menu.swift:548, 65e39f4dcb3a)
• Submenu-backed menu cards use a no-op selector: makeMenuCardItem assigns menuCardNoOp when a submenu exists, so the PR's guard leaves submenu-backed overview rows on the existing passive submenu action path. (Sources/CodexBar/StatusItemController+MenuCardItems.swift:65, 65e39f4dcb3a)
• z.ai overview rows can expose detail submenus: makeOverviewRowSubmenu returns the z.ai usage details submenu when z.ai has time-limit usage details, matching the reported provider and the new regression fixture. (Sources/CodexBar/StatusItemController+OverviewSubmenus.swift:15, 65e39f4dcb3a)
• PR diff keeps submenu rows on the passive path: The patch only wires selectOverviewProvider when submenu == nil, while plain overview rows keep the keyboard/accessibility selector path. (Sources/CodexBar/StatusItemController+Menu.swift:562, 24e34dba0310)
• Regression coverage added: The new test builds a z.ai overview row with a non-nil submenu, performs its action, and expects the menu to remain in overview with the previous selected provider unchanged. (Tests/CodexBarTests/StatusMenuOverviewSubmenuTests.swift:65, 24e34dba0310)

Likely related people:

• steipete: Current blame maps the overview-row builder, z.ai submenu path, and unconditional overview-row selector wiring to this author in the available main history. (role: introduced/current menu behavior; confidence: high; commits: 723734ef3422; files: Sources/CodexBar/StatusItemController+Menu.swift, Sources/CodexBar/StatusItemController+OverviewSubmenus.swift)
• hhh2210: Recent merged work on menu-card height caching and merged-menu latency owns the current makeMenuCardItem helper lines that assign no-op actions for submenu-backed menu cards. (role: recent adjacent menu contributor; confidence: medium; commits: 65e39f4dcb3a; files: Sources/CodexBar/StatusItemController+MenuCardItems.swift, Sources/CodexBar/StatusItemController+Menu.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[devYRPauli]

Reviewed and tested this locally on macOS (Swift 6.3.2 / Xcode 26.5). Fix looks correct, and since CI here wants real-behavior proof, here it is.

Root cause is as described: addOverviewRows unconditionally set item.action = #selector(selectOverviewProvider(_:)), overwriting the no-op action makeMenuCardItem already wires up for rows that have a submenu. So activating a z.ai row (which always gets a submenu) fired selectOverviewProvider, flipped mergedMenuLastSelectedWasOverview and the selected provider, and rebuilt the menu mid-interaction. Gating it behind if submenu == nil is the right minimal fix and matches how makeMenuCardItem already handles the submenu case.

GREEN on this PR:

✔ "overview row submenu action does not switch provider detail" passed (0.092s)
✔ "selecting overview row switches to provider detail" passed (0.119s)
✔ Test run with 4 tests in 1 suite passed (0.594s)

RED on base (reverted only the source-fix hunk, kept the new test):

✘ mergedMenuLastSelectedWasOverview → false
✘ (selectedMenuProvider → .zai) == .claude
✘ menu.items.contains { ... }   // overviewRow-zai gone after the rebuild

Restoring the fix makes it green again. The test drives target.perform(action, with: zaiRow) on a row with a confirmed non-nil submenu, so it hits the real path. swiftformat --lint and swiftlint are both clean on the three changed files.

One unrelated note: closed attached menu preparation waits for store refresh to finish (StatusMenuOpenRefreshTests) failed under the parallel run but passes in isolation. It is not touched by this PR (last changed in #1277) and looks like a pre-existing timing flake, not a regression here.

LGTM.

[RajvardhanPatil07]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26995832069
• Updated: 2026-06-05T04:48:21.080Z