Refresh custom Account labels after account changes - #2362
Conversation
clawsweeper
Bot
added
rating: 🦪 silver shellfish
|
Codex review: needs maintainer review before merge. Reviewed July 25, 2026, 11:07 AM ET / 15:07 UTC. ClawSweeper reviewWhat this changesThis PR updates the menu-bar observation signature so stored custom layouts refresh when their displayed Account label changes, while keeping raw account text out of that signature. Merge readinessThis PR remains necessary: it targets a bounded custom-layout refresh bug, and the contributor now provides focused tests, green hosted checks, and redacted same-process runtime proof. The requested read-only repository inspection was blocked by the sandbox before I could independently compare the exact head with current Priority: P2 Review scores
Verification
How this fits togetherCodexBar receives provider usage snapshots and derives an observation signature to decide whether its menu-bar status item needs redrawing. Stored custom layouts can render an Account token, so visible account-label changes must participate in redraw detection without retaining personal information in the signature. flowchart LR
A[Provider usage snapshot] --> B[Resolve visible account label]
C[Stored custom layout] --> D[Check for Account token]
B --> E[Privacy-preserving observation signature]
D --> E
E --> F[Status-item redraw decision]
F --> G[Updated menu-bar label]
Before merge
Agent review detailsSecurityNone. Review metrics
Technical reviewBest possible solution: Merge a narrowly reviewed version that keeps account-label resolution shared between rendering and observation, verifies the signature remains process-local and privacy-preserving, and preserves the focused hidden-label and Account-token regression coverage. Do we have a high-confidence way to reproduce the issue? Yes, with medium confidence from the supplied focused tests and exact-head runtime transcript: configure an Account-only stored menu-bar layout, change only the provider account address, and select Refresh without restarting the app. I could not independently execute or inspect that path because the read-only sandbox failed before repository access. Is this the best way to solve the issue? Yes, provisionally. Including the rendered Account value as a privacy-preserving redraw input only when the stored layout displays Account is the narrowest apparent fix; normal source review should confirm that the hash is used only for process-local observation. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against cc8da27cec92. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Current state on head The previous re-review request appears to have stopped at the review-start placeholder from July 22, so requesting a fresh pass on the current proof. @clawsweeper re-review |
clawsweeper
Bot
added
proof: sufficient
|
Final maintainer review and isolated Codex autoreview were clean on exact head Focused local proof passed all 20 Exact-head hosted CI was fully green, including lint, both macOS test shards, Linux x64/arm64, musl, security, and the aggregate gate: https://github.com/steipete/CodexBar/actions/runs/29792483862 Merged as |
2 participants
Summary
Root cause
Custom Account tokens render from the snapshot account email, but icon observation intentionally ignored email-only snapshot churn. A stored layout containing Account could therefore keep showing the previous label until another visual field changed.
Verification
swift test --filter StatusItemIconObservationSignatureTests— 20 tests passedswift test --skip-build --no-parallel --filter '(MenuBarLayoutRendererTests|StatusItemIconObservationSignatureTests)'— 29 tests passedmake check— passed, including SwiftFormat and SwiftLint with zero violationsgit diff --check— passedExact-head runtime proof
I packaged and ran a fresh debug bundle from
5f9cffffbaf40388b90300d9ba1250b6d662cb78(CodexGitCommit=5f9cffff). The app used a stored custom layout containing only Account, with personal-info hiding off. A local fixture exercised CodexBar's supported Amp CLI provider path and kept usage constant at 20% used while changing only the synthetic account address. The same app process remained running, and I selected Refresh from its status menu after the identity change.Redacted terminal/live-capture transcript:
The
Dsuffix is CodexBar's debug-build marker. OCR was run locally against tight status-item captures with macOS Vision. No production account data or credentials were used.make testwas also run. It stopped in group 4 after both the initial run and automatic retry because two untouchedAdaptiveRefreshTimerTestshit their 30-second wait deadline:menu open advances a long idle timer during refresh without postponing an earlier tickcoding activity advances a long idle timer without postponing an earlier tickNo adaptive-refresh source or test files are changed here; hosted CI can provide clean-environment confirmation.
Risk
Low. Only stored custom layouts containing Account gain an additional render trigger. Other layouts and privacy-hidden account labels keep the previous observation behavior.
Review focus
Please sanity-check the render-aware observation boundary and the account-text hashing.