Mission Control Issue

[phuchong89]

Environment

• CodexBar: 0.50.0 (121)
• macOS: 27 Public Beta
• Hardware: Apple Silicon Mac - 15" M5 MBA

Description

When CodexBar is running, Mission Control immediately dismisses.

Mission Control opens for a split second and then closes automatically.

This happens when using:

• Four-finger swipe up
• F3 (Mission Control)
• Control + ↑

Steps to reproduce

1. Launch CodexBar.
2. Trigger Mission Control.
3. Mission Control appears briefly and immediately closes.
4. Quit CodexBar.
5. Mission Control works normally.
6. Relaunch CodexBar.
7. The problem immediately returns.

Expected behavior

Mission Control should remain open until a window or desktop is selected.

Actual behavior

Mission Control closes immediately after opening.

Notes

• 100% reproducible.
• Quitting CodexBar immediately restores normal Mission Control behavior.
• No Karabiner installed.
• No other window manager running.

[clawsweeper]

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

Summary
The current-release report gives a detailed, repeatable native macOS path, but source inspection cannot safely identify one cause without macOS 27 runtime isolation. This issue remains necessary.

Reproducibility: no. in this review environment: the reporter provides a detailed 0.50.0/macOS 27 path, but this checkout cannot run the required macOS UI runtime to verify it on current main.

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
A macOS 27 runtime owner should reproduce and isolate the triggering event path before selecting a repair boundary.

Review details

Best possible solution:

Reproduce on macOS 27 with a freshly built bundle, isolate launch-time consent activation and the global menu shortcut separately, then make the smallest guarded fix with a focused regression seam.

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

No in this review environment: the reporter provides a detailed 0.50.0/macOS 27 path, but this checkout cannot run the required macOS UI runtime to verify it on current main.

Is this the best way to solve the issue?

Unclear: source identifies relevant activation and input surfaces, but it does not prove which one dismisses Mission Control; runtime isolation should precede a code change.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Changing global shortcut, launch activation, or AppKit menu-tracking behavior without a macOS 27 reproduction could regress the configurable menu shortcut or consent flow.

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

Label changes

Label changes:

• add P2: Mission Control is consistently disrupted on the reported current release, but the affected scope and source cause are not yet verified.
• add impact:ux-friction: The report describes a repeatable system-UI disruption that is recoverable by quitting CodexBar but materially impairs normal desktop use.
• add issue-rating: 🦪 silver shellfish: 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.

Label justifications:

• P2: Mission Control is consistently disrupted on the reported current release, but the affected scope and source cause are not yet verified.
• impact:ux-friction: The report describes a repeatable system-UI disruption that is recoverable by quitting CodexBar but materially impairs normal desktop use.

Evidence reviewed

What I checked:

• Reporter’s current-release path: The issue identifies CodexBar 0.50.0 on macOS 27 Public Beta, gives three independent ways to invoke Mission Control, and reports that quitting CodexBar restores normal behavior.
• Launch-time activation path: After launch, CodexBar checks whether adaptive activity consent is needed; that path intentionally activates the app and presents a modal alert when the setting is agent-aware with undecided consent. (Sources/CodexBar/AdaptiveActivityConsentPresenter.swift:8, f15f142a7787)
• Global shortcut integration: The app registers the configurable open-menu action at launch; its callback only opens or closes the status-item menu when the configured shortcut fires. (Sources/CodexBar/CodexbarApp.swift:447, f15f142a7787)
• Menu event handling is scoped: The provider-switcher monitor is installed only for an open CodexBar menu and runs only during that menu’s tracking session, so it does not alone explain a failure immediately after launch. (Sources/CodexBar/StatusItemController+ProviderSwitcher.swift:230, f15f142a7787)
• History and release check: Reachable blame attributes the present shortcut and tracking code to the v0.50.0 source tree; main at f15f142 only adds an unreleased 0.50.1 changelog section and does not establish a fix. (Sources/CodexBar/CodexbarApp.swift:447, 0e453c4a5b2a)
• Maturity taxonomy unavailable: The required shortlist helper could not assess maturity because this checkout has no qa/maturity-scores.yaml scorecard; no maturity label is selected.

Likely related people:

• Peter Steinberger: Reachable blame ties the current global-shortcut registration and menu-tracking implementation to the v0.50.0 source tree; earlier history is unavailable locally. (role: recent area contributor; confidence: medium; commits: 0e453c4a5b2a; files: Sources/CodexBar/CodexbarApp.swift, Sources/CodexBar/StatusItemController+ProviderSwitcher.swift, Sources/CodexBar/AdaptiveActivityConsentPresenter.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.

[phuchong89]

I've attached a short screen recording demonstrating the issue.

What the recording shows

1. CodexBar is running.
2. Triggering Mission Control (four-finger swipe) causes Mission Control to appear briefly and then immediately dismiss.
3. Quitting CodexBar immediately restores normal Mission Control behavior.
4. Relaunching CodexBar immediately causes the issue to return.

Expected behavior

Mission Control should remain open until the user selects a window or desktop, regardless of whether CodexBar is running.

Actual behavior

Whenever CodexBar is running, Mission Control opens for a split second and immediately closes. The behavior is 100% reproducible on my machine.

Hopefully the attached recording helps reproduce and isolate the issue.

Screen Recording 2026-08-15 at 6.52.12 PM.mov.zip

[steipete]

Ran a full audit of every code path that could plausibly dismiss Mission Control (window ordering, app activation, activation-policy flips). No smoking gun at rest — there's no timer that activates the app or flips policy — but three ranked suspects and a 2-minute test that will pin it down:

Ranked suspects

1. Lifecycle keepalive window — CodexBar keeps an invisible (alpha-zero, 1×1, floating, all-Spaces) window onscreen for the app's lifetime, and WindowServer does count it as onscreen. A macOS 27 beta Mission Control regression around such windows is the best behavioral match for "opens for a split second then closes".
2. Dock policy observer — activates/changes activation policy only when a Settings/update window newly appears; shouldn't fire at rest, but beta behavior around hidden Sparkle windows is unverified.
3. OpenAI web-extras scraper — the only recurring background orderFrontRegardless() (an almost-offscreen floating window), normally every ~10 minutes.

Please try this (takes ~2 minutes):

1. Settings → Codex → disable OpenAI web extras, relaunch CodexBar, wait 30s, retest Mission Control. If fixed → suspect 3 confirmed.
2. If not fixed, run this in Terminal while triggering Mission Control a few times:

while true; do date '+%T.%N'; lsappinfo info -only ApplicationType -app com.steipete.codexbar; sleep 0.2; done | tee ~/Desktop/codexbar-2955-activation.txt

If ApplicationType ever changes from UIElement to Foreground at the dismissal moment → suspect 2 confirmed. If it never changes and the web-extras toggle didn't help → suspect 1 (the keepalive window), which we can rework to be genuinely offscreen on macOS 27.

Also worth one quick check: does the dismissal stop immediately when you quit CodexBar (to rule out another menu-bar app interacting)? Thanks — with that output this becomes a one-line diagnosis.