fix(claude): honor segmented account menu layout

[steipete]

Claude-swap ignored Menu → Multi-account layout and always rendered stacked/compact cards. Honor Segmented with stable account buttons and one source-owned detail card, reusing the existing serialized activation path.

Keep the active marker tied to adapter output. Unavailable accounts remain inspectable without activation; pending and failed switches retain the requested account’s usage and diagnostics. Use stable slot labels with Hide Personal Info. Closing inspection invalidates the cached menu so a fresh persistent menu returns to the active card on reopen without another fetch. With no active or explicitly selected account, show the no-active notice without falling back to ambient usage. Stacked/compact menus and CLI cards keep their existing behavior.

Fixes #3382. Thanks @thatlev for the report and acceptance criteria. Release notes are in #3499, to land after the code PRs.

Validation: make check passed; make test passed all 1,036 selections in 87 groups on the final head with no retries, failures, or timeouts. The persistent-menu regression failed before repair for both provider and merged menus, then passed. The architecture guard remains unchanged apart from four exact-line offsets. Independent branch review is clean through P2.

Developer ID-signed native proof exercised successful/failed switching, retained usage, privacy labels, sentinel inspection, merged menus, four-account wrapping, and no-active behavior. Reusing the same menu across inspection and reopen restored the active card with no change to provider revision or adapter invocation count. The built CLI continued to render every synthetic account, including the expired slot. All proof uses synthetic data and a fake cswap executable.

Existing stacked rendering (preserved)	Segmented rendering

Inspect an unavailable account	Reopen the same menu, without a fetch

No active account: no ambient quota card.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed September 8, 2026, 4:21 AM ET / 08:21 UTC.

ClawSweeper review

What this changes

Makes Claude-swap honor the existing segmented account layout, with stable account buttons, one account’s details, and unavailable-account inspection.

Merge readiness

✅ Ready for maintainer review

This remains a useful, focused fix: current main and v0.56.8 still omit segmented Claude-swap presentation. The earlier cache-invalidation finding is resolved, and no remaining blocking defect was found.

Priority: P2
Reviewed head: 8cbffc5c97bc4b9ee8705c68fa8a340b6961f9f5

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused patch with relevant native visual evidence, regression coverage, and the earlier finding resolved.
Proof confidence	🐚 platinum hermit (4/6) ✨ media proof bonus	Sufficient (screenshot): The inspected native screenshots directly show the changed Claude menu’s segmented rendering, sentinel inspection, and restored active card on reopen; the captured body describes the synthetic cswap setup and broader switching checks.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The inspected native screenshots directly show the changed Claude menu’s segmented rendering, sentinel inspection, and restored active card on reopen; the captured body describes the synthetic cswap setup and broader switching checks.
Evidence reviewed	9 items	Current main still needs the fix: At the fetched main revision, addClaudeSwapMenuCards chooses only stacked or compact rendering and does not consult multiAccountMenuLayout. Release comparison: Inspection of the same file at v0.56.8 also showed only stacked/compact rendering; the requested presentation is not supplied by that release. Introduced change and preference compatibility: The pinned merge-base-to-head diff contains nine files. It reads the existing preference without changing its default, persistence, or migration; the stacked branch remains intact. Production grows by 236 lines and tests by 188 net lines.
Findings	None	None.
Security	None	None.

How this fits together

CodexBar’s Claude menu displays account usage supplied by the optional claude-swap executable. The layout preference controls presentation, while explicit account selections reuse the existing serialized switching path.

flowchart TD
  A[Claude account snapshots] --> C[Account menu presentation]
  B[Saved layout preference] --> C
  C --> D[Stacked account cards]
  C --> E[Segmented buttons and details]
  E --> F[Inspect unavailable account]
  E --> G[Existing serialized account switch]
  G --> A

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production and test growth	production +236; tests +188 net	Growth implements the missing presentation path and focused state/menu regressions without changing the activation backend.

Root-cause cluster

Relationship: fixed_by_candidate
Canonical: #3382
Summary: This PR is the implementation candidate for the reported Claude segmented-layout gap; release-note collection is separate.

Members:

• canonical: Apply segmented multi-account layout to claude-swap and provider account sources #3382 - Defines the missing behavior and explicitly accepts a focused Claude-first implementation.
• adjacent_distinct: docs(changelog): collect Claude menu and Bedrock disclosure fixes #3499 - Collects release notes after the code changes and does not implement the menu fix.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Technical review

Best possible solution:

Honor the saved layout through this focused Claude presentation path while retaining source-owned identity, existing activation guards, and stacked and CLI behavior.

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

Yes, from source: with multiple Claude-swap accounts, current main bypasses segmented presentation regardless of the saved layout preference. No live reproduction was executed in this review.

Is this the best way to solve the issue?

Yes. The branch fills the missing Claude presentation path while reusing stable identities, the existing switching backend, and established menu-rebuild mechanics.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against b1e27d266a8e.

Labels

Label justifications:

• P2: Repairs an existing layout preference for an optional account source with limited user impact.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The inspected native screenshots directly show the changed Claude menu’s segmented rendering, sentinel inspection, and restored active card on reopen; the captured body describes the synthetic cswap setup and broader switching checks.
• proof: sufficient: Contributor real behavior proof is sufficient. The inspected native screenshots directly show the changed Claude menu’s segmented rendering, sentinel inspection, and restored active card on reopen; the captured body describes the synthetic cswap setup and broader switching checks.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The inspected native screenshots directly show the changed Claude menu’s segmented rendering, sentinel inspection, and restored active card on reopen; the captured body describes the synthetic cswap setup and broader switching checks.

Evidence

What I checked:

• Current main still needs the fix: At the fetched main revision, addClaudeSwapMenuCards chooses only stacked or compact rendering and does not consult multiAccountMenuLayout. (Sources/CodexBar/Providers/Claude/StatusItemController+ClaudeSwapMenu.swift:10, b1e27d266a8e)
• Release comparison: Inspection of the same file at v0.56.8 also showed only stacked/compact rendering; the requested presentation is not supplied by that release. (Sources/CodexBar/Providers/Claude/StatusItemController+ClaudeSwapMenu.swift:10, 6ef82690b4a7)
• Introduced change and preference compatibility: The pinned merge-base-to-head diff contains nine files. It reads the existing preference without changing its default, persistence, or migration; the stacked branch remains intact. Production grows by 236 lines and tests by 188 net lines. (Sources/CodexBar/Providers/Claude/StatusItemController+ClaudeSwapMenu.swift:11, 8cbffc5c97bc)
• Earlier finding resolved: The repair clears inspection and calls invalidateMenus, which invalidates menu freshness and clears reusable merged content. The added regression reopens the same persistent menu in both provider and merged modes without changing the provider revision. (Sources/CodexBar/Providers/Claude/StatusItemController+ClaudeSwapMenu.swift:76, 51e135249859)
• Native visual evidence: Inspected all four prepared screenshots from the captured PR body: stacked cards, segmented buttons with one active card, expired-account diagnostics with the active marker preserved, and the active card restored after reopening. The body reports a freshly built Developer ID-signed native run with synthetic accounts and a fake cswap executable; screenshots directly establish the displayed UI states, not real credential transactions. (8cbffc5c97bc)
• Existing activation boundary preserved: The new selection handler looks up the current stable account identity and delegates activation to the existing guarded switch method. That method checks configuration, source, activatability and positive slot, serializes transactions, and calls the existing reader with fixed arguments. No credential storage, subprocess implementation, dependency, or permission changes are introduced. (Sources/CodexBar/Providers/Claude/UsageStore+ClaudeSwapRefresh.swift:115, 8cbffc5c97bc)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

• 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.

History

Review history (4 earlier review cycles)

• reviewed 2026-09-08T07:24:51.724Z sha 64b9b4f :: needs changes before merge. :: [P2] Invalidate the cached menu when clearing account inspection
• reviewed 2026-09-08T07:36:33.679Z sha b2e6a3a :: needs changes before merge. :: [P2] Invalidate the cached menu when clearing account inspection
• reviewed 2026-09-08T07:50:12.980Z sha 51e1352 :: blocked before merge. :: none
• reviewed 2026-09-08T08:04:58.412Z sha 8cbffc5 :: needs maintainer review before merge. :: none

[steipete]

Verified head 8cbffc5. CI is green: https://github.com/steipete/CodexBar/actions/runs/34202240112.

make check passed. The final make test run passed all 1,036 selections in 87 groups, on the first pass with no retries or timeouts. Independent branch review is clean through P2, and the current ClawSweeper review has no remaining findings.

The Developer ID-signed native harness used the production controller/menu and a fake cswap executable. It proved exactly one source-owned switch command per activation request, retained usage on failure, inspect-only expired accounts, privacy-safe slot labels, merged-menu behavior and two-row wrapping. Reopening the same persistent menu restored the active card with no provider-revision change and zero additional adapter calls. A populated ambient snapshot did not create an account card when the adapter reported no active account and none was explicitly inspected. The real built CLI retained full per-account card output, including the expired slot.

The persistent-menu regression failed before repair for both provider and merged menus, then passed. The no-active rendering regression protects against the shared empty-card fallback. Four existing architecture-test line offsets were refreshed without changing their anchor strings, fingerprints or enforcement. The PR body contains the inspected synthetic screenshots. Changelog notes are in #3499, to land last.