macOS 26.6.2: normal quit leaves blank menu-bar slots in CodexBar 0.67.0; autosaveName reset reproduces it

[mymatejackson]

Summary

Normally quitting CodexBar can leave its old ControlCenter-hosted status-item window behind as a blank Item-0. Relaunch creates a new working icon beside it. Repeated cycles accumulate gaps and displace other menu-bar icons toward the notch.

Confirmed on official CodexBar 0.67.0 (158): the first newly measured normal quit/relaunch cycle left the exact previous window behind. The app exited normally, but window 1360 changed from codexbar-merged to blank Item-0; relaunch created working window 1515 beside it. Visible hosted slots increased from 15 to 16. Previously, three of four tested 0.66.0 (156) cycles and both tested 0.65.0 (154) cycles failed.

A separate minimal AppKit app isolates the trigger: clear the status item's autosaveName, remove it, and immediately terminate. Keeping the name intact in otherwise equivalent controls leaves no blank slot. This also reproduces inside applicationWillTerminate.

Environment

• macOS 26.6.2 (25G83), MacBook Pro; merged icons enabled, percentage display.
• 0.67.0 positive: built-in display, 2056 logical points wide, 2× scale. Earlier positives also occurred on an external LED Cinema display at 2560×1440, 1× scale.
• No Bartender, Ice, or Hidden Bar installed/running. No custom global menu-bar spacing/padding setting found. CodexBar's menu-bar preferences were normal; no preference correction was made.
• Latest official release checked 26 September 2026: 0.67.0 (158). The installed bundle has Peter Steinberger's Developer ID signature, a stapled notarization ticket, and passes Gatekeeper assessment.

Reproduction

1. With CodexBar running, record its codexbar-merged window ID using CGWindowListCopyWindowInfo (ControlCenter, layer 25).
2. Request ordinary termination using NSRunningApplication.terminate() and confirm the app exits. No force kill is needed.
3. In failing cycles, the same window ID remains as blank Item-0. Relaunch adds a new working codexbar-merged window; repeat to see accumulation.

Expected: the old host disappears after normal quit, and the new launch preserves placement without adding a blank slot.

Official release/cycle	Old window	After normal quit and relaunch	New working window
0.67.0 cycle 1	1360	Retained blank Item-0	1515
0.66.0 cycle 1	7463	Removed correctly	7469
0.66.0 cycle 2	7469	Retained blank Item-0	7498
0.66.0 cycle 3	7498	Retained blank Item-0	7507
0.66.0 cycle 4	7507	Retained blank Item-0	7541

The outcome follows the exact old window ID; generic names and total window counts alone are insufficient because other system items change independently.

0.67.0 lifecycle evidence

At 17:39:32 local time on 26 September, AppKit approved normal termination, ControlCenter changed host identity from com.steipete.codexbar-codexbar-merged-44914 to com.steipete.codexbar-Item-0-44914, CodexBar completed termination, and ControlCenter then stopped tracking the renamed host. No matching ephemeral-displayable removal followed. The exact old window 1360 remained through relaunch as blank Item-0.

Source correlation

PR #3723 introduced clearing autosaveName before removal to preserve saved placement. That is the native sequence isolated here. The 0.67.0 removal helper is reached by shutdown from applicationWillTerminate.

Between 0.66.0 and 0.67.0, these relevant files changed only by two unrelated credential-notification cleanup calls in cancelShutdownTasks; the item-removal helper and identity-reset sequence are unchanged. Current main adds opt-in startup hosting diagnostics in PR #4012 for the different never-hosted-at-startup report #3377. That PR explicitly makes no runtime hosting fix and does not change this shutdown removal path. A fresh bounded issue search found no exact retained-after-exit duplicate.

Please investigate preserving host identity during actual termination without regressing saved icon positions. A regression check needs both successful old-window removal and preserved placement on relaunch. Preference-only tests miss this failure. A locally tested candidate source patch is included in the evidence archive, but the installed app remains the official build.

Attachments prepared

• Minimal AppKit reproducer and Info.plist
• Sanitized 0.67.0 and 0.66.0 per-cycle results
• Focused AppKit/ControlCenter lifecycle logs
• Native saved-position controls
• Candidate source patch and isolated validation results

No account identifiers, credentials, home-directory paths, or full-desktop screenshot are needed to reproduce or explain this report.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 26, 2026, 7:26 AM ET / 11:26 UTC.

Summary
The reported quit failure is supported by an official 0.67.0 reproduction and by the shutdown path on current main. The linked fix PR is open, so this issue remains the bug record while that repair is reviewed.

Reproducibility: yes. The report gives a controlled normal-quit reproduction on official 0.67.0 with exact old and new Control Center window IDs, and current main retains the same removal sequence; this checkout was not run as a macOS app.

Regression provenance
Possible regression — probable (reproduction; reviewed change). No predecessor PR is attributed.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #4022
Summary: An open PR explicitly proposes the repair for this issue. The cited startup-hosting report concerns a different lifecycle stage.

Members:

• canonical: Fix retained menu bar slots on quit #4022 - Open, explicitly linked candidate repair for normal-quit retained slots.
• adjacent_distinct: Tahoe 26.6.2: NSStatusItemScene exists in-process, but Control Center never hosts a layer-25 extra (0.56.3) #3377 - That report concerns an icon never hosted at startup, rather than an old host retained after quit.
• adjacent_distinct: fix(menu): preserve saved status item positions across removal #3723 - The merged placement change supplies relevant history but addressed saved positions during removal.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
The open, explicitly linked #4022 owns the proposed repair; review its native shutdown and placement evidence before resolving this issue.

Review details

Best possible solution:

Review the linked repair with a native quit-and-relaunch check that confirms the exact old Control Center window disappears and the icon retains its saved position; preserve the existing behavior for removal while the app keeps running.

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

Yes. The report gives a controlled normal-quit reproduction on official 0.67.0 with exact old and new Control Center window IDs, and current main retains the same removal sequence; this checkout was not run as a macOS app.

Is this the best way to solve the issue?

Yes, conditionally. A shutdown-specific identity treatment is a narrow fit if native verification shows both host removal and preserved placement; defaults-only tests cannot establish the host outcome.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 90f6d0aa2de9.

Label changes

Label changes:

• add P2: The reproduced macOS quit behavior accumulates blank slots and displaces other menu bar icons, with limited platform scope.
• add impact:ux-friction: Repeated quit and relaunch cycles leave visible gaps and disturb the user's menu bar layout.
• 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:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.

Label justifications:

• P2: The reproduced macOS quit behavior accumulates blank slots and displaces other menu bar icons, with limited platform scope.
• impact:ux-friction: Repeated quit and relaunch cycles leave visible gaps and disturb the user's menu bar layout.

Evidence reviewed

What I checked:

• Reported official-release reproduction: The issue reports that a normal quit of signed, notarized 0.67.0 on macOS 26.6.2 retained window 1360 as blank Item-0; relaunch created working window 1515. A minimal AppKit control reproduced the failure when autosaveName was cleared before removal.
• Current shutdown path: The application termination callback invokes status-item shutdown, which removes the merged item and each provider item. (Sources/CodexBar/StatusItemController+Shutdown.swift:104, 90f6d0aa2de9)
• Identity reset on removal: The removal helper clears the item's autosave name immediately before removing it, matching the reported isolated trigger. (Sources/CodexBar/MenuBarStatusItemPlacementPreservation.swift:31, 90f6d0aa2de9)
• Feature history: The placement-preservation helper, including the identity reset, was added by commit 70941c8 through merged fix(menu): preserve saved status item positions across removal #3723. Its raw recorded parent lacks this file. (Sources/CodexBar/MenuBarStatusItemPlacementPreservation.swift:31, 70941c8f7fe8)
• Release comparison: Release v0.67.0 contains the same identity-reset sequence as current main; the issue's official-release failure therefore remains relevant to the current source path. (Sources/CodexBar/MenuBarStatusItemPlacementPreservation.swift:31, e0286a895055)
• Existing tests and contract: Current shutdown tests check menu and item cleanup, while placement tests use in-memory defaults; neither observes whether Control Center removes the old hosted window. The changelog records saved-position preservation as shipped behavior. (Tests/CodexBarTests/StatusItemControllerShutdownTests.swift:59, 90f6d0aa2de9)

Likely related people:

• Petr Kratochvíl: Raw commit 70941c8 adds Sources/CodexBar/MenuBarStatusItemPlacementPreservation.swift:31 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 70941c8f7fe8; files: Sources/CodexBar/MenuBarStatusItemPlacementPreservation.swift)
• Peter Steinberger: 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.

[steipete]

Fixed on main via #4022 by @mymatejackson and shipping in 0.67.1. Root cause: the autosaveName = nil reset added in #3723 to protect saved positions during runtime removal was also running inside the quit teardown, so Control Center kept ghost slots for the renamed hosts. Shutdown now removes the items with their identities intact, while runtime hide/remove keeps the position protection. Thanks @giuseppebisemi for the independent confirmation.