Windows App: WSL switch fails during provisioning, then hides history returned by thread/list #32902

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   performance

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jul 14, 2026
2. github-actions commented on Jul 14, 2026

   

   github-actionsBot

   on Jul 14, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows 0.144.1: elevated sandbox adds ~20s per command; unelevated restores speed but breaks apply_patch with split roots #32314
   • Windows elevated sandbox delays every shell_command by ~88 seconds before process creation; unelevated is immediate #31958
   • Windows unelevated sandbox fails because runtime adds split writable roots for workspace and special temp directories #32168
   • Recent Codex task missing from history after new ChatGPT desktop update #32182

   Powered by Codex Action
3. Cameloo1

   changed the title [-]Windows App: elevated sandbox stalls commands; switching to WSL breaks launch and hides history[/-] [+]Windows App: WSL switch fails during provisioning, then hides history returned by thread/list[/+] on Jul 14, 2026
4. lukassarfert commented on Jul 19, 2026

   

   lukassarfert

   on Jul 19, 2026

   More actions

   Adding data on this from a newer build — App 26.715.4045.0, app-server 0.145.0-alpha.18, Windows 11 Pro 26200, WSL 2.7.10.0, OracleLinux 9.5 (kernel 6.18.33.2), bubblewrap 0.6.3, roughly 393 rollout files / 547 MB of session history, 413 threads. Both failure modes @Cameloo1 reported on 26.707 / 0.144.2 are still present several builds later.

   There's an exact mechanism behind the first one, and a harder variant of the second.

   1. The provisioning kill has a permanent form: the backfill claim goes stale

   The report describes the process being killed while it was actively working. The mechanism is visible in the app-server log:

   state db backfill is running at /mnt/c/Users/<user>/.codex; waiting up to 30s before retrying startup initialization
   Error: failed to initialize sqlite state runtime under /home/<user>/.codex/sqlite:
     timed out waiting for state db backfill at /mnt/c/Users/<user>/.codex after 30s (status: running)
   

   The claim lives in backfill_state in state_5.sqlite. When a run is interrupted, that row is left at status='running' with last_success_at still NULL, and nothing expires it — there's no heartbeat or TTL. Every subsequent launch reads the row, concludes a backfill is already running elsewhere, waits its 30 seconds, and performs no work itself. The owner it waits for is long dead.

   In the original report provisioning eventually completed. Here it could not, and the app became permanently unlaunchable: main, GPU, network and storage processes all start, crashpad runs, everything reports Responding=True, but no --type=renderer process is ever spawned, so no window appears. No crash dumps, nothing in the Windows event log. From a user's perspective, clicking the icon does nothing at all, indefinitely — which makes this very hard to self-diagnose.

   Relaunching does not help and cannot: four consecutive launches moved last_watermark by zero bytes, because no launch does any work while the stale claim is held. Clearing the claim while preserving the watermark resolves it:

   UPDATE backfill_state SET status = 'pending';

   The backfill then resumed from its watermark and completed in under 40 seconds — status='complete', 413 threads, matching the Windows-side DB exactly. The next launch produced initialize_handshake_result outcome=success in 949 ms and window ready-to-show after 161 ms. Deleting the row instead also clears the lock, but discards last_watermark and forces a full rescan over /mnt/c.

   For what it's worth, the 30s value appears to be hardcoded — no CODEX_* env var, config key or CLI flag in the binary touches it. #23787 mentions a 900-second backend lease against the 30-second GUI wait, which is consistent with the behaviour here.

   2. Path normalization: UNC workspace roots break turn/start entirely

   The path-normalization theory in the report holds, and there's a sharper case than C:\... vs /mnt/c/.... With a workspace root stored as a UNC path (\\wsl.localhost\<distro>\home\<user>\src\repos\<repo>), every message submit failed:

   [Composer] submit failed  method=turn/start
   cwd="/mnt/c/Program Files/WindowsApps/OpenAI.Codex_.../app/resources/\\wsl.localhost\<distro>\home\<user>\src\repos\<repo>"
   error: Invalid request: AbsolutePathBuf deserialized without a base path
   

   A UNC path isn't absolute to the Linux app-server — absolute means a leading / — so it's treated as relative and joined onto the server's own working directory. That's what "without a base path" means here: not a notation mismatch, but a relative path with nothing to resolve it against. The consequence goes beyond hidden history: with a UNC root the app is unusable, since every message fails at turn/start.

   Rewriting the stored roots into Linux notation resolved it — active-workspace-roots, electron-saved-workspace-roots, thread-workspace-root-hints and local-projects in .codex-global-state.json, plus matching [projects.'/linux/path'] trust entries in config.toml. (The app rewrites config.toml from its own state on exit, so it has to be closed first.) Afterwards: turn/start with errorCode=null and no AbsolutePathBuf errors at all.

   Two observations that may help scope the fix:

   • The identical error was already occurring on method=fs/watch earlier the same day in native Windows mode with that UNC root open. UNC roots trip path handling in more than one code path, not only under WSL.
   • After switching, thread not found is returned for a number of older conversation IDs while those threads are present in the DB — likely the same underlying issue as the hidden-history symptom in the report, surfacing through a different call.

   Findings that look relevant but aren't

   The sandbox log fills with GetSecurityInfo failed: 1 / GetNamedSecurityInfoW failed: 1 on the WSL UNC path. These are noise — 9p doesn't implement Windows ACLs, and they appear daily including on days when everything works (305 on one entirely healthy day). Likewise bundled_executable_relocation_failed for bwrap: the bundled copy really is missing from the MSIX, but the distro's /usr/bin/bwrap is present and this is not what terminates the server. A 519 MB logs_2.sqlite is a genuine concern (#27741) but was not causal here either.

   Suggested fixes

   1. Add a TTL or heartbeat to the backfill claim. A running row whose owner no longer exists should expire rather than deadlock every future launch — this is what turns a slow first run into a permanently broken install.
   2. Reconcile the 30-second GUI wait with the backend lease, or surface backfill progress in the UI. Today a large history means the window never opens, with no user-visible reason.
   3. Translate stored workspace roots when switching to WSL mode, or normalize UNC paths server-side. Silently joining a \\wsl.localhost\ root onto the server's cwd is the worst of the available outcomes — rejecting it with a clear message would already be a large improvement.
   4. Include the offending path in the user-facing error. AbsolutePathBuf deserialized without a base path in a toast is unactionable; the log contained the answer immediately.

   👍React with 👍1Reacted by Wasif Amin