Menu bar items multiply when usage updates occur with "Icon + Percentage" style and "Percent" display mode

[uclort]

Environment:

• Menu bar style: Icon + Percentage
• Display mode: Percentage
• Merged icons mode (single provider shown individually)

Steps to reproduce:

1. Set menu bar style to "Icon and Percentage"
2. Set display mode to "Percentage"
3. Use Codex (or any provider that produces frequent usage changes)
4. Observe the menu bar while usage is updating

Expected behavior:
The menu bar icon and percentage text should update in place without creating duplicate entries.

Actual behavior:
When usage data changes frequently (e.g., during active Codex use), multiple duplicate menu bar items appear to be created. The menu bar icon area seems to be repeatedly rebuilt rather than updated in place, sometimes resulting in multiple copies of the same status item appearing.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 14, 2026, 7:56 AM ET / 11:56 UTC.

Summary
Keep this issue open. The report includes exact settings and visual evidence, while current main retains a destructive visibility-recovery path that removes and recreates provider items. The earlier identity fix addressed display-change recovery but does not establish that this newly reported update-driven duplication is resolved.

Reproducibility: no. not yet at high confidence. The reporter supplies exact settings and a screenshot, but ordinary current-main usage refreshes reuse cached status items, so a live macOS run is needed to identify the event entering the destructive lifecycle path.

Ways to help us reproduce this

• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
The invariant, central lifecycle files, and validation boundary are narrow enough for one focused repair, but the worker must establish the live trigger before changing recovery behavior.

Review details

Best possible solution:

Maintain one stable NSStatusItem identity for the single visible provider, update its icon and percentage in place, make any necessary recovery serialized and idempotent, and verify the invariant with lifecycle tests plus a fresh-bundle macOS recording.

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

No, not yet at high confidence. The reporter supplies exact settings and a screenshot, but ordinary current-main usage refreshes reuse cached status items, so a live macOS run is needed to identify the event entering the destructive lifecycle path.

Is this the best way to solve the issue?

Unclear at the implementation level. Preserving one item and updating it in place is the correct invariant, but live reproduction should determine whether the narrow fix belongs in icon observation, settings visibility updates, or visibility recovery.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The screenshot and settings are concrete, but the exact current-main trigger is not established: ordinary icon refresh code appears to reuse the existing item, so visibility recovery, settings observation, or an AppKit interaction may be involved.
• The behavior is macOS/AppKit-specific and may not be reliably covered by headless tests; a freshly built bundle and visible menu-bar recording are needed to distinguish duplicate NSStatusItem instances from rendering or menu-bar-manager artifacts.

Codex review notes: model internal, reasoning high; reviewed against 6fef50406760.

Label changes

Label changes:

• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• remove issue-rating: 🐚 platinum hermit: Current issue advisory state no longer selects this label.
• remove clawsweeper:needs-live-repro: Current issue advisory state no longer selects this label.

Label justifications:

• P2: The report describes a visible, configuration-specific menu bar regression with bounded but meaningful user impact.
• impact:ux-friction: Repeated duplicate menu extras make the primary UI confusing and cluttered while the application otherwise remains usable.

Evidence reviewed

Acceptance criteria:

• swift test --filter 'MenuBarVisibilityWatcherTests|StatusItemControllerSplitLifecycleTests'
• make test
• make check
• ./Scripts/compile_and_run.sh
• Fresh-bundle macOS recording with the reported settings showing repeated usage updates and a stable single status item

What I checked:

• Current refresh path reuses status items: Usage-driven icon updates apply new content to existing items, and lazyStatusItem returns the cached per-provider NSStatusItem when available. (Sources/CodexBar/StatusItemController.swift:3467, 6fef50406760)
• Destructive recovery remains on main: recreateStatusItemsForVisibilityRecovery removes and replaces the merged item, removes every provider item, and then rebuilds visibility and icons; this remains a plausible lifecycle surface if recovery overlaps or triggers unexpectedly. (Sources/CodexBar/StatusItemController.swift:3569, 6fef50406760)
• Single-provider merged preference uses split lifecycle: shouldMergeIcons requires more than one displayed provider, so the reported single-provider configuration uses the per-provider statusItems dictionary even when Merge Icons is enabled. (Sources/CodexBar/StatusItemController.swift:3846, 6fef50406760)
• Prior related fix was narrower: Merged pull request Fix menu bar item identity #1122 preserved identity for live-but-displaced items while retaining destructive recreation for missing button, missing window, or zero-width cases. (Sources/CodexBar/StatusItemController.swift:3569, 22cf7d4)
• Latest release does not claim this fix: The v0.42.1 changelog and current unreleased section do not list a fix for status items multiplying during percentage updates. (CHANGELOG.md:1, 3e05988f5c5f)
• Repository vision supports bounded bug fixes: VISION.md lists bug fixes with clear causes and bounded risk under Merge by Default, fitting a focused status-item lifecycle correction. (VISION.md:7, 6fef50406760)

Likely related people:

• steipete: Recent history includes status-item visibility, settings-refresh, and lifecycle changes, and this person merged the prior stable-identity fix. (role: recent area contributor and merger; confidence: high; commits: 22cf7d4, 4484fad, b76c340; files: Sources/CodexBar/StatusItemController.swift, Sources/CodexBar/MenuBarVisibilityWatcher.swift)
• lederniermagicien: Authored the prior focused work separating destructive and non-destructive recovery and adding identity and lifecycle coverage. (role: introduced stable status-item identity behavior; confidence: high; commits: b7ed1b7; files: Sources/CodexBar/StatusItemController.swift, Sources/CodexBar/MenuBarVisibilityWatcher.swift, Tests/CodexBarTests/StatusItemControllerSplitLifecycleTests.swift)
• Zihao-Qi: Recently changed visual-settings refresh behavior in the same controller, which may relate to observation-triggered lifecycle updates. (role: recent adjacent UI lifecycle contributor; confidence: medium; commits: 5c6e6f9; files: Sources/CodexBar/StatusItemController.swift)

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.

[uclort]

Unfortunately, this issue does not appear to be fully resolved.

I can still reproduce the duplicate menu bar item problem. My current setup has two providers enabled: DeepSeek and ChatGPT. After the usage data refreshes, duplicate items are still created instead of the existing items being updated in place.

I’ve attached a screenshot showing the duplicated entries.

It looks like the fix in #2167 may not cover the multi-provider case or another status-item rebuild path. Could you please reopen this issue and investigate further?

[uclort]

Unfortunately, this issue does not appear to be fully resolved.

I can still reproduce the duplicate menu bar item problem. My current setup has two providers enabled: DeepSeek and ChatGPT. After the usage data refreshes, duplicate items are still created instead of the existing items being updated in place.

I’ve attached a screenshot showing the duplicated entries.

It looks like the fix in #2167 may not cover the multi-provider case or another status-item rebuild path. Could you please reopen this issue and investigate further?

@ss251 @StevanusPangau