WSL 2.7.10 / kernel 6.18.33.2: Codex CLI triggers unrecoverable VMA lock stall; ps hangs and threads enter D state

### Windows Version

Microsoft Windows [Version 10.0.22631.6199]

### WSL Version

2.7.10.0

### Are you using WSL 1 or WSL 2?

- [x] WSL 2
- [ ] WSL 1

### Kernel Version

6.18.33.2-2

### Distro Version

Ubuntu 22.04

### Other Software

Codex CLI 0.144.5

Codex is installed as a native Linux standalone binary:

`/home/acrobot/.codex/packages/standalone/releases/0.144.5-x86_64-unknown-linux-musl/bin/codex`

The Codex executable, `~/.codex` state directory and project are all on WSL’s native ext4 filesystem. Nothing involved in the reproduction is stored under `/mnt/c`.

The project was located at:

`/home/acrobot/tripptic`

### Repro Steps

1. Start Codex CLI from a project stored under `/home` on the WSL ext4 filesystem.
2. Use Codex normally in an interactive session.
3. Eventually, the Codex terminal interface freezes completely.
4. Open another WSL terminal.
5. Run `ps aux`. It hangs while enumerating processes around the Codex process.
6. Running `ps` under `strace` also hangs inside process inspection.
7. Ctrl+C, Ctrl+Q and attempts to terminate Codex do not recover the process.
8. Use SysRq w and t to capture blocked-task and complete task dumps.

This has occurred multiple times, although I do not yet have a deterministic minimum-duration reproduction.

### Expected Behavior

Codex should remain responsive. If Codex itself deadlocks, it should remain possible to inspect and terminate it without affecting ps or other process-inspection tools.

### Actual Behavior

Codex freezes, process inspection involving Codex hangs, and multiple Codex threads enter uninterruptible D state.

The SysRq dump shows a `sqlx-sqlite-worker` thread blocked during `munmap()`:

```
task:sqlx-sqlite-wor state:D
__vma_start_write
__split_vma
vms_gather_munmap_vmas
do_vmi_align_munmap
do_vmi_munmap
__vm_munmap
__x64_sys_munmap
```

Another Codex `tokio-rt-worker` is blocked acquiring the virtual-memory write semaphore:

task:tokio-rt-worker state:D
rwsem_down_write_slowpath
down_write_killable
__vm_munmap
__x64_sys_munmap

After attempting to terminate Codex, other Codex threads become blocked while exiting:

```
rwsem_down_read_slowpath
down_read
do_exit
do_group_exit
get_signal
```

The affected threads cannot be terminated with signals because they remain in D state. Restarting the affected WSL distribution is required.

At the time of capture, PSI reported no current memory or I/O pressure:

```
memory some avg10=0.00 avg60=0.00 avg300=0.00
memory full avg10=0.00 avg60=0.00 avg300=0.00
io some avg10=0.00 avg60=0.00 avg300=0.00
io full avg10=0.00 avg60=0.00 avg300=0.00
```

The issue is not caused by DrvFS or a project under /mnt/c; the executable, project and Codex databases are all on ext4.

I have not yet reproduced the VMA stall using a program other than Codex. Codex appears to be the reproducible userspace trigger, but the unrecoverable D state and process-wide virtual-memory locking stall appear to occur in the WSL kernel.

### Diagnostic Logs

[WslLogs-2026-07-18_19-40-59.tar.gz](https://github.com/user-attachments/files/30154891/WslLogs-2026-07-18_19-40-59.tar.gz)