Summary
On a Mac where org.agentseal.codeburn-menubar has accumulated bad status-item state, the CodeBurnMenubar icon never appears in the menu bar, on any launch, on any display. The app itself runs fine (process alive, CLI polling works); only the NSStatusItem placement fails. Re-signing the identical binary with a different CFBundleIdentifier fixes it instantly, which isolates the bundle id as the only variable.
Environment
- macOS 26 (Tahoe), Apple Silicon
- Menu bar set to auto-hide (
_HIHideMenuBar = 1), relevant, see below
- CodeBurnMenubar 0.9.19 (local build) and 0.9.22 (official release), both affected identically
What I ruled out
All of the following were tried with the menu bar actively revealed during launch (auto-hidden bars make placement fail if the bar is hidden at launch time, but that alone isn't this bug):
- Fresh reinstall via
codeburn menubar (checksum-verified official 0.9.22): no icon
- Deleting the app's preferences domain and all caches/state, then reinstalling: no icon
killall ControlCenter then relaunch: no icon- Full reboot, fresh launch with the bar revealed: no icon
- Same binary,
CFBundleIdentifier changed to a fresh id and re-signed: icon appears on the first launch, every time (reproduced with both 0.9.19 and 0.9.22)
Diagnosis
macOS keeps per-bundle-id state for status items (Control Center's status-item scene service). That state can go permanently bad: once poisoned, NSStatusBar.system.statusItem(...) succeeds, item.isVisible reads true, the button has its image, but the item's window is parked at the screen's right corner behind the clock with legacy 22pt metrics, and AppKit never retries placement. The poison survives app reinstalls, preference deletion, and (new data point) reboots.
Likely contributor in this case: the app ran for weeks launching at login while the auto-hidden menu bar was hidden. Each such launch parks the item, and repeated parking appears to be what corrupts the id's state permanently. I've hit the same failure mode with three unrelated in-house menu-bar apps; the fresh-bundle-id fix worked first-try in every case.
Suggested fixes
- Placement hardening in
setupStatusItem: pin statusItem.autosaveName, force isVisible = true on every launch, and create the item only in applicationDidFinishLaunching (the flame button.image workaround you already ship helps a different Tahoe issue, not this one).
- A retry path for auto-hidden menu bars: placement only succeeds while the bar is revealed; a launch while it's hidden parks the item for that entire run. Observe-only sampling of
item.button?.window?.frame (healthy: ~30pt tall, inside the bar band, not flush against the right screen edge) detects the parked state; do not remove/recreate the item in a loop, since that churn is itself what poisons the id.
- An escape hatch: a documented way to run under an alternate bundle id (build flag or defaults key), so users with a poisoned id aren't permanently locked out. Re-signing locally works but
codeburn menubar --force reverts it on every update.
Happy to provide logs or test builds; the affected machine reproduces this 100% of the time.
Summary
On a Mac where
org.agentseal.codeburn-menubarhas accumulated bad status-item state, the CodeBurnMenubar icon never appears in the menu bar, on any launch, on any display. The app itself runs fine (process alive, CLI polling works); only theNSStatusItemplacement fails. Re-signing the identical binary with a differentCFBundleIdentifierfixes it instantly, which isolates the bundle id as the only variable.Environment
_HIHideMenuBar = 1), relevant, see belowWhat I ruled out
All of the following were tried with the menu bar actively revealed during launch (auto-hidden bars make placement fail if the bar is hidden at launch time, but that alone isn't this bug):
codeburn menubar(checksum-verified official 0.9.22): no iconkillall ControlCenterthen relaunch: no iconCFBundleIdentifierchanged to a fresh id and re-signed: icon appears on the first launch, every time (reproduced with both 0.9.19 and 0.9.22)Diagnosis
macOS keeps per-bundle-id state for status items (Control Center's status-item scene service). That state can go permanently bad: once poisoned,
NSStatusBar.system.statusItem(...)succeeds,item.isVisiblereads true, the button has its image, but the item's window is parked at the screen's right corner behind the clock with legacy 22pt metrics, and AppKit never retries placement. The poison survives app reinstalls, preference deletion, and (new data point) reboots.Likely contributor in this case: the app ran for weeks launching at login while the auto-hidden menu bar was hidden. Each such launch parks the item, and repeated parking appears to be what corrupts the id's state permanently. I've hit the same failure mode with three unrelated in-house menu-bar apps; the fresh-bundle-id fix worked first-try in every case.
Suggested fixes
setupStatusItem: pinstatusItem.autosaveName, forceisVisible = trueon every launch, and create the item only inapplicationDidFinishLaunching(the flamebutton.imageworkaround you already ship helps a different Tahoe issue, not this one).item.button?.window?.frame(healthy: ~30pt tall, inside the bar band, not flush against the right screen edge) detects the parked state; do not remove/recreate the item in a loop, since that churn is itself what poisons the id.codeburn menubar --forcereverts it on every update.Happy to provide logs or test builds; the affected machine reproduces this 100% of the time.