Status bar items jump to leftmost (hidden) on restart — corrupted NSStatusItem Preferred Position values

[foobra]

Bug

On restart, one or more CodexBar status items (codex / claude / antigravity) jump to the leftmost position of the menu bar, where they collide with the notch / system control-center cluster and become hidden. Dragging them back does not stick — they snap to the front again on the next restart.

Root cause

The NSStatusItem Preferred Position <autosaveName> defaults (macOS status-item autosave; position is measured in points from the right edge of the menu bar) get written as out-of-range values far larger than any screen width. macOS clamps an out-of-range position to the leftmost slot, so the icon ends up at the front of the menu list and gets hidden behind system items.

Evidence

defaults read com.steipete.codexbar right before the fix:

"NSStatusItem Preferred Position codexbar-antigravity" = 614;
"NSStatusItem Preferred Position codexbar-claude" = 501;
"NSStatusItem Preferred Position codexbar-codex" = 6247;   ← out of range → clamped to FRONT → hidden
"NSStatusItem Visible codexbar-merged" = 0;
hasRepairedHiddenStatusItemVisibilityDefaults = 1;

Note that only codexbar-codex had the corrupted 6247 value; the other two were sane 3-digit numbers. The user also reports that on every restart, all three items jump to the leftmost position — suggesting the out-of-range write is not limited to a single provider and happens on a restart code path.

Workaround

Deleting the corrupted autosave positions and the hasRepaired flag, then restarting CodexBar, restores sane values:

defaults delete com.steipete.codexbar "NSStatusItem Preferred Position codexbar-codex"
defaults delete com.steipete.codexbar "NSStatusItem Visible codexbar-merged"
defaults delete com.steipete.codexbar hasRepairedHiddenStatusItemVisibilityDefaults
killall CodexBar && open -a CodexBar

After the above, values are sane again:

"NSStatusItem Preferred Position codexbar-antigravity" = 1218;
"NSStatusItem Preferred Position codexbar-claude" = 615;
"NSStatusItem Preferred Position codexbar-codex" = 548;

… but the corruption recurs on subsequent restarts.

Environment

• macOS: 15.7.7
• CodexBar: 0.56.2 (build 133)
• Bundle: com.steipete.codexbar

Suspected code paths (from DWARF in the binary)

• CodexBar/MenuBarStatusItemPlacementPreflight.swift
• CodexBar/StatusItemController+MenuBarLayout.swift
• CodexBar/StatusItemController+MenuRowReordering.swift

It looks like the autosave position for a status item is being written as an out-of-range value on some restart / lane-(re)creation / re-merge path (e.g. when the codex lane is freshly created or re-merged), instead of being derived from the current screen width or left untouched.

Expected

Status items keep their last user-dragged position across restarts, or are assigned a sane in-bounds position; they should never be written with a value larger than the screen width.

[clawsweeper]

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

Summary
Current code already clears invalid persisted positions before status-item creation, including in release v0.56.2. The report says corruption recurs on that release, which source inspection cannot confirm or disprove without a real macOS restart trace, so this remains an active bug report.

Reproducibility: no. this read-only Linux checkout cannot exercise macOS status-item persistence. Source verifies the cleanup path but cannot establish whether AppKit rewrites an invalid value after creation.

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
The latest release already contains the relevant cleanup path, so a fresh runtime trace is needed before safely dispatching a code change.

Review details

Best possible solution:

Capture a fresh v0.56.2-or-newer restart sequence showing the relevant defaults before launch, after launch, and after a user drag; repair only a confirmed remaining write or bounds path.

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

No: this read-only Linux checkout cannot exercise macOS status-item persistence. Source verifies the cleanup path but cannot establish whether AppKit rewrites an invalid value after creation.

Is this the best way to solve the issue?

No: deleting defaults restores placement temporarily but does not identify why the released preflight safeguard is bypassed or followed by another invalid write.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The released safeguard may be followed by an AppKit write or bypassed by a display-layout edge case; neither mechanism is established by the available source or tests.

Codex review notes: model internal, reasoning high; reviewed against 2ff41951c0e0.

Label changes

Label changes:

• add P2: The report describes a recurring menu-bar usability problem with limited provider-icon scope.
• add impact:ux-friction: Affected icons can become difficult to access after restart, but the report documents a manual recovery path.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.

Label justifications:

• P2: The report describes a recurring menu-bar usability problem with limited provider-icon scope.
• impact:ux-friction: Affected icons can become difficult to access after restart, but the report documents a manual recovery path.

Evidence reviewed

What I checked:

• Current repair path: Every status-item creation runs placement preflight before assigning its stable autosave name; the preflight removes malformed, non-positive, and screen-out-of-range saved positions. (Sources/CodexBar/StatusItemController.swift:325, 2ff41951c0e0)
• Provider creation uses the common repair path: Lazy provider status items are created only through the shared factory, so Codex and other provider autosave names receive the same preflight check. (Sources/CodexBar/StatusItemController+StatusItemVending.swift:18, 2ff41951c0e0)
• Focused regression coverage: Tests cover removing a 11298-point saved position against a 3000-point limit while retaining reasonable and large in-bounds positions. (Tests/CodexBarTests/StatusItemControllerSplitLifecycleTests.swift:354, 2ff41951c0e0)
• Release and history provenance: The placement source blob at placement-fix commit 55c0a10 is identical to v0.56.2’s blob; v0.56.2 is build 133, the release named in the report. Shallow history prevents parent-patch inspection, so this is not proof that the remaining runtime recurrence is fixed. (Sources/CodexBar/MenuBarStatusItemPlacementPreflight.swift:5, 55c0a105002f)
• Release identity: The v0.56.2 tag points at release commit 5351013 and the checked-in appcast identifies it as build 133. (appcast.xml:9, 5351013a211f)

Likely related people:

• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Piotr Durlej: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.

[w-winter]

Yep, super nasty bug that makes CodexBar unusable to me without a larger external display where I can reorder its menu bar position again.

[w-winter]

On restart, one or more CodexBar status items (codex / claude / antigravity) jump to the leftmost position of the menu bar, where they collide with the notch / system control-center cluster and become hidden. Dragging them back does not stick — they snap to the front again on the next restart.

I still reproduce this on CodexBar 0.56.6, btw, despite #3361

[w-winter]

Still occurring in 0.56.8 . Running macOS 26.6.2

[kratocz]

Root cause found on macOS 26.6.2 with the installed 0.60.3, fix in #3723.

Mechanism. On macOS 26, AppKit deletes NSStatusItem Preferred Position <autosaveName> from the app's defaults when a status item is removed (removeStatusItem) or hidden (isVisible = false) while the app keeps running. Without that key the next item with the same autosave name is placed at the far left of the status area. Removals that happen after NSApp.terminate has begun leave the key alone. Verified with a standalone AppKit probe; transcript is in the PR under .github/pr-proof/status-item-placement-preservation.log.

Trigger in CodexBar. The Quit menu action (StatusItemController+Actions.swift, quit()) calls prepareForAppShutdown() before NSApp.terminate(nil), so all status items are removed outside termination and every quit from the menu wipes the saved positions. Quitting through Sparkle's relaunch or the Quit button in Settings terminates first and keeps them, which is why the loss looks intermittent. Display-change recovery (refreshExistingStatusItemsForVisibilityRecovery hides and re-shows every item) and provider toggles (removeProviderStatusItem) take the same AppKit path.

Reproduction on the installed app (macOS 26.6.2, 0.60.3, split icons, no menu bar manager):

defaults read com.steipete.codexbar | grep "Preferred Position"   # three keys present
# Quit CodexBar from its status menu
defaults read com.steipete.codexbar | grep "Preferred Position"   # keys gone; next launch: icons far left

Quitting with osascript -e 'tell application id "com.steipete.codexbar" to quit' keeps the keys. A debug build of the fix branch kept a seeded position after Quit from the status menu.

Workaround until the fix ships: quit via the Settings button or the AppleScript above. Lost positions can be restored while the app is not running with defaults write com.steipete.codexbar "NSStatusItem Preferred Position codexbar-<provider>" -float <value>.

The out-of-range values reported here on Sequoia (6247) were not observed on this host; #3723 only covers the deletion path.