[Bug]: Display-change recovery retry loop corrupts Control Center and confuses menu bar managers

[diazdesandi]

Hi, coming from https://github.com/stonerl/Thaw

Summary

When a display configuration change occurs (monitor connected/disconnected,
resolution changed) while CodexBar's status item is hidden by a menu bar
manager (Bartender, Ice, Hidden Bar, etc.), CodexBar can destroy and recreate
its NSStatusItem up to four times in rapid succession. Each recreation is
visible to the system as a brand-new status item, which corrupts Control
Center's internal layout and causes menu bar managers to lose track of or
re-expose the previously hidden item.

We discovered this issue while testing for the release of Thaw 2.0.0 beta 13. CodexBar corrupted the Control Center files and broke the app functionality itself. By looking at the logs, it was discovered that there were issues happening with CodexBar. We are working on a way to handle them from our side. If the build with issues is required, we can provide it. We also have multiple logs files and we can run a live test if required.

Environment

• CodexBar: /0.29.x
• macOS: 26.5
• Menu bar manager: Thaw

Expected behavior

On a display configuration change, CodexBar refreshes or recreates its status
item once if recovery is needed, then stops — leaving menu bar managers free
to manage its position without interference.

Actual behavior

The verifyScreenChangeRecoveryIfNeeded method introduced a retry loop in
commit c305858 ("fix: retry menu bar display recovery"). After the initial
recreateStatusItemsForVisibilityRecovery() call, the loop reschedules itself
up to three more times (2 s apart). When a menu bar manager re-parks or
re-hides the newly recreated item, the item can temporarily appear blocked
(hasWindow: false or buttonWidth: 0) before the manager completes its own
bookkeeping. Each such appearance triggers another recreation cycle, for up to
four total NSStatusItem destructions per display event.

Reproduction

1. Install Thaw and hide CodexBar's icon in its
   overflow section.
2. Run CodexBar.
3. Trigger a menu bar change
4. Observe Control Center icons shift or glitch, and Thaw re-exposing CodexBar
   as if it were a new unknown item.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed May 27, 2026, 5:31 AM ET / 09:31 UTC.

Summary
Keep open: current main still contains the display-change follow-up retry path that can call destructive status-item recreation again, and two open linked PRs already target the issue.

Reproducibility: We have a high-confidence source-level reproduction path: current main can recreate status items, schedule verification, and recreate again while a visible item still appears blocked. I did not establish a live macOS 26/Thaw reproduction in this read-only review.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
Two open linked PRs already target this exact issue, so a new ClawSweeper repair lane would duplicate active review work.

Review details

Best possible solution:

Review and land one linked fix that preserves the initial recovery recreation while making follow-up display-change verification non-destructive, with focused state-seam tests plus live macOS menu-bar-manager validation.

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

We have a high-confidence source-level reproduction path: current main can recreate status items, schedule verification, and recreate again while a visible item still appears blocked. I did not establish a live macOS 26/Thaw reproduction in this read-only review.

Is this the best way to solve the issue?

Yes, the best fix direction is narrow: keep the one recovery attempt when needed, but prevent destructive delayed retries while third-party menu bar managers settle. The linked PRs are the right review surface for that repair.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The source path is clear, but this review did not run a live macOS 26/Thaw display-change reproduction or verify Control Center file corruption directly.
• Two open PRs propose similar repairs; maintainers still need to choose and validate one path with a real menu bar manager before release.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 83ed8e405541.

Label changes

Label changes:

• remove clawsweeper:no-new-fix-pr: Current issue advisory state no longer selects this label.
• remove clawsweeper:linked-pr-open: Current issue advisory state no longer selects this label.

Label justifications:

• P2: The bug can visibly disrupt menu bar/Control Center behavior, but it is bounded to display-change recovery and third-party menu bar manager setups.
• impact:other: The affected surface is macOS menu bar and Control Center integration, which is maintainer-visible but not one of the more specific owned impact classes.

Evidence reviewed

What I checked:

• Current main retry loop: checkScreenChangeStatusItemVisibility recreates status items on a blocked snapshot, schedules a follow-up verification, and verifyScreenChangeRecoveryIfNeeded recreates again while the retry predicate remains true. (Sources/CodexBar/MenuBarVisibilityWatcher.swift:285, 83ed8e405541)
• Retry predicate remains enabled: shouldRetryScreenChangeRecovery returns true before screenChangeRecoveryRetryLimit when any visible snapshot still appears blocked. (Sources/CodexBar/MenuBarVisibilityWatcher.swift:150, 83ed8e405541)
• Recreation is destructive to status-item identity: recreateStatusItemsForVisibilityRecovery removes the current NSStatusItem, creates a new merged item, removes provider items, and reapplies visibility/icons. (Sources/CodexBar/StatusItemController.swift:680, 83ed8e405541)
• Existing tests encode retry behavior: The current test suite expects screen-change retry to continue for a missing window before the retry limit, matching the reported repeated-recreation path. (Tests/CodexBarTests/MenuBarVisibilityWatcherTests.swift:315, 83ed8e405541)
• History provenance: The reported retry loop traces to c305858cb9f1324d1c8d388b8c118e7f5fa21efb (fix: retry menu bar display recovery), which modified MenuBarVisibilityWatcher.swift and its tests. (Sources/CodexBar/MenuBarVisibilityWatcher.swift:309, c305858cb9f1)
• Release provenance: The latest shipped tag is v0.30.0 at 81cf30a6d5e157206ace4170fa4e115e72f8d203; current main 83ed8e405541b3861f34ccdbc5ae8fbc83a865ca is not contained in a tag, and the retry path remains present on main. (CHANGELOG.md:8, 81cf30a6d5e1)

Likely related people:

• steipete: The retry loop was introduced by c305858cb9f1324d1c8d388b8c118e7f5fa21efb, and current blame/log history for the affected files points to Peter Steinberger. (role: introduced behavior and recent area contributor; confidence: high; commits: c305858cb9f1, 81cf30a6d5e1; files: Sources/CodexBar/MenuBarVisibilityWatcher.swift, Tests/CodexBarTests/MenuBarVisibilityWatcherTests.swift, Sources/CodexBar/StatusItemController.swift)
• Yuxin-Qiao: Open linked PR Avoid repeated display-change status item recreation #1180 targets this issue by making follow-up verification observe-only. (role: linked fix author; confidence: medium; commits: 66b98eda34f6; files: Sources/CodexBar/MenuBarVisibilityWatcher.swift, Tests/CodexBarTests/MenuBarVisibilityWatcherTests.swift)
• diazdesandi: The reporter supplied the Thaw reproduction context and opened linked PR fix: stop retrying display-change recovery to avoid corrupting menu bar managers #1176 with live menu-bar-manager validation notes. (role: reporter and linked fix proposer; confidence: medium; commits: 9addc89bfc58; files: Sources/CodexBar/MenuBarVisibilityWatcher.swift, Tests/CodexBarTests/MenuBarVisibilityWatcherTests.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.

[steipete]

Fixed in #1176 / 63d9373.

What landed: CodexBar now performs at most one post-display recovery recreation, removes the dead retry predicate, and keeps the macOS allow-list guidance path via a synchronous post-recreation check. Local proof: swift test --filter MenuBarVisibilityWatcherTests, swift test --filter StatusItemControllerSplitLifecycleTests, make check, and clean autoreview.