[Windows Desktop] Adding a second project folder permanently locks Codex on “Oops, an error has occurred”

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #35057
• #35061
• #35081
• #35073

Powered by Codex Action

same here.

some info from log :
Desktop App Package Version: 26.721.3996.0 (x64)
App Server / CLI Version: 0.146.0-alpha.3.1
Primary Runtime Bundle Version: 26.715.12143
Embedded Node.js Runtime Version: v24.14.0

Temp workaround fix for this: code --install-extension openai.chatgpt@26.715.61943

Disable auto update until they fix it.

Having the same issue here; occured exactly after adding some adding secondary folders to a project.
Not sure if it matters that the folders I added were already parts of other projects?
I tried reverting the change in "config.toml", but it looks unchanged and I don't see any entry with multiple folders in it.
I'm using the stand-alone app, so VS.Code extension does not apply to me.

/EDIT: It wasn't in config.toml, but in ".codex-global-state.json" where I had to remove the multi-rooted project from one of the "local-projects". After doing so, Codex started again.

@tibo-openai looks like this could be more than a few isolated cases?

This also happened when I tried to add a folder from another existing project to a new project. Nuked immediately upon creation of the new project.

And same - in duplicate I add some logs - maybe can be helpful.

I can independently reproduce this in the Microsoft Store Windows desktop app.

App version: OpenAI.Codex 26.721.3996.0 x64
Windows build: 10.0.26200.0 x64

The issue started when a new task/workspace was changed from a C: location to a D: location. After that, every launch permanently displays the “Something went wrong / Update ChatGPT” fallback page.

The renderer log consistently reports:
ReferenceError: process is not defined
name=AppRoutes

Authentication, app-server startup, thread/list, app/list, and model/list succeed. Creating a fresh Chromium Default profile does not fix the issue. The same account and the same app version work normally on another Windows computer.

This appears consistent with the single-root to multi-root workspace transition described in #35073, but it affects the Microsoft Store desktop app and persists across restarts.

I initially reported this separately as #35190.

I can confirm this issue on the Windows desktop app.

The crash occurred immediately after I used the new project feature to combine several related repositories into one project. After that, every launch showed the full-page error and the UI could not recover.

Resetting the persisted global state allowed the app to launch again, but restoring the original state brought the crash back. This confirmed that the problem was caused by the saved project configuration.

The affected project contained multiple values in rootPaths, similar to:

{
"name": "Combined Project",
"rootPaths": [
"<root-1>",
"<root-2>",
"<root-3>"
]
}

The surgical workaround was:

Fully close the desktop app.
Back up the global state JSON file.
Find the affected project.
Reduce its rootPaths array to exactly one entry:
{
"name": "Combined Project",
"rootPaths": [
"<single-root>"
]
}
Save the file and restart the app.

The app launched normally immediately after this change. Conversations and repositories were not deleted, and the conversation database did not need to be modified.

This appears to be triggered by any persisted project containing multiple Windows root paths. The app may still crash even when a different single-root project is selected, because the renderer appears to process all persisted projects during startup.

For affected users, editing only the problematic rootPaths entry is safer than deleting or fully resetting the global state file, because a full reset also removes local UI, onboarding, sidebar, and project state.

Reproduced on OpenAI.Codex 26.721.3996.0 (Microsoft Store, Windows 11 10.0.22631). I decompiled the shipped renderer bundle and traced this to a specific line, so here is the code-level root cause — the existing reports here nail the symptom and the workaround, but I don't think the actual defect has been posted yet.

TL;DR

path.posix.relative() is called with Windows paths. The POSIX resolver doesn't recognise them as absolute, so it falls back to process.cwd(), which doesn't exist in the sandboxed renderer → ReferenceError: process is not defined → AppRoutes error boundary → full-screen fallback.

Trace

Bundle: app.asar → /webview/assets/app-initial-DVfVy4b5.js

The component in the error-boundary stack (C3s) calls TFi(...) during render, passing the project root paths:

function C3s(){
  ...
  i = Y(UFi),          // project root paths
  a = i[0] ?? null,
  o = TFi(i),          // <-- throws
  s = i.length > 0,
  ...
}

TFi de-duplicates roots by asking whether one contains another:

function TFi(e){
  return e.filter((t,n) => e.every((e,r) => {
    if (r === n) return true;
    let i = EFi.default.posix.relative(bf(e), bf(t));   // <-- defect
    return i === '..' || i.startsWith('../') || (i === '' && r > n)
  }))
}

bf() normalises a path into a comparable key, and for Windows it returns a win32:-prefixed string:

function bf(e){
  let t = Sf(e),
      n = /^\/[a-z]:\//i.test(t) ? t.slice(1) : t,
      r = t.match(/^\/\/(?:wsl\$|wsl\.localhost)\/([^/]+)(?:\/(.*))?$/i),
      i = t;
  if (r != null) { /* wsl: / win32: */ }
  else (kl(n) || Al(n)) && (i = `win32:${Ol(n)}`);   // <-- e.g. "win32:c:/test/foo"
  return i === '/' ? i : i.replace(/\/+$/, '')
}

So TFi ends up calling:

path.posix.relative("win32:c:/users/.../repoA", "win32:c:/users/.../repoB")

posix.relative() calls posix.resolve(), whose absolute-path test is charCodeAt(0) === 47 (/). The bundled polyfill:

a >= 0 ? o = arguments[a]
       : (i === void 0 && (i = process.cwd()), o = i),   // <-- unguarded process
n(o), o.length !== 0 && (e = o + '/' + e, t = o.charCodeAt(0) === 47)

"win32:c:/..." starts with w, never /, so resolvedAbsolute stays false, the loop runs past the last argument, and it hits process.cwd(). In the sandboxed renderer process is undefined → ReferenceError.

(Even if kl()/Al() didn't match and bf returned C:/... unchanged, it still doesn't start with /, so it throws either way. On macOS/Linux the roots do start with /, the loop short-circuits, and process.cwd() is never reached — which is why this is Windows-only.)

Why exactly ≥2 roots

e.every((e,r) => { if (r === n) return true; ... }) — with a single root the only iteration has r === n and returns early, so posix.relative is never called. From two roots onward the second iteration reaches it and throws. That matches every report in this thread: single-root projects are fine, adding a second folder bricks the app.

Suggested fix

Any one of these:

1. Don't route bf() output through path.posix — the win32:/wsl: keys aren't POSIX paths, they're opaque comparison tokens. Compare them with plain string prefix logic.
2. Use a platform-aware relative(), or normalise Windows roots to a POSIX-absolute form (/c/users/...) before handing them to path.posix.
3. Independent of the above: the bundled path polyfill reaching for process.cwd() in a sandboxed renderer is a latent trap for any other caller — worth shimming process.cwd or guarding it.

(1) looks like the minimal correct change — relative() here only answers "is A inside B", and the win32:-prefixed strings are already normalised and comparable.

Workaround (confirms the analysis)

Verified on my machine — fully quit the app, then in ~/.codex/.codex-global-state.json reduce the affected project's rootPaths to a single entry:

"local-projects": {
  "<id>": { "name": "<project>", "rootPaths": ["<single-root>"] }
}

Also patch .codex-global-state.json.bak, otherwise a fallback read can reintroduce it. Before/after, from %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\<YYYY>\<MM>\<DD>\codex-desktop-*-t0-*.log:

| | 2 roots | 1 root |
|---|---|---|
| error boundary / process is not defined | present, every launch | 0 |
| [startup][renderer] app routes mounted | never completes | succeeds (1850 ms / 3249 ms) |

Two clean relaunches, no other change. Note the app rewrites this file on exit, so it has to be edited with the app closed.

One clarification on an earlier comment in this thread suggesting all persisted projects are scanned at startup: the call site I traced (C3s) reads only the selected project's roots. There is at least one other TFi call site in the bundle, so a broader trigger is plausible, but I only verified the selected-project path.