Fix Codex VS Code process is not defined in Multi-Root Workspaces

If the Codex panel works with one folder but crashes as soon as you add a second VS Code workspace folder, first open each folder in its own VS Code window. If you must keep a multi-root workspace, install the last known working Codex extension version offered by VS Code, then retest. Do not delete Codex state or patch the extension bundle.

This guide is for one narrow regression: the Codex WebView shows a generic error while Developer Tools reports ReferenceError: process is not defined. It is not a general fix for sign-in failures, network outages, sandbox errors, or the separate Codex Desktop second-folder problem.

Confirm you have this exact failure

The strongest public reports share the same pattern:

• Codex opens in an empty VS Code window.

• Codex opens when VS Code has one folder.

• Adding a second folder, or opening a .code-workspace file with two roots, crashes the Codex sidebar.

• Help > Toggle Developer Tools > Console shows ReferenceError: process is not defined.

• The affected reports used Windows 11 and VS Code 1.130.0. One report identified Codex extension 26.721.30844 as broken and 26.715.61943 as working.

Before changing anything, save open files and note your current versions:

code --version
code --list-extensions --show-versions | findstr /I "OpenAI.chatgpt"

Expected result: the first command prints the VS Code version and commit; the second prints the installed Codex extension ID and version. If code is not on PATH, open Help > About for VS Code and the Codex extension details page for its version.

If Codex also fails in a single-folder window, stop here. Your symptom is different, so a multi-root workaround will only hide the real problem.

Fastest safe workaround: use one root per window

This workaround changes no repository files, sessions, credentials, or extension data.

1. In VS Code, choose File > Close Workspace.

2. Choose File > Open Folder... and open only the folder you need.

3. Open the Codex panel and start a disposable test task such as “List the top-level files without changing them.”

4. If you need the second repository, open it in a separate window.

You can also start two single-root windows from PowerShell:

code -n "C:\src\project-a"
code -n "C:\src\project-b"

Expected result: Codex renders in both windows because each extension instance sees one workspace root. Keep tasks scoped to the repository in their window so file context and approvals stay unambiguous.

VS Code officially supports multi-root workspaces, and its Source Control view can show multiple repositories. Using separate windows is therefore a temporary compatibility workaround for the Codex extension, not a claim that VS Code itself lacks multi-root support.

If you need one multi-root window, roll back the extension temporarily

First check whether a newer Codex extension has been released and test it. The public issues were still open when this guide was researched, so do not assume every later version contains a fix.

If the latest version still reproduces the exact console error:

1. Open the Extensions view with Ctrl+Shift+X.

2. Find Codex - OpenAI's coding agent.

3. Open its gear menu and choose Install Another Version....

4. If 26.715.61943 is offered, select it. That is the version one reproducible report identified as working with the same workspace.

5. Reload the extension host when prompted.

6. Reopen the .code-workspace file and open Codex.

Expected result: the Codex task list and composer render with both folders present, and Developer Tools no longer logs ReferenceError: process is not defined when the panel starts.

Treat the rollback as temporary. An older extension can miss security fixes and product changes. If you pause auto-updates for Codex while waiting, record why, monitor the linked issue, and re-enable updates after a fixed version passes the verification checklist below.

If the reported version is not offered, do not download an unverified VSIX from a mirror. Use separate single-root windows and wait for an official Marketplace version.

Verify the recovery

Run this short matrix after the workaround or an extension update:

Do not declare the issue fixed after the panel merely paints once. Open a new task, switch between both roots, and keep Developer Tools open for at least a minute.

Why the workaround works

One detailed reproduction traced the crash to workspace-root comparison inside the Codex WebView bundle. The bundled browser path implementation reached process.cwd(), but a VS Code WebView does not expose Node.js's process global. The code path appears only when Codex compares multiple roots, which explains why an empty or single-folder window can work while the same extension crashes with two folders.

Using one root avoids the failing comparison. Rolling back restores a bundle that the reporter verified against the same multi-root workspace. Neither workaround repairs the extension; both keep you productive until OpenAI ships and verifies a WebView-safe path implementation.

Do not use these destructive shortcuts

• Do not inject a fake globalThis.process object into the extension. The public shim was diagnostic evidence, not a supported user fix. Marketplace updates will overwrite it, and a partial Node shim can mask other defects.

• Do not delete %APPDATA%\Code, %USERPROFILE%\.vscode, or Codex session files. Clearing state did not fix the detailed reproduction and can destroy unrelated settings or history.

• Do not rotate credentials or reset network configuration. The exact failure occurs during WebView rendering, before an authentication or provider fix would help.

• Do not downgrade VS Code first. The available comparison isolates the Codex extension version while keeping the same VS Code workspace.

If the message instead names CreateProcess, PowerShell, or sandbox permissions, use the Codex Windows sandbox error guide. If the standalone Codex Desktop app shows “Oops” after adding a folder, use the Codex Desktop second-folder recovery guide. Those symptoms have different causes and recovery steps.

Reconnect one real-world tool after Codex is stable

Once the panel passes the read-only test, verify that your restored coding workflow can discover a real integration without changing provider data:

aident account auth status
aident capabilities search --query "GitHub issue search" --targetEnv staging

Expected result: Aident reports an authenticated account and returns read-only GitHub search Actions. This checks the bridge from your local coding agent to managed integrations without exposing a provider key or writing external data.

Connect Aident Loadout and verify one read-only Action.

Sources

• OpenAI Codex issue #35073: Windows multi-root regression and version comparison

• OpenAI Codex issue #35120: WebView stack and root-cause analysis

• OpenAI Codex issue #35208: independent Windows initialization report

• OpenAI Codex IDE extension documentation

• Visual Studio Code multi-root workspace documentation

• Visual Studio Code extension version management

• Official Codex Visual Studio Marketplace listing