[VS Code][Windows] Codex 26.721.30844 crashes in multi-root workspaces with "process is not defined"

Additional investigation:

I narrowed the reproduction further.

The crash does not depend on any particular project.

Reproduction:

1. Open any single local folder.
2. Verify Codex works.
3. Select File → Add Folder to Workspace...
4. Choose any second local folder.

The Codex panel crashes immediately when the second folder is added.

This reproduces with completely new workspaces as well, so it is not related to:

• existing .code-workspace files
• workspace storage
• project contents
• AGENTS.md
• specific repositories

The trigger appears to be the transition from a single-root workspace to a multi-root workspace.

Additional finding:

The issue is fully reversible without restarting VS Code.

If a second folder is added to the workspace, the Codex panel immediately switches to the error screen.

If that second folder is immediately removed again from the workspace, the Codex panel immediately recovers and returns to the normal UI.

This suggests the extension host does not crash. Instead, the Codex WebView appears to throw an exception while handling the transition from a single-root workspace to a multi-root workspace, and successfully re-renders once the workspace returns to a single root.

Host comparison:

• Microsoft VS Code 1.130.0 + Codex 26.721.30844:

fails immediately when a second workspace folder is added

• Antigravity + the same Codex 26.721 extension:

works normally with the same multi-root workspace

This suggests the issue may depend on differences in the WebView/runtime
environment provided by the host IDE, rather than on the workspace data itself.

Independent reproduction on Windows:

• Windows 11 Pro x64, build 28000
• VS Code 1.130.0
• Multi-root .code-workspace with 2 local folders
• Broken extension: openai.chatgpt@26.721.30844
• Previously working extension: openai.chatgpt@26.715.61943

Timeline and evidence:

1. VS Code automatically installed 26.721.30844 at 09:04 local time, replacing 26.715.61943.
2. After VS Code was restarted, the Codex panel failed to open/render.
3. The extension host successfully activated openai.chatgpt, and the bundled codex.exe app-server remained running, so this was not an extension-host or app-server startup failure.
4. Codex.log repeatedly recorded the webview React error boundary (name=AppRoutes) immediately after app routes mounted. The same log also recorded /settings/user returning HTTP 403, though that may be secondary rather than the root cause.
5. Pre-update logs from 26.715.61943 did not contain the repeated React error-boundary failures in the same workspace.

Workaround used: explicitly install and pin openai.chatgpt@26.715.61943. VS Code's installed-extension manifest now selects the older version. No project files or Codex configuration were changed.

This independently confirms the 26.721.30844 regression in a Windows multi-root workspace.

Confirmed on Windows 11 with VS Code and Codex extension 26.721.30844. Codex worked normally until the extension updated/reloaded. Removing the second folder from my multi-root workspace immediately restored functionality. The Codex CLI continued to work throughout.

This reproduces for me in Antigravity too, contrary to the comment above saying 26.721 works fine there with multi-root — in my case it fails consistently with 3 folders in the workspace (each its own git repo). I also confirmed it's unrelated to a specific folder: a single-folder window always works, regardless of which folder.

Environment: Antigravity IDE (Google, VS Code fork), extension openai.chatgpt 26.721.30844, Windows 11 x64 (10.0.26200.0), ChatGPT Plus.

Using DevTools → Network tab on the Codex webview, I traced the actual failing request. It's not /settings/user (that 403 also showed up for me, but the real blocker seems to be downstream of it):

GetSlashCommands (fetch) returns HTTP 500 repeatedly — 9 consecutive failures in my capture — before eventually succeeding ~200+ seconds after the panel starts loading. By the time it succeeds, the webview has already tripped the React error boundary (name=AppRoutes) and is stuck on the error screen for good, even though the underlying request did eventually return 200.

Response body on every failing GetSlashCommands call:

{"code":"unknown","message":"failed to resolve cascade config: neither PlanModel nor RequestedModel specified. You must specify a valid model."}

Request payload includes a workspaceUris array with every workspace root:

{
  "cascadeConfig": { ... },
  "workspaceUris": [
    "file:///c%3A/Users/<user>/.../repo-a",
    "file:///c%3A/Users/<user>/.../repo-b",
    "file:///c%3A/Users/<user>/.../repo-c"
  ]
}

My read: this looks like a startup race condition — the default model isn't resolved yet when the first GetSlashCommands call fires, and resolving it apparently takes longer the more workspace roots there are to initialize, which is why it only shows up once a second (or third+) folder is present. The 26.715.61943 pin mentioned above as a workaround matches this theory — it's presumably from before whatever change introduced this call's dependency on a resolved model.