Severe disk I/O / 100% disk active time on Windows WSL2 when using Codex extension / CLI

What version of Codex CLI is running?

v0.137.0

What subscription do you have?

Pro Lite

Which model were you using?

GPT 5.5

What platform is your computer?

WSL on Windows 11

What terminal emulator and version are you using (if applicable)?

bash on wsl

Codex doctor report

-

What issue are you seeing?

Codex is causing severe disk I/O / 100% Windows disk active time when used with VS Code + WSL2.

This makes Codex practically unusable for WSL2-based development on Windows, even on a powerful setup with 64GB+ RAM and a fast SSD. The machine becomes sluggish, Windows Task Manager reports 100% disk usage, and normal development in WSL becomes difficult or impossible.

Important: the repository is inside the WSL Linux filesystem, not under /mnt/c.

Example repo path:

~/code/<repo>

The project is opened from Ubuntu/WSL like this:

cd ~/code/<repo>
code .

So this does not appear to be the usual WSL performance issue of editing a repo located on the Windows-mounted filesystem.

The issue appears to involve both:

• the Codex VS Code/IDE extension path
• the Codex CLI/local runtime

Before uninstalling the Codex CLI, the main disk users were:

codex app-server --analytics-default-enabled
codex

After uninstalling the Codex CLI, the situation improved somewhat because codex app-server no longer appears, but a plain codex process still shows disk read/write activity.

While Windows showed 100% disk usage, iotop -oPa showed Codex as the dominant cumulative disk writer:

Total DISK READ:        59.35 K/s | Total DISK WRITE:       150.35 K/s
Current DISK READ:      59.35 K/s | Current DISK WRITE:     126.61 K/s

PID    USER      DISK READ   DISK WRITE   COMMAND
1166   <user>    168.06 M    4.92 G       codex app-server --analytics-default-enabled
52985  <user>     35.36 M    2.16 G       codex
88974  <user>     36.00 K   60.85 M       node (vitest 1)
45     root        0.00 B   34.98 M       systemd-journald
1122   <user>    185.97 M   32.25 M       node --dns-result-order=ipv4first ...

pidstat also showed active Codex disk I/O:

14:20:13 UID   PID     kB_rd/s   kB_wr/s   kB_ccwr/s   iodelay   Command
14:20:13 1000  52985   548.00    824.00    272.00      0         codex
14:20:13 1000 135838    16.00    352.00      0.00      0         codex

There were also normal project tools running, such as Vite/Vitest/Playwright/lint/typecheck, but Codex was the standout persistent disk writer. The project tools can create bursts, but Codex appears to be the recurring culprit.

This appears specific to Codex. Other coding agents/tools, for example Claude, are usable in the same WSL2 development setup.

What steps can reproduce the bug?

1. Use Windows 11 with WSL2 and Ubuntu.

1. Use a repository located inside the WSL Linux filesystem, not under /mnt/c.

Example:

``bash
~/code/<repo>
``

1. Close VS Code / Cursor / Codex.

1. Fully shut down WSL from PowerShell:

``powershell
wsl --shutdown
``

1. Open Ubuntu Bash and verify clean state:

``bash
lsof -nP 2>/dev/null | grep /mnt/c/ || echo "no /mnt/c handles"
pgrep -af 'codex|code|cursor|node' || echo "no editor/codex processes"
``

1. Start disk/process observation before opening the editor:

``bash
sudo iotop -oPa
``

Optionally also log process I/O:

``bash
pidstat -dru -p ALL 1 | tee ~/wsl-codex-io-test.log
``

1. In a second Ubuntu Bash window, open the WSL repo in VS Code:

``bash
cd ~/code/<repo>
code .
``

1. Enable/use the Codex IDE extension, or start Codex in the same repo.

1. Observe Windows Task Manager / Resource Monitor and WSL iotop / pidstat.

Actual result:

• Windows disk active time reaches 100%.
• WSL becomes sluggish.
• iotop -oPa shows Codex as one of the dominant cumulative disk writers.
• pidstat shows active read/write activity from codex processes.
• Before uninstalling the CLI, codex app-server --analytics-default-enabled was also a major disk writer.
• After uninstalling the CLI, codex app-server no longer appears, but a plain codex process still performs disk I/O.

Project context:

This is a TypeScript/Node repository using common dev tooling, including some or all of:

Vite
Vitest
Playwright
tsx watch
npm run dev
npm run lint
npm run typecheck

These tools can create some expected disk activity, but Codex is the process that stands out as the persistent/high cumulative disk writer.

Diagnostic commands used:

sudo iotop -oPa
pidstat -dru -p ALL 1
lsof -nP 2>/dev/null | grep /mnt/c/
pgrep -af 'codex|code|cursor|node'

Additional useful commands for further diagnosis:

codex --version
code --version
wsl -l -v
uname -a
cat /etc/os-release
cat ~/.codex/config.toml
pgrep -af codex
pstree -sap <codex-pid>
lsof -nP -p <codex-pid>
lsof -nP -p <codex-pid> | grep -E '/mnt/c|\.codex|<repo>'

I can provide sanitized logs if useful.

What is the expected behavior?

Codex should be usable in a normal Windows + WSL2 development setup without causing sustained 100% disk active time.

Expected behavior:

• Codex should not continuously write gigabytes of data while idle or during normal repository usage.
• Codex should not make WSL2 development sluggish/unusable on a high-end machine with 64GB+ RAM and a fast SSD.
• The Codex IDE extension and Codex CLI/runtime should not duplicate background scanning/indexing/watching work.
• codex app-server should not perform heavy disk I/O unless there is an explicit active task that requires it.
• A plain codex process should not continue producing significant background disk I/O after the CLI/app-server path has been removed or disabled.
• Codex should respect common ignore patterns and avoid watching/indexing generated folders by default.
• Codex should provide a way to disable or throttle background repository scanning, indexing, file watching, telemetry/logging, or cache/database writes.
• When running in WSL, Codex should avoid unnecessary writes through Windows-mounted paths and should prefer Linux-local cache/state paths where appropriate.
• Codex should expose diagnostics showing what it is currently watching, indexing, reading, or writing.

Common directories that should be ignored by default or be easily configurable:

.git
node_modules
.pnpm-store
.yarn/cache
.vite
.vitest
.turbo
.next
.nuxt
dist
build
coverage
playwright-report
test-results
.cache
tmp
temp

In short: opening a WSL2 repo with Codex enabled should not make the machine unusable.

Additional information

This was initially suspected to be a VS Code WSL extension issue, but the evidence points more strongly to Codex.

Key observations:

1. The repository is stored in the WSL Linux filesystem:

``bash
~/code/<repo>
``

not in:

``bash
/mnt/c/...
``

1. After a full restart / wsl --shutdown, this returned no results before opening the editor/Codex:

``bash
lsof -nP 2>/dev/null | grep /mnt/c/
``

1. Earlier /mnt/c results were mostly cwd entries from VS Code/Cursor processes, not necessarily active file I/O from the project.

1. The stronger evidence is from iotop / pidstat, where Codex appears as the main disk I/O process.

1. Before uninstalling the Codex CLI, codex app-server --analytics-default-enabled accumulated several GB of writes.

1. After uninstalling the CLI, the situation improved because codex app-server stopped appearing, but a plain codex process still appears in disk read/write.

1. This suggests the issue may be in the shared Codex local runtime used by both the IDE extension and CLI, or in how the extension starts/uses the CLI/app-server in WSL.

Possible root causes:

• file watcher loop on WSL2
• repeated repository indexing
• repeated cache/database/log writes
• telemetry/logging writes
• app-server conversation/thread persistence
• ignoring generated folders such as node_modules, .vite, .vitest, coverage, playwright-report, etc.
• overlapping work between IDE extension and CLI/runtime
• writing Codex state/cache/temp files through Windows-mounted paths instead of Linux-local paths
• failure to debounce file events from Vite/Vitest/Playwright/TypeScript tooling

Requested improvements:

1. Add a setting to disable all Codex background indexing/watching for a workspace.
2. Add configurable watcher/indexing excludes.
3. Respect .gitignore and common generated directories by default.
4. Add rate limiting/debouncing for filesystem events.
5. Add diagnostics showing exactly what Codex is reading/writing/indexing/watching.
6. Avoid starting codex app-server unless required.
7. Make it clear whether disk activity is coming from the IDE extension, CLI, app-server, telemetry, logs, cache, or repository indexing.
8. Ensure disabling/uninstalling the CLI or extension does not leave background Codex runtime behavior behind.
9. Document WSL-specific performance recommendations.
10. Provide an official workaround for WSL users until this is fixed.

Sanitized diagnostic snippets:

1. lsof: mostly editor cwd entries under /mnt/c, not necessarily active repo I/O

$ lsof 2>/dev/null | grep /mnt/c/

sh    <pid>              <user>  cwd  DIR  ... /mnt/c/Users/<windows-user>/AppData/Local/Programs/cursor
node  <pid>              <user>  cwd  DIR  ... /mnt/c/Users/<windows-user>/AppData/Local/Programs/cursor
node  <pid> <tid> node   <user>  cwd  DIR  ... /mnt/c/Users/<windows-user>/AppData/Local/Programs/cursor
node  <pid> <tid> node   <user>  cwd  DIR  ... /mnt/c/Users/<windows-user>/AppData/Local/Programs/cursor

sh    <pid>              <user>  cwd  DIR  ... /mnt/c/Users/<windows-user>/AppData/Local/Programs/Microsoft VS Code
sh    <pid>              <user>  10r  REG  ... /mnt/c/Users/<windows-user>/.vscode/extensions/ms-vscode-remote.remote-wsl-<version>/scripts/wslServer.sh
node  <pid>              <user>  cwd  DIR  ... /mnt/c/Users/<windows-user>/AppData/Local/Programs/Microsoft VS Code
node  <pid> <tid> node   <user>  cwd  DIR  ... /mnt/c/Users/<windows-user>/AppData/Local/Programs/Microsoft VS Code

This initially looked suspicious, but most entries are cwd entries from editor/extension processes. The repo itself is not under /mnt/c.

2. lsof: Codex-specific /mnt/c / .codex paths

codex  <pid>              <user>  cwd      DIR  ... /mnt/c/Program Files/WindowsApps/OpenAI.Codex_<version>_x64__<id>/app/resources
codex  <pid>              <user>  txt      REG  ... /mnt/c/Users/<windows-user>/.codex/bin/wsl/<hash>/codex
codex  <pid>              <user>  3u   unknown  ... /mnt/c/Users/<windows-user>/.codex/tmp/arg0/codex-arg0<random>/.lock
codex  <pid> <tid> tokio  <user>  cwd      DIR  ... /mnt/c/Program Files/WindowsApps/OpenAI.Codex_<version>_x64__<id>/app/resources
codex  <pid> <tid> tokio  <user>  txt      REG  ... /mnt/c/Users/<windows-user>/.codex/bin/wsl/<hash>/codex
codex  <pid> <tid> tokio  <user>  3u   unknown  ... /mnt/c/Users/<windows-user>/.codex/tmp/arg0/codex-arg0<random>/.lock

This is more relevant than the generic VS Code/Cursor cwd noise, because Codex itself is running with Windows-side .codex paths while the repo is in the WSL Linux filesystem.

3. iotop during Windows 100% disk active time

Total DISK READ:        59.35 K/s | Total DISK WRITE:       150.35 K/s
Current DISK READ:      59.35 K/s | Current DISK WRITE:     126.61 K/s

PID    PRIO  USER    DISK READ  DISK WRITE  COMMAND
1166   be/4  <user>   168.06 M     4.92 G    codex app-server --analytics-default-enabled
52985  be/4  <user>    35.36 M     2.16 G    codex
88974  be/4  <user>    36.00 K    60.85 M    node (vitest 1)
45     be/3  root       0.00 B    34.98 M    systemd-journald
1122   be/4  <user>   185.97 M    32.25 M    node --dns-result-order=ipv4first ...
1134   be/4  <user>   275.04 M     0.00 B    node ... --type=fileWatcher

The absolute current read/write rate is not huge, but Windows reports 100% disk active time. This may indicate high latency / small write amplification / WSL VHD behavior rather than pure throughput saturation. Codex still stands out as the largest cumulative writer.

4. pidstat log snippet

14:20:13      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
14:20:13     1000     52985    548.00    824.00    272.00       0  codex
14:20:13     1000    135838     16.00    352.00      0.00       0  codex

14:20:14      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
14:20:14     1000     52985      1.00      2.00      0.00       0  codex
14:20:14     1000    135838      0.00      1.00      0.00       0  codex

This confirms active read/write activity from multiple codex processes while the WSL project was open.

Impact:

This blocks using Codex in a very common development setup:

Windows 11
WSL2
Ubuntu
VS Code
Linux-hosted repository
TypeScript/Node project

On this setup, Codex on WSL is currently unusable, while other agents/tools such as Claude work in the same environment.