WSL Remote extensionHost hangs when Codex rehydrates stale /mnt/* paths from ~/.codex state

What version of the IDE extension are you using?

openai.chatgpt-26.616.32156-linux-x64

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

VS Code with Remote - WSL.

What platform is your computer?

Linux 6.18.33.1-microsoft-standard-WSL2 x86_64 unknown

What issue are you seeing?

Follow-up / reduced diagnosis for #21980. I searched for existing issues and only found #21980, but that issue contains a broad regression/debugging history. This report is the narrowed root cause and workaround.

In VS Code Remote WSL, the Codex extension can make the shared remote extensionHost hang/reconnect-loop when opening Codex threads if old ~/.codex state contains stale /mnt/* project/session paths.

A fresh ~/.codex works normally. Restoring my old ~/.codex causes the hang again.

Healthy/fresh state:

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

Broken/restored state:

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 VS Code workspace at the time was Linux-native:

/home/imi/Projects/sd-scripts

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

The issue is severe because it wedges the shared VS Code Remote WSL extension host, not just the Codex UI.

What steps can reproduce the bug?

I can reproduce it with old Codex state that contains stale /mnt/* paths.

1. Use VS Code Remote WSL.
2. Open a Linux-native workspace, for example:

/home/imi/Projects/sd-scripts

1. Use a ~/.codex folder whose previous sessions/config/state contain old Windows-mounted WSL paths such as:

/mnt/d/Projects/...
/mnt/c/Users/...

1. Open Codex and open a thread.
2. VS Code reports that the Remote extension host is unresponsive and may enter a reconnect loop.

Process state in the broken case:

ps -eo pid,ppid,stat,wchan:35,cmd | rg 'server-main|bootstrap-fork --type=extensionHost|codex app-server'

shows:

extensionHost      Dl+  p9_client_rpc
codex app-server   Sl+  futex_do_wait

I also confirmed that editing only threads.cwd in state_5.sqlite did not fix it. Editing threads.cwd plus threads.sandbox_policy also did not fix it.

The workaround that fixed it was rebuilding the old .codex state while remapping stale /mnt/* references away from DrvFS paths across:

state_5.sqlite
sessions/*.jsonl
archived_sessions/*.jsonl
config.toml

After that, 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

One extra detail: after path remapping, config.toml had duplicate [projects."..."] blocks because multiple old project paths collapsed to the same Linux-native path. Codex then refused to resume threads until I deduped those project blocks.

What is the expected behavior?

Codex should not make the shared VS Code Remote WSL extension host unresponsive when opening/restoring old threads.

Old session/project paths should not cause the extension to recursively stat/watch stale /mnt/* roots, especially dependency/cache folders like:

.venv
node_modules
.mypy_cache

If an old thread has a stale or inaccessible cwd / writable root, Codex should either ignore it, treat it as unavailable, or only resolve it when the user explicitly resumes that thread. It should not recursively watch old DrvFS paths during thread list hydration or normal thread opening.

Additional information

The narrowed diagnosis appears to be:

Codex’s VS Code extension rehydrates old session/project/config paths from ~/.codex, then recursively stat/watch-scans stale /mnt/* roots from WSL Remote. On WSL this goes through DrvFS/9P. With large dependency folders like .venv, this can wedge the shared remote extensionHost in p9_client_rpc / statx.

Suggested fix areas:

• Do not recursively watch old/stale session cwd or writable roots on thread list hydration.
• In WSL Remote, skip or guard /mnt/* roots from old sessions unless explicitly needed.
• Exclude dependency/cache directories like .venv, node_modules, .mypy_cache, etc.
• Handle stale/unavailable thread working directories without blocking the extension host.
• Avoid producing duplicate [projects."..."] TOML table entries when old paths normalize/remap to the same project path.

Previous thread with month + history