[Windows] Desktop renderer crashes when selecting a project with multiple nested roots

Summary

Codex Desktop on Windows enters the full-page Oops, an error has occurred renderer fallback when the selected local project has more than one nested Windows root. The app process remains alive, but the UI is unusable and both Update ChatGPT and Try again have no effect.

This is deterministic when selecting the affected project directly or when opening an older worktree-backed task that reselects that project.

Environment

• Codex Desktop (Microsoft Store): 26.721.3404.0
• Package: OpenAI.Codex_26.721.3404.0_x64__2p2nqsd0c76g0
• Platform: Windows 10 Home x64, 10.0.19045 (build 19045)

Steps to reproduce

1. Have a local project whose persisted entry in %USERPROFILE%\.codex\.codex-global-state.json contains two nested Windows roots, for example:

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

1. Select that project, restart Codex Desktop with it selected, or open an existing task assigned to that project (including a Codex-managed worktree task).
2. The renderer immediately falls into the generic full-page error boundary.
3. Click Try again or Update ChatGPT.
4. Neither action recovers the app.

Actual behavior

The main process stays alive, but the renderer shows only:

Oops, an error has occurred
Update ChatGPT | Try again

The desktop log records:

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

The component stack begins at the same minified renderer component on each occurrence:

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

Expected behavior

Projects with multiple roots, including a repository root plus its parent workspace, should render normally. If a root configuration is invalid, Codex should reject or normalize it without crashing the entire application shell.

Confirmed A/B reproduction and recovery

The following was reproduced twice with backups taken before changing local state:

1. With a two-root project selected, Codex failed on launch with process is not defined / AppRoutes.
2. Changing only selected-project to an existing one-root project allowed the app to launch.
3. Opening an older worktree task assigned to the original two-root project reselected that project and immediately reproduced the same error screen.
4. With Codex fully closed, both .codex-global-state.json and .codex-global-state.json.bak were backed up.
5. Only the affected project's rootPaths was changed from two entries to its repository root alone. The project remained selected.
6. Codex was relaunched with that same project selected. The UI rendered normally, the older task was usable, and the fresh launch logs contained no new process is not defined / AppRoutes error.

Confirmed local recovery shape:

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

This is a recovery workaround, not an application-level fix. Affected users should close Codex and back up both global-state files before attempting it.

Suspected cause (hypothesis from read-only packaged-bundle inspection)

The signed renderer bundle appears to filter workspace roots by calling a path-browserify POSIX relative() operation on normalized values shaped like:

win32:c:/<workspace>/ExampleProject
win32:c:/<workspace>

Those strings are not POSIX-absolute. With two roots, the comparison reaches path-browserify path resolution, which falls back to process.cwd(). The sandboxed renderer has no Node process global, producing process is not defined.

With exactly one root, the pairwise comparison short-circuits on the self-entry, so that relative-path branch is not reached. This explains the observed one-root/two-root A/B result, but the source-level cause should be confirmed by maintainers.

Impact

• Codex Desktop becomes completely unusable on startup.
• The built-in retry/update buttons do not recover it.
• Opening a historical task can re-trigger the failure even after temporarily recovering by switching projects.
• The user must manually repair persisted state while the app is closed.

Screenshot

A screenshot of the full-page error will be attached in the first comment.

Possibly related

#32424 has the same Windows renderer exception signature after managed-worktree creation, but it was closed as resolved in an older build and does not describe this deterministic multi-root project-state trigger.