Restarting CodexBar creates a new Bartender item identity and resets it to Always Hidden

[zxfxpower]

Summary

Every normal quit and relaunch of CodexBar causes Bartender 6 to treat the menu bar item as a new identity.

The previously configured item remains in Bartender's Shown list, while a new UUID-prefixed identity with the same codexbar-merged suffix is added to Always Hidden. As a result, manually moving CodexBar to Shown does not persist across app restarts.

Environment

• CodexBar: 0.55.0 (build 129)
• Bartender: 6.6.2 (build 662000)
• macOS: 26.6.2 (25G83)
• Architecture: Apple Silicon (arm64)
• CodexBar bundle identifier: com.steipete.codexbar

Reproduction steps

1. Launch CodexBar and Bartender.
2. In Bartender, move the current CodexBar item to Shown.
3. Quit CodexBar normally.
4. Confirm the CodexBar process exits.
5. Relaunch CodexBar without changing any Bartender settings.
6. Inspect Bartender's menu bar item configuration.

Controlled before/after evidence

Bartender's ProfileSettings.activeProfile was inspected read-only before quitting, after quitting, and after relaunching.

Stage	CodexBar process	Shown	Always Hidden	Identity result
Before quit	Running	15	10	0F5CE9D2-CAF6-4213-BB2A-F3497C39177B-codexbar-merged was in Shown
After quit	Exited	15	10	Configuration was byte-for-byte equivalent for the CodexBar identity sets
After relaunch	New process	15	11	New 8142B235-395D-4F5C-A7C9-405DAB207B62-codexbar-merged entry appeared in Always Hidden

No existing identity was removed or moved. The old UUID remained in Shown, and the only configuration change was the new UUID being appended to Always Hidden.

The Bartender configuration had already accumulated 25 CodexBar entries with 23 distinct UUID prefixes, consistent with this happening repeatedly.

Expected behavior

Bartender should be able to associate the relaunched status item with the existing stable CodexBar identity and preserve the user's Shown/Hidden classification.

Actual behavior

Each CodexBar launch is persisted as a new UUID-prefixed Bartender item. The new identity is classified as Always Hidden, so the user's previous placement is not reused.

Possible contributing factor

This is an inference, not a confirmed root cause: the current status-item creation path creates the NSStatusItem, invokes the creation callback, and only then assigns the stable autosaveName.

https://github.com/steipete/CodexBar/blob/main/Sources/CodexBar/StatusItemController.swift

A menu bar manager may therefore observe the item before codexbar-merged is attached and persist an ephemeral identity. Bartender's internal matching logic is closed-source, so the exact UUID origin has not been confirmed.

Related issues

• Wrong position in menu bar in 0.32.2 #1267 was a different preferred-position regression fixed in CodexBar 0.32.3.
• Disappears on menu bar after updating (when using Thaw) #3024 reports a similar menu bar manager compatibility symptom with Thaw after updating, but this report reproduces on every normal restart with Bartender 6.6.2 and does not require a CodexBar update.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 25, 2026, 11:41 PM ET / August 26, 2026, 03:41 UTC.

Summary
This remains a small, source-supported menu-bar compatibility bug: the status item is exposed to its creation callback before its stable autosave identity is assigned, matching the reported repeatable Bartender identity churn.

Reproducibility: yes. —current source deterministically exposes the item to its creation callback before assigning its autosave name, and the report supplies a controlled current-release Bartender relaunch sequence for the user-visible symptom.

Next step
The source ordering defect, repair boundary, and focused regression seam are clear; the implementation worker should establish the failing creation-time test before opening a PR.

Review details

Best possible solution:

Assign the stable autosave name at the earliest safe point before CodexBar callback/setup exposure, add a creation-time regression test, then verify a fresh Bartender relaunch preserves the existing placement.

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

Yes—current source deterministically exposes the item to its creation callback before assigning its autosave name, and the report supplies a controlled current-release Bartender relaunch sequence for the user-visible symptom.

Is this the best way to solve the issue?

Yes—the narrowest repair is to establish the existing stable identity before any callback/setup exposure, with a regression test for that ordering and a real Bartender relaunch check.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Bartender is closed-source, so the repair must be validated with a fresh normal quit/relaunch against Bartender; source ordering alone cannot prove its matching algorithm.

Codex review notes: model internal, reasoning high; reviewed against 3cde772b9f02.

Label changes

Label changes:

• add P2: A normal relaunch repeatedly discards a user’s menu-bar-manager placement preference but does not make CodexBar unusable.
• add impact:ux-friction: Users must repeatedly reconfigure Bartender placement because the menu-bar item is treated as new after relaunch.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: A normal relaunch repeatedly discards a user’s menu-bar-manager placement preference but does not make CodexBar unusable.
• impact:ux-friction: Users must repeatedly reconfigure Bartender placement because the menu-bar item is treated as new after relaunch.

Evidence reviewed

Acceptance criteria:

• swift test --filter StatusItemControllerSplitLifecycleTests
• make test
• make check
• Freshly package and relaunch CodexBar, place it in Bartender’s Shown list, then confirm a normal quit/relaunch reuses rather than appends the manager identity.

What I checked:

• Current ordering exposes an unnamed item: The status-item factory creates the AppKit item, invokes its creation callback, and only then assigns the stable autosave name; the callback is an observable re-entry boundary. (Sources/CodexBar/StatusItemController.swift:329, 3cde772b9f02)
• Stable identity is an existing contract: The merged item’s declared stable name is codexbar-merged, and focused lifecycle tests assert stable autosave and accessibility identities for merged and provider items. (Sources/CodexBar/StatusItemController.swift:57, 3cde772b9f02)
• Current test coverage misses creation-time identity: The lifecycle test verifies the final identity after controller setup, but no test asserts that an onCreated callback receives an already-named item. (Tests/CodexBarTests/StatusItemControllerSplitLifecycleTests.swift:195, 3cde772b9f02)
• History and likely ownership: Blame attributes the factory ordering to the v0.55.0 release commit; the feature history also shows Peter Steinberger’s continuing work on status-item placement and lifecycle behavior. (Sources/CodexBar/StatusItemController.swift:329, 061593ca15d9)
• Reported real-world behavior: The issue supplies a controlled Bartender 6 before/after configuration comparison: a normal relaunch appends a new UUID-prefixed codexbar-merged identity while retaining the previous Shown entry.

Likely related people:

• Peter Steinberger: Current blame and the available status-item lifecycle history associate this factory and adjacent placement work with Peter Steinberger. (role: recent area contributor; confidence: medium; commits: 061593ca15d9, 8545c76d; files: Sources/CodexBar/StatusItemController.swift, Sources/CodexBar/MenuBarStatusItemPlacementPreflight.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]

I checked the proposed callback-order change against the reported codexbar-merged path. Both initial merged-item creation and visibility recovery omit onCreated. Moving that nil callback below the autosave-name assignment therefore does not establish a fix for the reported merged-item behavior, and it leaves the AppKit creation-to-name-assignment interval intact.

The callback is used by provider-item vending to register an item before setup can re-enter and create a duplicate (#2162). We should preserve that ownership boundary rather than change it based on this unconfirmed diagnosis.

The controlled restart evidence is still useful, and this issue remains open. A repair needs signed current-build Bartender proof across repeated normal restarts: retain the existing Shown identity without appending a new UUID, and correlate any startup recovery/recreation. A creation-callback unit test alone would not prove that result. No callback-order patch or closure is being made on the present evidence.

[zxfxpower]

Retested with the current signed CodexBar release across three consecutive normal restarts.

Environment:

• CodexBar: 0.56.1 (build 132)
• Bundle identifier: com.steipete.codexbar
• Signature: Developer ID Application: Peter Steinberger (Y5PE65HELJ)
• Gatekeeper: accepted, Notarized Developer ID
• Bartender: 6.6.2 (build 662000)
• macOS: 26.6.2 (25G83)
• Architecture: arm64

Method:

1. Put the currently active codexbar-merged item in Bartender's Show list.
2. Quit CodexBar normally.
3. Confirm the CodexBar process exited.
4. Read ProfileSettings.activeProfile without modifying it.
5. Relaunch CodexBar normally.
6. Compare the complete codexbar-merged UUID sets in Show and AlwaysHide.

In every cycle, quitting CodexBar left both UUID sets unchanged. Relaunching then appended one new UUID to AlwaysHide, while the previously shown identity remained in Show.

Cycle	Launch time (Asia/Shanghai)	New PID	Before relaunch	After relaunch	New identity	Visible
1	16:03:42	2626	Show 18 / AlwaysHide 10	Show 18 / AlwaysHide 11	63005168-8AAF-41B9-A100-CDD02A259995-codexbar-merged	No
2	16:12:13	42423	Show 19 / AlwaysHide 10	Show 19 / AlwaysHide 11	321E621D-A8E2-4A47-B7FA-641EC1DAF635-codexbar-merged	No
3	16:16:14	68189	Show 20 / AlwaysHide 10	Show 20 / AlwaysHide 11	88F974EC-47D3-4884-BE29-48D1F91DA56F-codexbar-merged	No

The profile contained 28 distinct codexbar-merged UUIDs before this test and 31 afterward—exactly one additional identity per launch.

The macOS unified log also showed fresh NSStatusItemView scene creation/reconnection activity at the time of each process launch. It did not expose an application-level recovery decision, so I am not treating that as proof of a specific root cause.

This confirms the current signed build does not retain the existing shown identity and instead appends a new UUID on every normal relaunch. I can repeat the same test against a signed candidate build when one is available.

[steipete]

#3825 (landed via #3830) creates the item at zero length, assigns codexbar-merged synchronously, then enables normal sizing. Startup and visibility recovery use the same factory and name; recording-item tests cover the sequence without creating a live status bar. #3665 had already moved naming before provider registration, but that alone did not establish a fix for the merged-item report. AppKit still creates an object before a name can be assigned, so these tests do not prove the origin or persistence of Bartender's UUID. Please keep this issue open until repeated normal restarts of a signed candidate retain the existing Shown identity without adding new Always Hidden entries. Thanks @zxfxpower for the controlled restart evidence.

[zxfxpower]

Thanks for the fix! I've updated to the latest version, and the issue appears to be resolved on my end.

Would you like me to run any additional checks or provide specific evidence to help confirm the fix? Please let me know what would be most useful.

[steipete]

Thanks @zxfxpower for the controlled restart comparisons. Current main assigns stable autosave names before registration and normal sizing, including recovery. The merged path already omitted the registration callback, so callback ordering alone cannot explain its reported UUID changes. Keeping this open until signed current-build Bartender restart comparisons show whether the existing Shown identity is retained and whether recovery recreated the item.