WSL remote regression: newer versions hang remote extension host, older versions break Codex send with TypeError: n is not iterable

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

• #21911
• #21515

Powered by Codex Action

Still broken, as soon as I left the pre-release version from weeks ago that I managed to get to work and go back to release latest 26.513.21555 it completely breaks vscode

<img width="1137" height="439" alt="Image" src="https://github.com/user-attachments/assets/29027c0c-427b-4b92-8bda-119a81ce2165" />

Going back to 26.5429.30905 works, but it would be nice to have an idea about when this can be expected to be fixed so newer versions can be used in whatever the setup that's causing this to happen in is.

Still 0 updates on this, nothing past that version works

Also happens on a brand new reinstalled wsl with a different distro

openai.chatgpt-26.609.30741-linux-x64
→ PendingMigrationError: navigator is now a global in nodejs
→ Extension host (Remote) is unresponsive
→ reconnect loop with unacknowledgedMessage

@etraut-openai ping for visibility, month + old issue that persists between clean environment reinstalls

---

I have a more concrete repro/diagnosis for the VS Code Remote WSL hang.

Summary

When the Codex VS Code extension is active in a WSL Remote workspace, the remote VS Code extensionHost becomes unresponsive / stuck. The VS Code server itself starts successfully, but the extension host wedges.

This is not a general WSL startup failure: the VS Code Remote WSL resolver starts the server, binds the local port, and creates the proxy successfully. The failure happens after the remote extension host starts and Codex activates.

Environment

• Windows host
• VS Code Remote WSL
• WSL distro: NixOS
• VS Code server commit: fcf604774b9f2674b473065736ee75077e256353
• Codex VS Code extension versions seen during debugging:

• openai.chatgpt-26.609.30741-linux-x64
• openai.chatgpt-26.616.32156-linux-x64
• Active VS Code workspace:

• /home/imi/Projects/sd-scripts

Observed process state

After opening the WSL workspace, these processes are present:

server-main     Sl+   alive
extensionHost   Dl+   stuck
codex app-server Sl+  child of extensionHost

Example:

/home/imi/.vscode-server/bin/.../node .../out/server-main.js ...
/home/imi/.vscode-server/bin/.../node .../out/bootstrap-fork --type=extensionHost ...
/home/imi/.vscode-server/extensions/openai.chatgpt-.../bin/linux-x86_64/codex app-server --analytics-default-enabled

The extension host is stuck in kernel wait state around WSL/9P:

WCHAN = p9_client_rpc
STAT  = Dl+

Kernel stack

Reading /proc/<extensionHostPid>/stack while hung showed the extension host blocked while adding an inotify watch:

p9_client_rpc
p9_client_clunk
v9fs_dentry_release
__dentry_kill
dput
path_put
__x64_sys_inotify_add_watch
x64_sys_call
do_syscall_64
entry_SYSCALL_64_after_hwframe

strace evidence

strace on the remote extensionHost showed it repeatedly calling statx() and inotify_add_watch() on paths under an old Windows-mounted project path:

/mnt/d/Projects/sd-scripts/...

Examples included:

inotify_add_watch(..., "/mnt/d/Projects/sd-scripts/.mypy_cache/...", ...)
inotify_add_watch(..., "/mnt/d/Projects/sd-scripts/.mypy_cache.disabled-20260620-000127/...", ...)
inotify_add_watch(..., "/mnt/d/Projects/sd-scripts/.venv/Lib/site-packages/torchvision/...", ...)

Important detail: the active VS Code workspace is not /mnt/d/Projects/sd-scripts; it is:

/home/imi/Projects/sd-scripts

So the extension host is watching an older/remembered project path even though the active workspace is Linux-native.

Why this looks Codex-related

The issue happens with the Codex extension active. Codex logs around startup include repeated repo watcher startup messages:

[git-repo-watcher] Starting git repo watcher

The Codex app-server child process itself did not show /mnt/d/Projects/sd-scripts hits when traced directly, so the inotify calls appear to come from the VS Code extension host side, not directly from the Rust/native codex app-server child process.

My current hypothesis is:

The Codex VS Code extension’s repo watcher / workspace dependency logic is watching remembered project entries, not only the active VS Code workspace. If a remembered project path is on DrvFS, such as /mnt/d/Projects/sd-scripts, the shared remote extensionHost can get stuck in WSL p9_client_rpc while adding many inotify watches under that path.

Why this is bad in WSL Remote

/mnt/d/... is a Windows-mounted DrvFS/9P path. Adding large numbers of inotify watches under it, especially inside .venv, site-packages, or cache directories, can make the WSL remote extension host hang hard. Once that happens, VS Code Remote keeps reconnecting or the extension host becomes unresponsive.

What I am not doing as a workaround

I do not want to delete my ~/.codex sessions/config or remove old project history just to make VS Code usable. The old project path existing should not cause the active WSL Remote workspace’s extension host to recursively watch it.

Expected behavior

When VS Code Remote is opened at:

/home/imi/Projects/sd-scripts

the Codex extension should not recursively watch old remembered project roots such as:

/mnt/d/Projects/sd-scripts

At minimum, Codex should avoid watching DrvFS paths from WSL Remote, or it should ignore generated folders like .venv, .mypy_cache, .ruff_cache, .pytest_cache, node_modules, etc.

Fresh ~/.codex:

• Codex opens thread and replies
• extensionHost stays in do_epoll_wait
• no /mnt/d/Projects refs in ~/.codex

Old ~/.codex:

• opening a thread makes extensionHost unresponsive
• extensionHost blocks in p9_client_rpc/statx
• strace showed inotify_add_watch under /mnt/d/Projects/.../.venv

---

gonna try importing my sessions first, then config, plugins, etc.

but it seems like it's not going to be easy, just moving folders/index is ineffective

it's guaranteed to be related to sessions/index/state sqlite. gonna look into it in more detail

Got a workaround/fix:

Codex’s restored user state contained stale /mnt/* workspace/project/session paths. When the VS Code extension opened/resumed threads, it rehydrated those paths and recursively stat/watch-scanned them through WSL DrvFS/9P, including huge dependency folders like .venv, which blocked the VS Code Remote extension host. Rewriting those paths to Linux-native/non-DrvFS paths and deduping the remapped config fixed the hang while preserving sessions.

---

Details:

This was not fixed by reinstalling WSL, switching distros, clearing the VS Code server, or removing/reinstalling the extension. The key difference was the contents of ~/.codex.

A fresh ~/.codex worked normally:

server-main       Sl+ do_epoll_wait
extensionHost     Sl+ do_epoll_wait
codex app-server  Sl+ futex_do_wait

Restoring my old Codex state made the extension host hang again as soon as I opened a Codex thread. In the broken state, the VS Code Remote extension host was stuck in WSL 9P/DrvFS filesystem calls:

extensionHost  Dl+  p9_client_rpc

Kernel stack from the stuck extensionHost main thread:

p9_client_rpc
p9_client_getattr_dotl
v9fs_inode_from_fid_dotl
v9fs_vfs_lookup
path_lookupat
filename_lookup
vfs_statx
do_statx
__x64_sys_statx

strace showed the extension host recursively touching/watching stale Windows-mounted project paths from old Codex state, including dependency files under .venv:

statx(AT_FDCWD, "/mnt/d/Projects/sd-scripts/.venv/Lib/site-packages/numpy/_core/tests/data/umath-validation-set-log2.csv", ...)
inotify_add_watch(56, "/mnt/d/Projects/sd-scripts/.venv/Lib/site-packages/numpy/_core/tests/data/umath-validation-set-log2.csv", ...)

The active workspace at the time was Linux-native:

/home/imi/Projects/sd-scripts

but old Codex state contained many stale /mnt/d/... and /mnt/c/... project/session paths.

What I tested:

• Fresh ~/.codex: works.
• Restored old ~/.codex: extension host hangs.
• Updating only threads.cwd in state_5.sqlite: did not fix it.
• Updating threads.cwd plus threads.sandbox_policy: did not fix it.
• Rebuilding the old .codex state while remapping stale /mnt/* paths away from DrvFS across state_5.sqlite, sessions/*.jsonl, archived_sessions/*.jsonl, and config.toml: fixed the hang and preserved my sessions.
• After path remapping, config.toml had duplicate [projects."..."] blocks because multiple old paths collapsed to the same Linux-native path; deduping those project blocks fixed thread resume.

After the repaired state, old sessions load and the extension host settles normally:

server-main       Sl+ do_epoll_wait
extensionHost     Sl+ do_epoll_wait
codex app-server  Sl+ futex_do_wait

So the more specific diagnosis seems to be:

Codex’s VS Code extension is rehydrating old session/project/config paths from ~/.codex and causing the shared VS Code Remote WSL extensionHost to recursively stat/watch stale /mnt/* roots. On WSL this goes through DrvFS/9P, and with large dependency folders like .venv it can wedge the remote extension host.

Suggested fix areas:

• Do not recursively watch old/stale session cwd / writable roots on thread list hydration or thread open.
• Avoid watching dependency/cache directories like .venv, node_modules, .mypy_cache, etc.
• In WSL Remote, either skip/guard /mnt/* roots from old sessions or only watch the active workspace unless explicitly needed.
• Handle old project paths that normalize/remap to the same [projects."..."] entry without producing duplicate TOML table keys.

moved to https://github.com/openai/codex/issues/29225