Codex chat panel never renders (permanently blank) — uncaught Monaco worker crash, reproducible across versions

What version of the IDE extension are you using?

26.707.31123 (also reproduced identically on 26.715.61943)

What subscription do you have?

Plus

Which IDE are you using?

VS Code 1.129.1

What platform is your computer?

Linux 6.8.0-136-generic x86_64 x86_64

What issue are you seeing?

The Codex sidebar/panel view never renders any content — it stays permanently blank/grey. The extension host activates normally, spawns the codex app-server backend process, and completes an Initialize handshake with no error. The failure is entirely inside the webview and produces no output in the extension's own log — only visible via Developer: Open Webview Developer Tools.

Root cause, from the webview console:

1. Could not create web worker(s). Falling back to loading web worker code in main thread, which might cause UI freezes. — Monaco's attempt to create a real web worker fails in this webview context.
2. You must define a function MonacoEnvironment.getWorkerUrl or MonacoEnvironment.getWorker — logged from the extension's own bundle at index.js:25. The webview never supplies this required Monaco configuration.
3. The fallback path then tries to resolve a worker module's URI and gets undefined, throwing:

TypeError: Cannot read properties of undefined (reading 'toUri')
at aP.toUri (index.js:22:12568)
at aP.asBrowserUri (index.js:22:12021)
at index.js:36:30380
at new Promise (<anonymous>)
at TS.$loadForeignModule (index.js:36:30242)
at index.js:631:7593

1. This becomes an uncaught error, which appears to abort the panel's initialization at this exact point — nothing renders after it.
2. Immediately after, VS Code's own resource loader enters a runaway retry loop that never resolves, leaking event listeners on every attempt (pde.readFileStream → TQe.loadResource), climbing continuously with no upper bound observed (175 → 263 → 351 → 403 → 491 → 579... over several minutes with the panel left open).

Ruled out before concluding this is the actual cause:

• Not a corrupted install — reproduced after a full uninstall/reinstall
• Not GPU/hardware acceleration — reproduced with disable-hardware-acceleration: true confirmed active
• Not the separate localResourceRoots/net::ERR_FAILED resource-loading bug present in 26.715.61943 — that one is real and distinct, and downgrading to 26.707.31123 fixes it, but this Monaco crash persists in both versions
• Not proxy, locale, or filesystem-permission related

Secondary issue in the same session, possibly unrelated:
Loading the font 'data:font/ttf;base64,...' violates the following Content Security Policy directive: "font-src 'self' https://.vscode-cdn.net". The action has been blocked.

For context: the same symptom (asBrowserUri/toUri crash tied to Monaco worker failures) has also been reported against a different VS Code extension entirely (Anthropic's Claude Code, anthropics/claude-code#69632 and #59030) — suggesting this is a known pitfall for extensions bundling Monaco in a webview without wiring up the main-thread worker fallback correctly.

Workaround: none for the panel. The extension's own bundled CLI binary (bin/<platform>/codex) works correctly and is unaffected, since it doesn't use a webview.

What steps can reproduce the bug?

Install the Codex extension in VS Code (reproduced on 26.707.31123 and 26.715.61943).
Open the Codex chat panel/sidebar.
While the panel is focused, open Developer: Open Webview Developer Tools (Command Palette).
In the Console tab, observe: Could not create web worker(s) → You must define a function MonacoEnvironment.getWorkerUrl or MonacoEnvironment.getWorker → an uncaught TypeError: Cannot read properties of undefined (reading 'toUri') → a runaway listener-leak loop in pde.readFileStream/TQe.loadResource.
The panel itself never renders any content — it stays blank/grey indefinitely, with no error visible anywhere except in that devtools console.
That's the exact sequence from the two sessions we captured tonight — steps 1–3 are what triggers it, step 4 is what you'll see if you check, step 5 is the visible symptom.

What is the expected behavior?

Opening the Codex panel should initialize the webview and render the chat interface — model selector, input box, conversation area — the same way it does when the bug isn't present. Instead, the panel stays permanently blank/grey; nothing ever renders, and no error is shown to the user anywhere in the UI itself (only visible via webview devtools).

Additional information

Searched for existing reports before filing, including GitHub's own issue search for "toUri" MonacoEnvironment in this repo (zero results) and four individually-checked "blank panel" issues (#9615, #2923, #4982, #28280) — each of those has a different root cause (service worker registration, 401 auth errors, no error detail, or unrelated). This appears to be a distinct, previously unreported cause.

Also reproduced in Google Antigravity (a VS Code fork) under the same conditions — though Antigravity has an additional, separate blocker on top (a missing chatSessionsProvider API proposal grant preventing the panel from registering at all there), so that environment isn't a clean second data point for this specific bug, just corroborating that it isn't tied to one specific VS Code build.