Codex panel frequently fails to load — blank or stuck on logo, then VS Code hangs until unresponsive (macOS, Apple Silicon)

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #33968
• #34184

Powered by Codex Action

Redacted log excerpts — usernames, file paths, UUIDs, thread/task IDs, project/plugin names and internal IDs have been stripped.

The two logs line up with the "renderer/webview hang, backend healthy" picture:

1. VS Code main process (main.log) — the window hang. The main process records the window going unresponsive, and the unresponsive samples repeatedly point at a WebSocket message handler; the render frame is then disposed, while the extension host exits cleanly (code 0). It also recurred the previous evening.

2026-07-18 21:10:32  CodeWindow: detected unresponsive
2026-07-18 21:10:32  UnresponsiveSampleError: from window with ID 6
                     CodeWindow unresponsive samples:
                       <4> at WebSocket._socketMessageListener (workbench.desktop.main.js:5177)
                       <1> at workbench.desktop.main.js:1076
2026-07-18 21:10:32  Extension host exited with code: 0

2026-07-19 16:55:33  CodeWindow: detected unresponsive
2026-07-19 16:55:45  CodeWindow: recovered from unresponsive
                     CodeWindow unresponsive samples:
                       <4> at workbench.desktop.main.js:1076:10604
                       <1> at WebSocket._socketMessageListener (workbench.desktop.main.js:5177:124590)
2026-07-19 16:56:48  CodeWindow: detected unresponsive
2026-07-19 16:57:13  [uncaught exception in main]: Error: Render frame was disposed before call stack was received
2026-07-19 16:57:13  Extension host exited with code: 0

2. Codex extension host (Codex.log) — the ~5-minute UI stall + DB corruption. The extension activates and the app-server initializes immediately, but the React root render is not requested until ~5 minutes later; separately, an app-server state DB operation fails with database disk image is malformed (SQLite code 11).

2026-07-19 16:57:29.520  Activating Codex extension
2026-07-19 16:57:29.767  [CodexMcpConnection] Initialize received id=1
        (… ~5 minutes with no render …)
2026-07-19 17:02:29.436  [statsig-refresh-diagnostics] React root render requested windowType=extension
2026-07-19 17:02:30.409  [startup][renderer] app routes mounted after 1464ms
2026-07-19 17:12:40.785  thread/delete failed: "failed to delete app-server state for <redacted>: database disk image is malformed" (code 11)
2026-07-19 17:12:41.019  codex_rollout::list: state db discrepancy … falling_back

Happy to share fuller redacted logs or a CPU profile of the hang (VS Code suggests https://aka.ms/vscode-tracing-cpu-profile) if that would help.

Follow-up: a controlled re-reproduction points to a Codex WebView resource-loading bug (macOS)

I re-ran this as a controlled test after neutralizing the disk/cache angle, and it still reproduced with everything else healthy — which isolates the failure to the Codex WebView frontend, not Docker, SQLite, or the cache.

Control reproduction (devcontainer; shared cache already cleared).

• Codex app-server initialized in ~25 ms, but the WebView never reached React root render requested — it hung on loading.
• In the same container, another WebView-based extension rendered its panel in ~1.28 s — so the container and VS Code's webview infrastructure are fine; the stall is specific to Codex.
• VS Code then logged a listener leak in doReadFileStream → loadResource (~4:34), and the window renderer went unresponsive (~4:56).
• Not resource starvation: container OOMKilled=false; both container databases are healthy (state_5.sqlite and logs_2.sqlite each PRAGMA quick_check = ok); and the shared volume had already been trimmed before this run, so its former size can't explain the recurrence.

So Docker, permissions, devcontainer.json, SQLite integrity, OOM, and cache size are all ruled out for this failure.

Same fingerprint as #33968. #33968 (also VS Code 1.129.1) shows the identical signature: the extension logs Initialize received id=1 and then goes silent, with React root render requested only appearing on the launches that recover. In an earlier captured hang on my machine that gap was ~5 minutes:

<details><summary><code>Codex.log</code> — ~5-min activation→render stall (redacted)</summary>

2026-07-19 16:57:29.520  Activating Codex extension
2026-07-19 16:57:29.767  [CodexMcpConnection] Initialize received id=1
        (… ~5 minutes with no render …)
2026-07-19 17:02:29.436  [statsig-refresh-diagnostics] React root render requested windowType=extension
2026-07-19 17:02:30.409  [startup][renderer] app routes mounted after 1464ms

</details>

<details><summary><code>main.log</code> — VS Code window hang; unresponsive samples hit a WebSocket message handler (redacted)</summary>

2026-07-19 16:55:33  CodeWindow: detected unresponsive
2026-07-19 16:55:45  CodeWindow: recovered from unresponsive
                     CodeWindow unresponsive samples:
                       <4> at workbench.desktop.main.js:1076:10604
                       <1> at WebSocket._socketMessageListener (workbench.desktop.main.js:5177:124590)
2026-07-19 16:56:48  CodeWindow: detected unresponsive
2026-07-19 16:57:13  [uncaught exception in main]: Error: Render frame was disposed before call stack was received
2026-07-19 16:57:13  Extension host exited with code: 0

(The extension host always exits cleanly with code 0 — not an ext-host crash.)
</details>

Likely mechanism — WebView asset/resource bootstrap. The loadResource listener leak above, plus the size of the frontend, point at resource loading:

• The installed macOS extension ships a ~147 MB WebView bundle with ~4,959 asset files.
• microsoft/vscode#326272 (merged 2026-07-17) caps concurrent host-backed WebView resource streams to 32 because extensions "like Codex" fired ~625 concurrent requests and exhausted the renderer's file-descriptor budget on Linux. The FD mechanism is Linux-specific and unproven on macOS, but the loadResource stack and scenario line up.
• #33032 is a related asset-loading failure: after an in-place extension update, VS Code's webview service-worker cache resolves webview/assets/*.js against the deleted previous extension dir → net::ERR_FAILED, React never mounts, only the logo shows, backend green. My extension had updated ~1 day before the repro; I'll capture the WebView DevTools console next time it hangs.

Separate, independent problems (not the cause here).

• Host ~/.codex/logs_2.sqlite still fails PRAGMA quick_check. That's a real defect that can affect Codex outside the container, but the container's own DBs are healthy while the WebView still hangs — so it doesn't gate the WebView.
• The shared Docker volume had bloated to ~29.7 GB (Codex a minority, ~5.2 GB across 46 cached versions) — a disk/IO/version-accumulation problem, but not the cause of the hang.

Would help (maintainer asks):

• Timeout + explicit in-panel error when the WebView never reaches React-root render, instead of hanging indefinitely.
• Surface failed WebView asset requests (net::ERR_FAILED / blocked vscode-webview) into the Codex output channel.
• Version-stamped asset URLs after an in-place update (per #33032).
• Cap concurrent WebView resource loads on all platforms (aligning with vscode#326272).
• Safe auto-recovery/rebuild of a corrupted logs_2.sqlite.

Related: #33968, #34184, #33032.

Confirming a closely related reproduction on macOS / Apple Silicon.

• VS Code 1.129.1 (arm64) and Codex extension 26.715.31925: the same version pair as this issue.
• Difference in timing: the Codex webview initially mounted successfully (React root render requested and app routes mounted), then later became gray / unresponsive while reasoning and tool updates were streaming.
• The extension log recorded 84 occurrences of ResizeObserver loop completed with undelivered notifications from 09:45:51 to 10:28:30, repeatedly adjacent to reasoning-summary item events.
• It also recorded Item not found in turn state, 57 state db discrepancy ... falling_back messages, and unhandled broadcasts including thread-stream-following-changed, thread-read-state-changed, and client-status-changed. The extension reported thread_tools as enabled while the bundled CLI logged it as an unknown feature key.
• There were no webview/assets or net::ERR_FAILED messages in this occurrence, so this does not appear to be exclusively the stale service-worker asset-path failure mode.
• An ipc-connection-reset followed by extension reactivation recovered the renderer: the next startup again logged app routes mounted, and no further ResizeObserver errors appeared during the captured period.

This looks like a related streaming/event-state/layout variant: the backend remains active but the webview renderer degrades after mounting. I can provide further redacted log excerpts if useful.