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

Environment

• Codex App: 26.707.62119
• MSIX package: OpenAI.Codex_26.707.8479.0_x64
• Codex CLI/app-server: 0.144.2
• Windows 11 Home x64, OS 10.0.26200 build 8655
• WSL 2.6.3.0
• Ubuntu 26.04 LTS
• WSL kernel 6.6.87.2-1
• /usr/bin/bash and bubblewrap 0.11.1 present

Summary

I enabled Run Codex in WSL because native Windows sandbox execution was slow. That native sandbox behavior is already covered by #32314, #31958, and #32168.

The WSL switch exposed a separate Codex App failure:

1. On the first WSL launch, the App repeatedly terminated the WSL app-server after approximately 90 seconds while it was still performing healthy first-run provisioning.
2. After provisioning completed, the same app-server initialized in under one second.
3. Codex App then displayed no existing task history, even though a direct JSON-RPC thread/list request using the App's WSL configuration returned 953 existing threads.
4. Reverting the App to native Windows immediately restored startup and the original history.

No task data was lost.

Why WSL was enabled

This is context rather than a second bug report:

• Native elevated mode currently takes approximately 3.5 seconds for a trivial command after workspace cleanup.
• Simple patch operations take approximately 10-16 seconds.
• Unelevated mode reduces a trivial command to approximately 0.2 seconds, but patching fails with:

~~~text
windows unelevated restricted-token sandbox cannot enforce split writable root sets directly; refusing to run unsandboxed
~~~

The detailed native sandbox reports are already in #32314, #31958, and #32168. WSL was selected as the practical workaround.

Observed WSL behavior

First launch fails during active provisioning

After enabling Run Codex in WSL and restarting the App, the WSL app-server was terminated after approximately 90 seconds before becoming reachable.

Diagnostics showed that it was not deadlocked or crashed. It was still performing one-time setup work, including:

• cold-starting WSL;
• loading the approximately 298 MB executable through /mnt/c;
• applying approximately 40 SQLite migrations; and
• backfilling approximately 950 existing threads.

Ubuntu had approximately 13 GB of available memory. There was no OOM, segmentation fault, kernel failure, or executable failure.

This is consistent with a fixed initialization deadline treating active first-run provisioning as a hung process.

Backend initializes, but the UI hides its history

After the one-time provisioning completed, a later launch initialized the exact WSL app-server in under one second.

Codex App opened, but its task history was empty.

A direct JSON-RPC thread/list request using the same WSL CODEX_HOME, app-server flags, and request parameters returned 953 existing thread records:

• 191 user threads
• 618 subagent threads
• 144 records with a null source classification

The databases and task files were present and readable. The backend returned the history, but the Desktop UI did not render it.

Persisted Windows cwd values use forms such as:

~~~text
C:\Users\<user>\...
~~~

while WSL represents the same locations as:

~~~text
/mnt/c/Users/<user>/...
~~~

This suggests a Desktop runtime/path/state classification problem rather than missing backend data.

Native rollback restores the App

Disabling Run Codex in WSL and restarting restored:

• normal App startup;
• the original task history; and
• access to the existing projects.

The WSL-side state was preserved for diagnostics.

Reproduction steps

1. Start Codex App in native Windows mode with existing local task history.
2. Configure Ubuntu as the default WSL2 distribution.
3. Verify /usr/bin/bash and bubblewrap are available.
4. Enable Run Codex in WSL.
5. Restart Codex App.
6. Observe the first launch fail after approximately 90 seconds while the WSL app-server is still migrating and backfilling its state.
7. Restart after the provisioning work has completed.
8. Observe that the WSL app-server initializes, but the App displays no existing history.
9. Query the same app-server directly with thread/list and observe that it returns the existing threads.
10. Disable Run Codex in WSL and restart.
11. Observe that native startup and the original history return.

Expected behavior

• First-run WSL provisioning should report progress and should not be killed while migrations or backfill are advancing.
• The initialization timeout should reset on progress, allow sufficient first-run time, or retry safely.
• A failed WSL launch should offer an automatic rollback to native Windows.
• Threads returned by thread/list should appear in the Desktop UI.
• Windows and WSL cwd forms should be normalized consistently when grouping tasks under projects.
• Switching environments must not make preserved task history appear lost.

Relationship to suggested duplicates

• #32314 and #31958 cover the native elevated sandbox slowdown that motivated the WSL switch.
• #32168 covers the unelevated split writable-root failure and is already closed as a duplicate.
• #32182 reports one missing task after an App update. It does not involve switching to WSL, a first-run provisioning timeout, or a backend thread/list response containing the hidden history.
• #30288 is related, but describes a short WSL eligibility timeout followed by fallback to the Windows app-server. In this reproduction, the WSL app-server launched, performed provisioning, and was terminated around the App's later initialization boundary.
• #24364 is also related to Windows/WSL cwd migration. In this reproduction, an unfiltered thread/list request returned the complete WSL history while the Desktop UI remained empty.

Diagnostic material

Sanitized App and sandbox logs can be supplied privately through /feedback. Raw SQLite databases, task JSONL files, user paths, and conversation content are intentionally not attached publicly.