Codex Desktop window never appears on macOS 26.4 — all processes running but window count stays 0

Open 💬 2 comments Opened Jul 6, 2026 by buyicoder

Summary

Codex Desktop launches successfully on macOS 26.4 (beta) — all 14 processes start normally (main, GPU, network, storage, 2 renderers, app-server) — but the main window never appears. osascript -e "tell application \"Codex\" to get count of windows" consistently returns 0.

Clicking the Dock icon has no effect. open -a Codex returns exit code 0 but no window is created. The app appears to be "running" in the background but is completely unusable.

Environment

  • macOS: 26.4 (25E246) — beta
  • Codex Desktop: 26.623.101652 (4674)
  • Codex Framework: 149.0.7827.197
  • codex-cli: 0.142.5
  • Auth mode: chatgpt (token valid, last refreshed 2026-07-04)
  • Hardware: Apple Silicon Mac

Symptoms

  • All 14 Codex processes start and remain running (verified via pgrep)
  • 2 renderer processes are active (renderer-client-id=5 and renderer-client-id=6)
  • codex app-server is running and responsive
  • Git plugin sync completes normally (openai/plugins, compound-engineering-plugin)
  • logs_2.sqlite is recreated normally after deletion
  • But window count is always 0 — no UI is ever visible

Troubleshooting attempted (all unsuccessful)

Every one of these was attempted with a full process restart (killall -9) and verification:

| Step | Action | Result |
|---|---|---|
| 1 | Graceful quit + restart | Window still 0 |
| 2 | Force kill all processes + restart | Window still 0 |
| 3 | Renamed logs_2.sqlite (was 313MB, see #31111) | Window still 0 |
| 4 | Cleared GPU cache (GraphiteDawnCache/) | Window still 0 |
| 5 | Removed Electron Singleton lock files | Window still 0 |
| 6 | Reset electron-main-window-bounds to defaults | Window still 0 |
| 7 | Fixed onboarding state (welcome-pending → false) | Window still 0 |
| 8 | Launched with --disable-gpu --disable-software-rasterizer | Window still 0 |

Key observations

  1. No crash reports in ~/Library/Logs/DiagnosticReports/ — the app does not crash, it simply never creates a window
  2. Crashpad pending/ has 187 historical dump files but no new ones from current launches
  3. The logs_2.sqlite file had grown to 313MB due to high-frequency TRACE logging (matches #31111 exactly — same macOS 26.4.1, same app version)
  4. All renderer processes are alive and consuming normal CPU — they are rendering something, but no visible window is produced
  5. Launching the binary directly from CLI reports "正在现有的浏览器会话中打开" (opening in existing browser session) and exits

Related issues

  • #31094 — Same Framework version (149.0.7827.197) crashes in CrBrowserMain on macOS 26.6. Our case may be a non-crashing variant of the same root cause.
  • #31111 — Same app version on macOS 26.4.1 writes high-frequency TRACE logs to logs_2.sqlite. We observed the same 313MB bloat.
  • #31090 — Renderer crashes after subagent wait — may share a common rendering-layer instability.

Hypothesis

The temporal_rs library ( implicated in #31094's temporal_rs_PlainDateTime_hour crash ) may have a compatibility issue with macOS 26.x's system libraries. In our case, instead of crashing with EXC_BREAKPOINT, the renderer silently fails to produce a visible window — possibly because the error is caught internally but leaves the window creation in an unrecoverable state.

Expected behavior

Codex Desktop should create and display its main window on macOS 26.4.

Workaround

The codex CLI works normally. The codex app-server process also runs fine — only the Electron GUI window is affected.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗