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

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

• #32314
• #31958
• #32168
• #32182

Powered by Codex Action

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.