fix(codex): redact System Account menu labels

[steipete]

The Codex System Account submenu displayed full email addresses even with Hide Personal Info enabled. Its title builder used raw account names while the neighboring account switcher already applied privacy labels.

Use the existing stable account-number and workspace-label rules for this submenu when privacy is on. When privacy is off, preserve the original display names exactly, including Personal and workspace discriminators. The value-only menu builder preserves item order, checked state, promotion targets, blocking, and submenu visibility.

Validation: the regression reproduced three failed assertions before the fix. make test-fast FILTER='CodexSystemAccountPrivacy|CodexAccountSwitcherRedaction|ProviderArchitectureGatekeeper' passed 56 tests. Signed native before/after captures use the production item builder with synthetic accounts; they demonstrate the email leak and the corrected menu. No saved settings, credentials, provider calls, or account promotion actions were used. make check passed with zero violations; final independent P2 review is clean. Full macOS/Linux CI is the landing gate.

This extracts the privacy repair from #3550; the broader switching redesign remains open. Thanks @zenibako.

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

[steipete]

Hide Personal Info now applies to the Codex System Account submenu. These captures show the same synthetic accounts through the production item builder and a native NSMenu in a Developer ID signed, isolated test host. The checked and enabled states are identical; no account actions were invoked.

Before, with Hide Personal Info on:

After, with Hide Personal Info on:

The value-only tests also cover privacy off, duplicate workspace labels, embedded email-like workspace text, stable numbering, promotion targets, blocked actions, and the existing submenu visibility rules. This is synthetic native-menu proof; it does not claim a live-account switching run.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed September 16, 2026, 10:33 PM ET / September 17, 2026, 02:33 UTC (Revision 2).

ClawSweeper review

What this changes

The PR applies existing private account labels to the Codex System Account submenu and adds regression tests, native screenshot support, and documentation.

Merge readiness

✅ Ready for maintainer review

This remains a useful, focused privacy repair: current main and v0.60.4 still expose submenu emails. The earlier merge-conflict blocker is resolved, and the reviewed patch has no actionable correctness findings.

Priority: P2
Reviewed head: d9a7db757a67d12e6b0e72c1d1c73c6969bef3a0

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused, maintainable repair with directly relevant native visual proof and regression coverage; no blocking patch defect remains.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): Inspected native before/after captures exercise the production submenu-item builder with synthetic accounts and visibly replace emails with distinct private labels; source and regression coverage preserve action targets and state. This display-only change does not require live-account switching proof.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): Inspected native before/after captures exercise the production submenu-item builder with synthetic accounts and visibly replace emails with distinct private labels; source and regression coverage preserve action targets and state. This display-only change does not require live-account switching proof.
Evidence reviewed	8 items	Current main still exposes raw labels: The current-main submenu directly uses account.displayName without consulting Hide Personal Info. Latest release also retains the defect: The same raw displayName assignment is present in v0.60.4; the submenu repair is not already shipped there. Bounded production change: The complete introduced diff changes title construction while preserving item order, promotion UUIDs, checked/enabled state, and submenu visibility; privacy off still uses the exact original displayName.
Findings	None	None.
Security	None	None.

How this fits together

CodexBar builds its System Account submenu from visible Codex accounts and the user's privacy preference. Menu titles identify accounts, while separate stored account IDs route promotion actions.

flowchart LR
  A[Visible Codex accounts] --> C[System Account menu builder]
  B[Hide Personal Info setting] --> C
  C --> D[Existing private label rules]
  C --> E[Original display names]
  D --> F[Native submenu]
  E --> F
  C --> G[Unchanged promotion targets]

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production and test delta	Production +21/-11 (net +10); tests +253	The small production extraction enables focused regression coverage and an opt-in native capture harness.

Technical review

Best possible solution:

Use the shared privacy-label policy for submenu titles while preserving existing display names when privacy is off and keeping promotion behavior unchanged.

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

Yes: current main renders raw account display names in this submenu even when Hide Personal Info is enabled; supplied native before/after captures corroborate that path. No reproduction was executed during this read-only review.

Is this the best way to solve the issue?

Yes: reusing the existing redaction and stable-numbering helper is the narrowest repair, with focused tests preserving the submenu's original action and visibility contracts.

AGENTS.md: found and applied where relevant.

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

Labels

Label justifications:

• P2: Repairs a bounded privacy-display defect in one account submenu without changing authentication or promotion behavior.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): Inspected native before/after captures exercise the production submenu-item builder with synthetic accounts and visibly replace emails with distinct private labels; source and regression coverage preserve action targets and state. This display-only change does not require live-account switching proof.
• proof: sufficient: Contributor real behavior proof is sufficient. Inspected native before/after captures exercise the production submenu-item builder with synthetic accounts and visibly replace emails with distinct private labels; source and regression coverage preserve action targets and state. This display-only change does not require live-account switching proof.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Inspected native before/after captures exercise the production submenu-item builder with synthetic accounts and visibly replace emails with distinct private labels; source and regression coverage preserve action targets and state. This display-only change does not require live-account switching proof.

Evidence

What I checked:

• Current main still exposes raw labels: The current-main submenu directly uses account.displayName without consulting Hide Personal Info. (Sources/CodexBar/Providers/Codex/CodexProviderImplementation.swift:278, b88c78718da1)
• Latest release also retains the defect: The same raw displayName assignment is present in v0.60.4; the submenu repair is not already shipped there. (Sources/CodexBar/Providers/Codex/CodexProviderImplementation.swift:278, 937b20813cf4)
• Bounded production change: The complete introduced diff changes title construction while preserving item order, promotion UUIDs, checked/enabled state, and submenu visibility; privacy off still uses the exact original displayName. (Sources/CodexBar/Providers/Codex/CodexProviderImplementation.swift:266, d9a7db757a67)
• Existing labeling policy and merged history: The patch reuses the private labeling helper associated with merged fix: keep Codex account switcher labels private and distinct #3551. Raw commit parentage and the parent-to-commit diff confirm the helper's addition; GitHub metadata identifies zenibako as the commit author. That earlier repair covered the switcher, leaving this submenu path unchanged. (Sources/CodexBar/CodexAccountSwitcherLabeling.swift:34, 4cfb60692bdd)
• Inspected native before/after proof: Locally inspected both downloaded images from the owner's proof comment: fix(codex): redact System Account menu labels #3702 (comment). With privacy on, the before image exposes three synthetic emails; the after image shows Account 1, Account 2 · Acme, and Account 3 · Acme with matching visible checked/disabled states. The opt-in native harness calls the changed production builder. Signing and isolation are contributor-reported; this proves displayed labels, not live-account promotion. (Tests/CodexBarTests/CodexSystemAccountPrivacyProofTests.swift:53, d9a7db757a67)
• Previous blocker cleared: The test merge has the exact pinned main parent followed by the exact PR head. Its tree matches the reviewed head, and comparison with the earlier reviewed head shows no changes to the production repair or its two test files. Live GitHub metadata reports mergeable=true. (41a3ec27a0bf)

Likely related people:

• Chandler Anderson: Raw commit 4cfb606 adds Sources/CodexBar/CodexAccountSwitcherLabeling.swift:34 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 4cfb60692bdd; files: Sources/CodexBar/CodexAccountSwitcherLabeling.swift)
• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; 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 (1 earlier review cycle)

• reviewed 2026-09-17T02:27:13.691Z sha 59034bd :: blocked before merge. :: none

[steipete]

The existing System Account submenu now honors Hide Personal Info on main through #3702, merged as 141ecf6. It uses stable private account labels while keeping promotion targets and menu state intact; privacy off retains the original display names.

Validation: make test-fast FILTER='CodexSystemAccountPrivacy|CodexAccountSwitcherRedaction|ProviderArchitectureGatekeeper' passed 56 tests. Signed synthetic native before/after proof is at #3702 (comment). make check, final independent P2 review, and every macOS/Linux check passed: https://github.com/steipete/CodexBar/actions/runs/35174630916. The only integration conflict was in the changelog; source and test blobs remained unchanged.

Thanks @zenibako. This repairs the existing submenu's privacy omission; the broader account-switching redesign in #3550 remains open.