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

Start with CodexBar/MenuBarStatusItemPlacementPreflight.swift, StatusItemController+MenuBarLayout.swift, and StatusItemController+MenuRowReordering.swift, focusing on restart, lane recreation, and re-merge paths. Reproduce the issue by inspecting the NSStatusItem Preferred Position defaults before and after restarting CodexBar. Done means status items retain their dragged positions or receive in-bounds values and no longer jump left or become hidden.

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.