Tahoe 26.6.2: NSStatusItemScene exists in-process, but Control Center never hosts a layer-25 extra (0.56.3)

[NicholasLea]

Description

CodexBar 0.56.3 launches, fetches usage, and creates an NSStatusItem / NSStatusItemScene in-process, but Control Center never hosts a layer-25 extra named codexbar-merged or com.steipete.codexbar. The menu bar icon is therefore unreachable. The official Tahoe allow-list toggle is already on, and hasShownTahoeAllowListGuidance never gets written, so the startup recovery / guidance alert never runs.

This is the same user-visible symptom as #1109 / #890 / #988 / #1077, but it still reproduces on current 0.56.3 after those recoveries landed. The new evidence is that AppKit has the scene, while the window server does not.

Environment

• CodexBar: 0.56.3 (134), official notarized ZIP (Developer ID Application: Peter Steinberger (Y5PE65HELJ)), /Applications/CodexBar.app
• Previous build on the same machine: 0.56.2 (133), same failure
• macOS: 26.6.2 (25G83)
• Bundle: com.steipete.codexbar, LSUIElement=true
• Displays:
  • LG UltraFine (0, 0, 1920x1080) (primary viewing screen)
  • Built-in Retina (210, -900, 1440x900) (below the LG)
• Menu-bar manager: iBar Pro is installed, but quitting it does not make a CC extra appear
• Enabled providers: codex, claude, gemini
• Menu-bar prefs after cleanup: mergeIcons=1, menuBarDisplayMode=percent, menuBarShowsBrandIconWithPercent=0, menuBarHidesCritters=1 (.bars, not brand-icon-percent)

What I tried

All of these left layer 25 unchanged (no codexbar-* / com.steipete.codexbar extra):

1. Toggle System Settings → Menu Bar → Allow in the Menu Bar → CodexBar off/on. It stays on.
2. Quit/relaunch CodexBar; upgrade 0.56.2 → 0.56.3.
3. Delete leftover NSStatusItem Visible/VisibleCC/Preferred Position Item-0…Item-9, keep VisibleCC codexbar-merged=1.
4. Force NSStatusItem Visible codexbar-merged=1 and Preferred Position codexbar-merged=180. Launch still rewrites Preferred Position Item-0=1007 and later codexbar-merged=1007.
5. Set mergeIcons=0 and pre-enable VisibleCC for codexbar-codex / codexbar-claude / codexbar-gemini. Heap then shows 4 NSStatusItemScenes; still no CC extra.
6. Quit iBar Pro, then launch CodexBar alone. Still no CC extra. iBar was relaunched afterwards.
7. Restart Control Center once (killall ControlCenter). Layer-25 count changed (other extras reattached); CodexBar still did not appear.
8. Did not loop removeStatusItem / killall ControlCenter (the source comment about corrupting CC is noted).

Evidence

1. Process and usage are healthy

• CodexBar process stays running (LSUIElement).
• Snapshots/CLI usage work (Codex session/weekly quotas update).
• Gatekeeper: spctl --assess = Notarized Developer ID.

2. AppKit creates the status item; the window server does not host it

heap on the 0.56.3 process with mergeIcons=1:

1  NSStatusBarWindow
1  NSStatusItemScene
1  NSStatusItemSceneSpecification

With mergeIcons=0:

4  NSStatusBarWindow
4  NSStatusItemScene

CGWindowListCopyWindowInfo(.optionAll) for the CodexBar PID only shows the SwiftUI placeholder settings scene:

owner=CodexBar name=CodexBar设置 layer=0  0x0 or 900x450

Control Center layer 25 on this machine has 50–77 extras (Clock, Sound, Wi‑Fi, Surge, WeChat, Chrome, iBar, …). None are:

• codexbar-merged
• codexbar-codex / codexbar-claude / codexbar-gemini
• com.steipete.codexbar

Hidden-but-real extras still keep a layer-25 window (negative x or y=1080 on the laptop bar). CodexBar has no such window, so this is not “overflow / other display / iBar tray”.

3. Defaults say the extra should be shown

NSStatusItem VisibleCC codexbar-merged = 1
NSStatusItem Visible     codexbar-merged = 1
NSStatusItem Preferred Position Item-0 = 1007          # recreated every launch
NSStatusItem Preferred Position codexbar-merged = 1007
hasShownTahoeAllowListGuidance = <unset>

ByHost com.apple.controlcenter.displayablemenuextras:

{"displayableInfos":[],"providerData":"<empty instanceIds NSKeyedArchive>"}

Other third-party extras still host, so an empty displayableInfos is not a global allow-list wipe. System Settings still lists CodexBar as allowed.

4. Startup recovery never fires

After a clean 0.56.3 launch, hasShownTahoeAllowListGuidance / tahoeAllowListGuidanceLastShownAt stay unset. No “CodexBar can't show its menu bar icon” alert.

That matches a gap in MenuBarVisibilityWatcher:

• TahoeHiddenNoProxy requires expectsVisibility && VisibleCC==true && !isVisible && !hasWindow
• isBlockedSnapshot requires isVisible && (!hasWindow || buttonWidth <= 0)

If AppKit leaves button.window / NSStatusBarWindow alive in-process (heap shows it) while Control Center never publishes a layer-25 extra, both predicates miss. The 10s startup recreate + allow-list guidance therefore never run.

MenuBarStatusItemWindowProbe only matches CG windows whose name is the autosave name (codexbar-merged). There is no such CC window here, so isTahoeBlockedProxy also does not trip.

5. Identity split on every vend

StatusItemController.makeStatusItem does:

let item = statusBar.statusItem(withLength: .variableLength)
onCreated?(item)
item.autosaveName = identity.autosaveName  // "codexbar-merged"

Launch always recreates NSStatusItem Preferred Position Item-0 = 1007 even when only the merged extra should exist. Tahoe may bind the CC scene to the implicit Item-0 identity, then lose it when autosaveName is renamed.

Expected

After launch, Control Center should host a visible (or at least overflow-listed) extra for codexbar-merged, and/or startup recovery should detect “in-process scene, no CC extra” and recreate + show the Tahoe allow-list alert.

Actual

• In-process: NSStatusItemScene exists.
• Window server: no CodexBar extra.
• Recovery: silent. ⌘, only hits the SwiftUI Settings { EmptyView() } placeholder (PlaceholderSettingsWindowGuard / CodexBar 0.53.0 always opens a blank Settings window on macOS 26.6.2 #3053). With no Dock icon and no status item, the real AppKit settings window is effectively unreachable.

Related

• Menu bar icon does not appear on macOS 26.5, CLI works (v0.28.0) #1109 (closed; owner could not reproduce on 26.5 / 0.28–0.29). Reporter later saw AX items at (-1, 950) / (1435, -1). This machine is stricter: no CC extra at all.
• Menu bar icon disappears or reattaches to external display after display reconfiguration on macOS 26.5 #1077 display-change rematerialization
• v0.25: Menu bar icon does not appear, CLI Operates #890 Tahoe allow-list
• v0.26.1: Menu bar icon does not appear on macOS 15.7.4 Sequoia #988 prefs-visible but not materialized
• Menu bar icon still missing on macOS 26.4 with CodexBar 0.23 #805 / fix: restore menu bar icon on macOS 26.4 (#805) #849 macOS 26.4 icon restore

Suggested probes

1. Treat “NSStatusItemScene exists but CGWindowList has no CC extra named autosaveName” as a startup recovery candidate, even when button.window != nil.
2. Set autosaveName before statusItem(withLength:), or create with a named extra so Tahoe never sees a transient Item-0.
3. Log isVisible, button.window != nil, button.frame, and MenuBarStatusItemWindowProbe names at the 2s startup check. log show --predicate 'process == "CodexBar"' is often empty here because of TCC, so an on-disk startup diagnostic would help.
4. I can re-run any probe build on this 26.6.2 dual-display + iBar machine.

Notes / non-causes

• Not a crash, not a dead process, not missing usage data.
• Not the old 1000px brand-icon-percent layout (menuBarShowsBrandIconWithPercent is off).
• Not iBar permanently hiding the extra (arrOfForEverHidden has no CodexBar; quitting iBar does not vend a CC window).
• One Control Center restart was tried; it was not looped.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 2, 2026, 1:25 AM ET / 05:25 UTC.

Summary
Current source contains the reported recovery gap: a visible Tahoe status item with a live AppKit window is considered healthy unless a specific off-display Control Center proxy is found. The reported absence of any named Control Center window therefore cannot trigger recreation or guidance. This is a bounded existing-behavior bug worth a focused fix.

Reproducibility: no. live reproduction was run in this read-only Linux environment, but yes at source level: an expected enabled Tahoe item with a live AppKit window and no named window-server record returns false from every current startup-recovery candidate.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
The source establishes a narrow missed recovery state with clear implementation and state-seam test locations; a worker must obtain real Tahoe after-fix proof before proposing a PR.

Review details

Best possible solution:

Add a narrowly gated startup candidate for an expected, preference-enabled Tahoe item that remains live in AppKit yet has no matching Control Center window, preserve the existing anti-retry safeguards, and validate it on the reporter's setup.

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

No live reproduction was run in this read-only Linux environment, but yes at source level: an expected enabled Tahoe item with a live AppKit window and no named window-server record returns false from every current startup-recovery candidate.

Is this the best way to solve the issue?

Yes: add a narrow recovery predicate rather than changing status-item identity first, because current source directly proves the recovery decision misses this state while creation-order changes remain an unproven platform hypothesis.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A no-matching-window predicate must remain Tahoe-gated and require app intent plus the enabled visibility default, or it could recreate items intentionally managed or hidden by third-party menu-bar tools.
• The source-only review cannot validate the reporter's dual-display Tahoe environment; the repair needs real post-fix Tahoe evidence before merge.

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

Label changes

Label changes:

• add P1: The running app has no reachable menu-bar control surface on the reported current Tahoe release.
• add impact:ux-friction: The report documents a broken visible control surface and difficult recovery, without establishing that every user path is universally blocked.
• 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:

• P1: The running app has no reachable menu-bar control surface on the reported current Tahoe release.
• impact:ux-friction: The report documents a broken visible control surface and difficult recovery, without establishing that every user path is universally blocked.

Evidence reviewed

Acceptance criteria:

• swift test --filter MenuBarVisibilityWatcherTests
• make test
• make check
• Redacted real Tahoe 26.6.2 launch evidence showing a named Control Center extra or the intended recovery/guidance result

What I checked:

• Current recovery predicate: Startup recovery handles blocked visible snapshots, hidden no-window Tahoe items with an enabled visibility default, and displaced items corroborated by an off-display Control Center proxy. It does not handle a visible item with a live window and no matching Control Center record. (Sources/CodexBar/MenuBarVisibilityWatcher.swift:126, a8b9c55cd008)
• Window-server probe scope: The probe returns only windows whose name equals a status item's autosave name; an empty result is not currently a startup-recovery candidate for an otherwise live AppKit item. (Sources/CodexBar/MenuBarStatusItemWindowProbe.swift:51, a8b9c55cd008)
• Existing recovery tests: Tests cover hidden/no-window Tahoe items and detached items corroborated by a proxy, while a live detached item without proxy corroboration is intentionally ignored; there is no coverage for the reported no-window-server-record state. (Tests/CodexBarTests/MenuBarVisibilityWatcherTests.swift:391, a8b9c55cd008)
• Feature history: The relevant Tahoe no-window recovery path was merged as “fix: detect Tahoe no-window menu block (Fix Tahoe no-window menu bar recovery #1954)”; earlier related recovery work also exists. The partial clone could not retrieve promised older blobs for source-line introduction verification, so routing relies on commit history rather than blame attribution. (Sources/CodexBar/MenuBarVisibilityWatcher.swift:150, 4484fad21c84)
• Release boundary: v0.56.3 is an ancestor of current main, but no tag contains current main and the current source still lacks the reported recovery condition; no shipped or main-only fix was found. (a8b9c55cd008)

Likely related people:

• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Piotr Durlej: 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.

[di-terekhov]

Additional reproduction on 0.59.0 (142) — the failure is still there, but it presents differently than described in the original report: the layer-25 window record is present in every state I sampled, while the rendered pixels inside those bounds come and go. So on 0.59.0, checking the window-server record cannot distinguish healthy from broken.

Environment: macOS 26.6.2 (25G83), MacBook Pro built-in display (1512×982, single display), no third-party menu bar manager, mergeIcons=1, NSStatusItem VisibleCC codexbar-merged=1, allow-list toggle on, notarized build at /Applications/CodexBar.app.

What I observed across quit → relaunch cycles of the same 0.59.0 binary

State	codexbar-merged record (CGWindowList, layer 25)	Pixels inside the recorded 94×33 bounds
Icon visible to the user	present (597,0 94×33)	14–17 rows of bright pixels (white text)
Icon not visible to the user	still present (597,0 94×33)	flat background — 0 bright rows

• The state is intermittent in both directions, including without a process restart: one instance went not-rendered → rendered on its own after a few minutes; another was rendered right after launch, not rendered ~1–2 minutes later, then rendered again. So this is not a per-launch coin flip that stays fixed — something re-rolls it during a launch.
• Once a launch is in the rendered state, it is stable: 5 minutes of 2-second pixel sampling stayed visible (143/143 samples), while the app kept sending per-minute countdown updates to Control Center (NSSceneFenceAction every ~60s in the unified log). Per-minute scene updates don't break it once hosted.
• In one not-visible sample the icon's bounds were not flat: ~2,400 mid-gray pixels (luminance 100–200) over the near-black bar, where an adjacent empty menu-bar region sampled seconds later had 2 unique luminance levels and zero mid-gray pixels. That sample looks like content composited dark-on-dark (wrong appearance), not a missing window. I can't say yet whether all not-visible samples are this variant or some are truly unhosted.

User-visible symptom when not rendered matches this issue exactly: the app looks dead, and "opening" it again does nothing — the process is alive the whole time (LSUIElement, so a second open just re-activates the hidden instance).

Cheap verification oracle

The original report's diagnostics (heap + window record) can't see this on 0.59.0. Pixel-sampling the recorded bounds can:

# capture the status item's recorded bounds (adjust to your CGWindowList output)
screencapture -x -R"590,0,110,36" /tmp/icon.png
# check for rendered content vs the flat menu-bar background
# (e.g. PIL, grayscale: rows where max luminance > 150 = rendered;
#  2 unique levels = empty;  many mid-gray pixels = composited dark-on-dark)

If startup-recovery logic is considered for this, "window record exists" cannot be the health signal — on 0.59.0 the record exists in the broken state too. A recovery heuristic based on rendered content inside the bounds (with a re-add/removeStatusItem retry on timeout) would cover both the original never-hosted case and this rendered-nothing/dark-on-dark case.

Workaround

killall CodexBar && open -a CodexBar restored a visible icon within 1–2 attempts in my runs. It also self-healed once without any restart, so waiting a few minutes can work too.

[steipete]

Thanks for the controlled 0.59.0 comparison. The persistent window record and the changes while the same process is running point to a different failure mode from a status item that is never hosted. A recovery rule based only on a missing window would miss this case.

Which menu-bar layout and provider are selected, and is the high-contrast menu-bar option enabled? Those details will let us reproduce the same rendering path and check image/template handling across appearance and refresh changes. Please share only the layout/settings details; no account information is needed.

[NicholasLea]

Here are the exact layout, provider, and display configuration details from my environment (running CodexBar 0.59.0 on macOS 26.6.2 (25G83)):

1. Menu Bar Layout & Display Settings

• Merge Icons: Enabled (mergeIcons = 1, using codexbar-merged)
• Display Mode: Percent (menuBarDisplayMode = percent)
• Brand Icon with Percent: Disabled (menuBarShowsBrandIconWithPercent = 0)
• Refresh Frequency: 5 minutes (refreshFrequency = fiveMinutes)
• Hide Critters: Enabled (menuBarHidesCritters = 1)

2. Selected Providers

• Enabled providers: codex, claude, and gemini.

3. Contrast & Appearance Options

• CodexBar High Contrast on Inactive Displays: Enabled (menuBarHighContrastOnInactiveDisplays = 1)
• macOS System High Contrast: Disabled (increaseContrast is not set / standard contrast)
• System Appearance: Dark Mode (AppleInterfaceStyle = Dark)

4. Display Setup

• Dual displays:
  • Main: External 4K display (LG UltraFine, 3840×2160, UI scaled to 1920×1080)
  • Secondary: Built-in MacBook Retina display (2560×1600)

[steipete]

I tested a signed, isolated native host on macOS 26.6.2 (25G83) with the production status-item controller, dark appearance, high contrast enabled, synthetic Codex/Claude/Gemini usage, and merged icons. The diagnostic is in #3572; no recovery behavior was changed.

The reported legacy icon preferences resolve to plain bars in this build; those rendered and had a hosted Control Center window. I also exercised an explicit percent-only layout. Across about 130 seconds, all 11 successfully matched window captures showed the synthetic 75% text (274 bright pixels in each capture). Two samples had no exact AppKit/window-server geometry match and were treated as inconclusive, not as proof of an unhosted icon.

This did not reproduce missing or dark-on-dark content. It also does not reproduce the reporter's dual-display/inactive-display setup. Keeping this open; the evidence does not justify adding a recreation loop or treating a window-record mismatch alone as failure.

A repeat with the improved geometry diagnostic on the final notes branch caught an initial offscreen AppKit button frame at {0, -22, 34, 22} that settled into its hosted position during the next capture phase. Complete Cocoa button/window and Quartz server bounds are now recorded in #3572. This transient recovered; it does not reproduce the persistent never-hosted state. Another existing extra shared the autosave name, so name-only server matches are insufficient.

[steipete]

Current main includes #3825’s zero-width creation, stable-name assignment, and normal-sizing sequence. The later thread evidence also describes a separate case where the window record exists but pixels disappear; the previous isolated maintainer test did not reproduce it. A missing-window recovery rule would not cover both cases. Keeping this open for current-build dual-display/appearance reproduction with matched bounds and rendered-content evidence.

[steipete]

Current source still does not classify a live AppKit window with no matching named server record as blocked. However, the later 0.59.0 evidence also shows invisible content while that record remains present, and the signed isolated experiment did not reproduce the failure. A missing-name heuristic would not establish a fix. Keeping this open for a matched AppKit/Quartz geometry and rendered-content capture on the affected display and appearance setup.