Wrong position in menu bar in 0.32.2

[AdrianSimionov]

Version 0.32.2 changed the position in the menu bar completely.

Currently, without Bartender on, when we open CodexBar, the position goes to most right side. Any other app, when opened, goes to left side of any other items already present.

With Bartender on, it goes to the right side of the Bartender icon (very strange); while Bartender is on CodexBar can be moved, but once I quit CodexBar and open it again, all icons move back to the right side of Bartender.

[clawsweeper]

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

Summary
Keep open. This is a fresh regression report, current main still contains the placement preflight from #1216, and the only commits after v0.32.2 do not touch the status-item placement code.

Reproducibility: no. not with high confidence. Source inspection clearly shows the current low-position preflight path, but the exact far-right and Bartender reset behavior needs a real macOS menu-bar run.

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
Maintainer review is needed to choose the placement-default tradeoff and require real macOS/Bartender proof before changing persisted status-item behavior again.

Review details

Best possible solution:

Revisit the placement preflight so fresh or missing stable autosave keys do not force right-edge placement or Bartender-side resets while preserving the upgrade and off-screen safeguards from #1216.

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

No, not with high confidence. Source inspection clearly shows the current low-position preflight path, but the exact far-right and Bartender reset behavior needs a real macOS menu-bar run.

Is this the best way to solve the issue?

Unclear. The likely fix is narrow, but changing persisted status-item placement behavior should be a maintainer-approved compatibility choice because the same code was added to avoid parked or off-screen status items.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live macOS/Bartender reproduction was run, so the exact right-edge and Bartender-side ordering behavior still needs real runtime confirmation.
• Changing the low preferred-position preflight could reintroduce the prior off-screen or hidden status-item behavior unless fresh-install, upgrade, and menu-bar-manager paths are validated together.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 4756ba06bf42.

Label changes

Label changes:

• add P2: This is a normal-priority user-visible menu-bar placement regression with limited blast radius but real usability impact.
• add impact:other: The issue affects CodexBar's visible menu-bar control surface and placement persistence, which is meaningful UI behavior outside the owned specific impact labels.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority user-visible menu-bar placement regression with limited blast radius but real usability impact.
• impact:other: The issue affects CodexBar's visible menu-bar control surface and placement persistence, which is meaningful UI behavior outside the owned specific impact labels.

Evidence reviewed

Acceptance criteria:

• swift test --filter StatusItemControllerSplitLifecycleTests
• swift test --filter MenuBarVisibilityWatcherTests
• make check
• Bundle-level macOS validation with a fresh install and an upgrade profile, both with and without Bartender or another menu-bar manager

What I checked:

• Current placement preflight: Before every status item is created, current main calls MenuBarStatusItemPlacementPreflight.prepare and then assigns a stable autosaveName. (Sources/CodexBar/StatusItemController.swift:239, 4756ba06bf42)
• Missing position keys are seeded low: prepare writes preferred position 0 when the stable key is missing or the stored value is above the suspicious threshold, which matches the code surface most likely to affect fresh placement. (Sources/CodexBar/MenuBarStatusItemPlacementPreflight.swift:13, 4756ba06bf42)
• Regression coverage documents intended current behavior: The tests explicitly expect a fresh install to write a low preferred position for codexbar-merged and preserve reasonable legacy Item-N positions. (Tests/CodexBarTests/StatusItemControllerSplitLifecycleTests.swift:127, 4756ba06bf42)
• No post-release placement fix on main: The diff from v0.32.2 to current main only changes CHANGELOG.md, version.env, and the widget project file, so the reported status-item placement surface is unchanged after the latest release. (4756ba06bf42)
• Related merged placement work: The merged placement PR added stable autosave names, preferred-position preflight, and maintainer fixups for legacy Item-N preservation; its commits are the likely provenance for this behavior. (38f684169ae3)
• Latest release check: The latest GitHub release is v0.32.2, published on 2026-06-01, matching the version named in the report. (3f419060f875)

Likely related people:

• steipete: Authored the follow-up commit preserving menu bar placement on upgrade, merged the related placement PR, and owns the current release commits around this area. (role: recent area contributor and merger; confidence: high; commits: 38f684169ae3, 8545c76d7aac, 3f419060f875; files: Sources/CodexBar/StatusItemController.swift, Sources/CodexBar/MenuBarStatusItemPlacementPreflight.swift, Tests/CodexBarTests/StatusItemControllerSplitLifecycleTests.swift)
• pdurlej: Authored the merged placement hardening commit that added stable autosave names and preferred-position preflight. (role: introduced behavior; confidence: high; commits: 42224287df9c; files: Sources/CodexBar/StatusItemController.swift, Sources/CodexBar/MenuBarStatusItemPlacementPreflight.swift, Sources/CodexBar/MenuBarStatusItemWindowProbe.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.

[AdrianSimionov]

I went back manually and this issue was introduced in 0.32.0

Works well in 0.31.0, but not after that.

[Yuxin-Qiao]

Recent contributor here — I think the pin-to-right is intentional, not a regression.

Pre-0.32.2, switching providers (Claude/Codex/DeepSeek) changed the status item's content length. Without a pinned position, NSStatusBar recomputed layout on every change — the whole item, including its open dropdown, drifted left/right. That wobble was the worse UX.

The trade-off: pin the position, let internal width absorb content changes. Cost is exactly what you describe — other icons get pushed left on first launch, dragged position is ignored.

Possible middle ground: honor an autosaved position when one exists, fall back to rightmost only on first launch. Worth a rememberMenuBarPosition toggle maybe?

[kirocop]

Additional diagnostic data (5K display, macOS 26.5)

• macOS: 26.5 (25F71)
• Display: 5K (5120x2880 native, 2560x1440 logical @ 2x scaling)
• CodexBar version: 0.32.2 (77), installed via brew install --cask steipete/tap/codexbar
• Menu bar item position (via System Events): x=-1, y=1424 — bottom-left corner, outside the visible top menu bar (screen is 2560x1440, so y=1424 is 16px from bottom)
• Screen bounds: 0, 0, 2560, 1440
• Process state: running, idle in mach_msg2_trap event loop, not crashed
• Keepalive window position: -5000, 6439 (off-screen, expected for lifecycle keepalive)
• Menu bar items in status menu: 1 item exists but is not visible at the top of the screen

What I tried (none fixed the position):

• Clean reinstall via brew uninstall --cask --zap --force codexbar && brew install --cask steipete/tap/codexbar
• defaults delete com.steipete.codexbar + app restart
• Force quit and relaunch

Observation: The NSStatusItem is being created but its computed position resolves to the bottom-left of the screen instead of integrating into the top menu bar. This is consistent with the placement preflight not accounting for 2x scaled 5K displays on macOS 26.

Next step for me: Reverting to 0.32.1 to confirm the regression is version-specific. Will report back with results.

[kirocop]

Additional diagnostic data + regression range

Hi! I spent time reproducing this and can confirm the issue. A few findings that may help narrow down the fix:

Regression range (not just 0.32.2):

• 0.31.0 → menu bar item position: (2525, -1) ✅ correct (top-right, in the menubar)
• 0.32.1 → position: (-1, 1439) ❌ broken (bottom-left, off-screen)
• 0.32.2 → position: (-1, 1424) ❌ broken (bottom-left, off-screen)

So the bug was introduced between 0.31.0 and 0.32.1, not 0.32.2 as the original report says.

Environment:

• macOS 26.5 (25F71)
• Display: 5K (5120x2880 native, 2560x1440 logical @ 2x scaling)
• Screen bounds: 0, 0, 2560, 1440
• CodexBar 0.32.2 (build 77)
• No Bartender. iStat Menus 7 (Setapp) is installed but the bug reproduces with it killed.

What I tried (none fix it):

• Fresh reinstall via brew install --cask steipete/tap/codexbar
• defaults delete com.steipete.codexbar.plist + relaunch
• Cleared ~/Library/Saved Application State/com.steipete.codexbar.savedState
• Killed iStat Menus daemon (launchctl unload + killall)
• defaults write NSStatusItem Preferred Position com.steipete.codexbar = 2500 (app overwrites it back to -1)

The status item is being created with a wrong preferredPosition/anchor on first launch for this display config. Position (-1, 1424) on a 1440-tall screen = bottom-left corner, which suggests a divide-by-zero or off-by-one in the placement preflight when screen.frame or NSStatusItem.systemMenuBar.height returns an unexpected value.

HTH — happy to test any fix.

[steipete]

Fixed on main in 55c0a10.

This stops seeding fresh status items with a forced private preferred-position value and clears bad stored preferred-position defaults for both stable codexbar-* keys and matching legacy Item-N keys. Valid large-display positions are preserved.

Proof:

• StatusItemControllerSplitLifecycleTests: 22 passed, including forced-zero cleanup, matching legacy cleanup, and 5K-sized large-position preservation.
• make check: SwiftFormat and SwiftLint passed.
• Autoreview: clean, no accepted/actionable findings.
• Live ad-hoc bundle: seeded codexbar-merged preferred position to 0, launched with keychain disabled/manual refresh, and verified the stored value was removed; Peekaboo saw codexbar-merged in the menu bar.

Leaving this open for reporter verification on macOS 26.5 / 5K after the next release.