Windows Codex Desktop becomes unstartable after adding a second folder to an existing project

Confirmed on the same Store build (26.721.3404.0) with an additional deterministic repro and renderer diagnostics.

Environment for this repro:

• Windows 10 Home x64, build 19045
• Package OpenAI.Codex_26.721.3404.0_x64__2p2nqsd0c76g0
• Affected project had two nested roots rather than two unrelated folders:

{
  "rootPaths": [
    "C:\\<workspace>\\ExampleProject",
    "C:\\<workspace>"
  ]
}

Additional repro path:

1. Temporarily changing only selected-project to an existing single-root project allowed Desktop to launch.
2. Opening an older Codex-managed worktree task assigned to the two-root project reselected that project and immediately returned the app to the full-page error state.
3. Closing Desktop and changing only that project's rootPaths to one entry in both global-state files allowed Desktop to launch with the same project still selected; the older task was usable and fresh logs contained no new fatal error.

Exact renderer log signature:

error [electron-message-handler] error boundary
errorMessage="process is not defined"
errorName=Error
name=AppRoutes

The repeated component stack begins at:

at S3s (app://-/assets/app-initial-_qVLmrD6.js:8875:151178)

A read-only inspection of the packaged renderer suggests a possible cause (hypothesis, not confirmed source-level diagnosis): the multi-root filtering path calls a path-browserify POSIX relative() operation on normalized strings shaped like win32:c:/.... With two roots, resolution can fall back to process.cwd(), but the sandboxed renderer has no Node process global. With one root, the pairwise comparison short-circuits before that branch.

This also confirms the bug is not limited to a particular second-folder type, special character, or malformed JSON: the transition from one saved root to two is the shared trigger.

I initially filed #35061 before seeing this earlier report; it contains the longer diagnostic write-up and will be closed as a duplicate of this issue.

+1，This is a very serious bug. I strongly suspect Codex was released without testing.

Codex版本：26.721.30844
电脑运行版本：Windows 11 家庭版 中文版 25H2
问题描述：在已有项目任务中添加新的文件夹项目后，Codex出现崩溃。
问题现象：
<img width="958" height="613" alt="Image" src="https://github.com/user-attachments/assets/231332c9-db27-4a05-a822-c6e12d3ead89" />

暂时解决方案：回退用户下的.codex中的.codex-global-state.json、.codex-global-state.json.bak的rootPaths中读取的项目路径
<img width="653" height="230" alt="Image" src="https://github.com/user-attachments/assets/03c46350-d8c7-476e-ba35-a5b535df320b" />

I can confirm this issue.

I updated to the latest Windows desktop build today, tried the new ability to add a second folder to an existing project, and immediately hit the same full-screen "An error occurred" page. After that, every restart returned to the same screen, making the app unusable.

The workaround described in this issue is effective. After removing the second entry from rootPaths in both .codex-global-state.json and .codex-global-state.json.bak, the application started normally again and my existing project history was preserved.

Thank you to everyone who investigated the root cause and shared the workaround. Looking forward to seeing multi-folder projects become stable on Windows, since it's a very useful feature for real-world development workflows.

I encountered the same issue, and following the original poster’s workaround resolved it successfully.

A bug this serious, and this easy to reproduce… and they still shipped it?

It was inevitable given the app's daily releases.

真的不敢想象，这么容易出现的bug，竟然没有被测

Additional confirmation: nested roots and an existing project are not required. I reproduced this through the advertised multi-source flow while creating a brand-new project.

Environment

• Codex Desktop (Microsoft Store): 26.721.3404.0
• Renderer/Sentry release: codex@26.721.30844
• Windows 11 Pro x64: 10.0.26200
• Package status after the failure: Ok (Store-signed MSIX)

Reproduction variant

1. Update Codex Desktop to the build above.
2. Choose the UI flow to create a new project.
3. Give it a normal display name.
4. Add two separate existing local source folders during creation, represented here as:

%USERPROFILE%\SourceA
%USERPROFILE%\SourceB

1. Finish creating/selecting the project.
2. The app enters the full-page Oops, an error has occurred fallback. Subsequent launches return to the same screen because the new project remains selected.

Both folders in this reproduction were:

• unrelated and non-nested
• normal directories on the same local C: drive
• not Git repositories

The saved state remained valid JSON and contained the expected two-root shape:

{
  "name": "<NEW_PROJECT>",
  "rootPaths": [
    "%USERPROFILE%\\SourceA",
    "%USERPROFILE%\\SourceB"
  ]
}

Renderer evidence

The fresh Sentry scope repeatedly recorded:

ReferenceError: process is not defined
    at Object.resolve (app://-/assets/app-initial-_qVLmrD6.js:45:62687)
    at Object.relative (app://-/assets/app-initial-_qVLmrD6.js:45:63314)
    at Array.every (<anonymous>)
    at Array.filter (<anonymous>)
    at wFi (app://-/assets/app-initial-_qVLmrD6.js:4865:3287)
    at S3s (app://-/assets/app-initial-_qVLmrD6.js:8875:151232)

The router also warned that the matched leaf route at / had no element/component and would render an empty outlet.

A/B recovery result

With Codex fully closed, I backed up the global state, removed only the newly created two-root project from local-projects / project-order, and restored a known one-root project as selected-project.

After relaunch:

• the app rendered normally
• the existing projects, sessions, settings, and authentication remained intact
• the package still reported Status: Ok
• the main window was responsive
• the fresh renderer session reported errors: 0

No reinstall, package reset, cache clear, or authentication reset was needed.

This broadens the trigger from “adding a second folder to an existing project” to creating any selected Windows project with multiple source folders, including two unrelated non-Git directories. Since multiple sources are exposed as a supported project feature, the app should validate/recover this state rather than persist a project that prevents the entire shell from starting.

I performed a read-only inspection of the packaged renderer from build 26.721.3404.0. This appears to identify the concrete failure path behind the existing process is not defined renderer error.

The multi-root filtering logic calls the POSIX implementation of relative() on normalized Windows identifiers, effectively:

pathBrowserify.posix.relative(normalize(rootA), normalize(rootB))

For Windows roots, the normalization result is shaped like:

win32:/mnt/c/...

That value does not begin with /, so path-browserify's POSIX resolve() treats it as relative and falls back to process.cwd(). In the sandboxed renderer there is no Node process global, producing:

ReferenceError: process is not defined

This also explains the one-root/two-root A/B behavior: with one root, the self-comparison short-circuits before relative() is called; with two distinct roots, the comparison reaches that branch and the renderer crashes.

I reproduced the same behavior with an isolated equivalent of the packaged logic: one normalized root completes normally, while two distinct win32: roots throw ReferenceError: process is not defined when evaluated without a process global.

The fix should avoid passing win32: identifiers to the POSIX relative() implementation, or otherwise ensure the path representation is truly absolute before resolution. A platform-aware path comparison would likely be safer.

No application bundle or private paths are attached here.

I can confirm that this is still reproducible in the newer Microsoft Store package 26.721.3996.0 (after the originally reported 26.721.3404.0 build).

The packaged renderer follows the same failure path described above:

1. The multi-root label/filter helper calls path.posix.relative(normalize(rootA), normalize(rootB)).
2. Windows roots normalize to identifiers such as win32:/mnt/c/....
3. Because that identifier is not POSIX-absolute, path-browserify falls back to process.cwd().
4. The sandboxed renderer has no Node process global, so selecting any project with two distinct roots throws ReferenceError: process is not defined.
5. A one-root project avoids the call because the pairwise comparison short-circuits.

A renderer-side fix should avoid passing scheme-prefixed path identities to path.posix.relative. The safer approach is to parse the normalized scheme/drive and compare path segments only when the roots share the same origin; roots on different drives should be treated as unrelated. A smaller fix would first convert the normalized identity to a genuinely absolute POSIX sentinel path before calling relative, but the drive/scheme-aware comparison is less error-prone.

Suggested regression matrix (with globalThis.process absent, matching the sandboxed renderer):

• one Windows root
• two nested roots on the same drive
• two unrelated roots on the same drive
• roots on different drives

For each case, selecting/rendering the project and its file-search labels should not throw, and distinct roots should remain distinguishable.

I checked the public openai/codex tree, but the Desktop React/Electron renderer containing this helper is not present there. The repository's contribution policy also says external PRs require a maintainer invitation. If a maintainer can point me to the relevant source location and invite a targeted contribution, I am happy to submit the focused fix and regression tests.

Confirmed on the newer Microsoft Store stable package OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0 on Windows 11 x64 (build 22621).

The selected local project had exactly two distinct roots. On every launch, the primary window failed in AppRoutes with:

errorMessage="process is not defined"
errorStack="Error: process is not defined"
rendererWindowAppearance=primary
app://-/assets/app-initial-DVfVy4b5.js

The same error was also emitted for hotkeyWindowHome and hotkeyWindowThread.

Additional A/B results:

• Store reports no newer stable package.
• Package status is Ok.
• Rebuilding Code Cache, GPUCache, DawnGraphiteCache, and DawnWebGPUCache does not help.
• A full application restart reproduces the identical error at a new timestamp.
• The official Beta package OpenAI.CodexBeta_26.715.3651.0 starts normally on the same machine and reads the same CODEX_HOME; its logs contain no equivalent error boundary.
• SQLite quick checks for goals, memories, and state all return ok, confirming that this is a renderer regression rather than local data corruption.

No private paths, project names, account details, or logs containing user content are attached.

Additional confirmation from a Windows 11 system on the newer Microsoft Store build 26.721.3996.0.

Environment

• Windows 11 Enterprise x64, build 26200, zh-CN
• Codex package: OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0
• App server: 0.146.0-alpha.3.1

Trigger and evidence

The selected local project was the only project in the saved state with exactly two unrelated Windows roots. Adding the second folder was followed by the full-page error. Across three launches, the renderer emitted the same failure seven times:

error [electron-message-handler] error boundary
errorMessage="process is not defined"
errorName=Error
name=AppRoutes
componentStack="at C3s (app-initial-DVfVy4b5.js:8875:151178) ..."

The surrounding thread/list and thread/read calls completed with errorCode=null. Read-only integrity checks also passed:

• state_5.sqlite: PRAGMA quick_check = ok
• logs_2.sqlite: PRAGMA quick_check = ok
• session_index.jsonl: 164 valid JSON lines, 0 invalid

This rules out chat/session database corruption on this machine.

A read-only inspection and isolated execution of the packaged renderer path reproduced the same exception. The multi-root comparison calls the POSIX relative() implementation with normalized Windows identifiers shaped like win32:e:/.... Because those identifiers are not POSIX-absolute, the bundled path implementation falls back to process.cwd(); the sandboxed renderer has no Node process global. With one root, the pairwise comparison short-circuits before reaching that branch.

Validated recovery / workaround

1. Fully quit Codex Desktop.
2. Back up both files:

• %USERPROFILE%\.codex\.codex-global-state.json
• %USERPROFILE%\.codex\.codex-global-state.json.bak

1. In each file, locate the affected entry under local-projects (the project referenced by selected-project).
2. Change only that project's rootPaths from two entries to one by preserving the original first root and removing the newly added second root.
3. Relaunch Codex.

Do not delete chats, sessions, SQLite databases, skills, configuration, authentication, or project files. Reinstalling alone is unlikely to help because the persisted multi-root state can survive the reinstall.

After changing only those two rootPaths arrays, both files remained valid and the semantic diff contained no other change. The same app build then started normally, fresh logs contained 0 process is not defined errors, chat list/read operations succeeded, and the user confirmed the UI was restored. Existing chat history and project files were preserved.

No private paths, project names, account details, or conversation IDs are included here.

Confirmed on a newer Windows build with a larger multi-root project.

Environment

• Codex Desktop: 26.721.3996.0
• Windows 11 Pro Insider Preview, x64, build 28020
• Primary root: Git repository
• Saved project: 8 configured local roots (7 Git repositories plus 1 ordinary data directory)
• A generated worktree adds one more writable root at task runtime (requestSandboxWritableRootCount=9)

Reproduction and isolation

1. Open any task assigned to the affected multi-root project.
2. thread/read succeeds.
3. The renderer immediately enters its error boundary and returns to the home/previous conversation.
4. The app process stays alive; there is no Windows Application Error/Hang event.

This reproduces with both:

• an older task whose session source was subagent; and
• a newly created, normal user-owned task containing only a minimal prompt and a one-sentence final answer.

Therefore the saved conversation content/source is not the trigger.

I also repaired a missing local refs/remotes/origin/HEAD pointer in the primary repository and confirmed all configured directories exist. The renderer failure was unchanged, so Git default-branch discovery is not the cause.

The deterministic log sequence is:

response_routed conversationId=<redacted> errorCode=null method=thread/read
error [electron-message-handler] error boundary errorMessage="process is not defined" errorName=Error errorStack="Error: process is not defined" name=AppRoutes

The task route then falls back to the home/previous conversation. This happened on each controlled open.

The project and task history remain intact. Archiving the original task and creating a clean replacement does not help while the project retains multiple roots.

I am applying the same recovery described in this issue: preserve backups of the session/global state, then reduce the affected project's rootPaths to only its primary Git repository in both .codex-global-state.json and its .bak copy while Codex is closed.

This confirms the multi-root renderer regression persists in 26.721.3996.0, and adds the exact frontend exception signature.

<img width="1980" height="1092" alt="Image" src="https://github.com/user-attachments/assets/767bfb60-cefb-4a39-989f-24eec59d9a9a" />

Having the same issue.

Removed at the user's request.

FIX

Close the app

Go to C:\Users/[username]/.codex

Locate .codex-global-state and .codex-global-state.json.bak and got to an editor

Find the paths of the projects you added, edit them, delete the added project path in all keys, save

Additional deterministic recurrence on Microsoft Store build 26.721.3996.0, with evidence from the persisted migration state.

Reproduction variant

1. Start from a working selected project with one existing local Windows root.
2. Add a second existing local folder through the Desktop project UI.
3. The global state update completed at T0.
4. The primary renderer entered the AppRoutes error boundary at T0 + 273 ms:

errorMessage="process is not defined"
errorName=Error
name=AppRoutes

This has now recurred three times on the same affected build, including after a successful minimal state repair and clean relaunch.

Unfinished migration shape

Both global-state copies were identical, valid JSON. In addition to the selected project's two-entry rootPaths, this recurrence left exactly one matching unfinished migration:

{
  "thread-project-assignment": {
    "cwd": "<PRIMARY_ROOT>",
    "pendingCoreUpdate": true
  },
  "thread-workspace-state-v1": {
    "project": {
      "path": "<PRIMARY_ROOT>"
    },
    "applied": {
      "projectSources": ["<SECONDARY_ROOT>"]
    },
    "pending": {
      "projectSources": ["<PRIMARY_ROOT>", "<SECONDARY_ROOT>"]
    }
  }
}

A prior recurrence on this machine persisted the two-root project with no pending assignment/atom, so both interrupted and apparently completed migration shapes can strand the renderer.

Verified recovery

With Desktop fully stopped:

1. Back up .codex-global-state.json and .codex-global-state.json.bak.
2. Reduce only the affected project's rootPaths to its original first root.
3. For the unfinished shape above, remove only the matching pendingCoreUpdate assignment and its matching workspace atom.
4. Write identical validated JSON to both state copies and relaunch.

No sessions, SQLite databases, configuration, authentication, project files, or unrelated thread records were changed. After relaunch, all Desktop processes were responsive; the fresh log contained 71 successful response_routed entries with errorCode=null and zero new process is not defined errors.

This suggests the UI should both avoid the renderer's process.cwd() path and make the project-source migration transactional/fail-safe so a renderer exception cannot persist an unstartable selected project.

All project names, paths, thread identifiers, and account details are redacted.

Add a second Project folder in 26.721.41059; it seems not to crash.

Encountered a similar problem.

Version: 26.721.41059
Platform:Windows 11

When creating a new project with a Chinese name and selecting two ASCII-only directories as project roots, Codex immediately showed the same error message.

This seems to be related to multi-root projects on Windows.

Fixed in new update, but... about shows '26.721.41059'.

In %USERPROFILE%.codex.codex-global-state.json, locate the affected project under local-projects, find the additional source directory you added in rootPaths, and remove only that directory entry. Then restart ChatGPT.

Confirmed fixed in Codex Desktop 26.721.11231.0, so I’m closing this issue.

Using the same project and folder pair from the original report, I added the second folder again, saved the project, fully restarted Codex, and the app reopened normally with both folders still attached.

I also compared the packaged renderer.

In the affected build, the multi-root filtering logic was equivalent to:

path.posix.relative(
  normalize(root),
  normalize(target)
)

For the normalized Windows paths used by the renderer, this could reach process.cwd() through path-browserify. Because the sandboxed renderer does not expose the Node.js process global, it failed with:

ReferenceError: process is not defined

In 26.721.11231.0, that logic appears to have been replaced with normalized path-prefix comparison equivalent to:

const parent = normalize(root);
const child = normalize(target);

return parent === child
  ? rootIndex > targetIndex
  : !child.startsWith(
      parent === "/" ? parent : `${parent}/`
    );

This removes the observed path.posix.relative() → process.cwd() failure path.

Verified fixed in 26.721.11231.0.