[Windows] Codex Desktop leaks wslservice threads/handles and leaves node_repl processes after tool calls

Summary

Codex Desktop on Windows causes wslservice.exe handles and threads to grow during local tool calls, even when the active workspace is a native Windows path and no WSL distro or WSL client process is running. Long Codex sessions eventually make the whole machine lag severely, including unrelated applications such as Discord.

The issue occurs only while Codex Desktop is open and executing local work. Closing Codex stops the immediate workload, but leaked wslservice.exe handles/threads remain until the Windows service itself is restarted. wsl --shutdown does not recover them.

Environment

• Codex Desktop: 26.803.10989.0 (Microsoft Store package)
• OS: Windows 11 Pro x64, 10.0.26100 (build 26100)
• WSL2 with Ubuntu 22.04 installed
• Reproduced from a native Windows workspace under C:\dev\...
• Codex running natively on Windows, not in WSL agent mode

Impact

After prolonged Codex use, one observed incident reached:

• wslservice.exe: 27,379 threads
• wslservice.exe: 151,010 handles

After restarting the WslService Windows service, the same process immediately returned to approximately:

• 334 threads
• 2,058 handles

In a later controlled repair, the clean baseline was 244 handles / 10 threads.

Controlled reproduction evidence

Runtime process accumulation

During a 15-second sample while Codex performed one diagnostic tool call:

Each leftover node_repl.exe had approximately 48-52 threads, about 150 handles, and about 10 MB working set. All were direct children of the Codex app-server process.

Killing all node_repl.exe processes removed those user processes but did not recover the WSL service allocations:

Test with Node REPL disabled

The app normally rewrites the generated [mcp_servers.node_repl] config on startup and removes enabled = false. To test independently, I added enabled = false and temporarily made config.toml read-only.

This successfully kept node_repl.exe at 0 processes, but one 20-second native Windows tool call still changed wslservice.exe from:

• 660 handles / 46 threads
• to 709 handles / 54 threads

This suggests that node_repl.exe accumulation is one contributor, but the Codex tool/sandbox host also touches or leaks resources in WslService independently.

Reproduction steps

1. Install WSL2 and Codex Desktop on Windows 11.

2. Open a project stored on a native Windows path (C:\...), with Codex configured to run natively on Windows.

3. Restart WslService and record a clean baseline:

   Get-Process wslservice | Select-Object Id, Handles, @{n='Threads';e={$_.Threads.Count}}, WorkingSet
   

4. Run a series of ordinary local Codex tool calls such as file reads, searches, Git commands, or PowerShell commands.

5. Repeat the process measurement and inspect node_repl.exe processes.

6. Observe that handles/threads increase and are not recovered when the individual tool/runtime processes exit.

7. Run wsl --shutdown; the service counters do not return to baseline.

8. Restart the Windows WslService; counters return to normal immediately.

Troubleshooting already performed

• Removed all saved WSL workspace roots and stale WSL project entries from Codex local state.
• Removed stale process-manager records containing WSL working directories.
• Verified no wsl.exe, wslhost.exe, preview server, or project process was active during the controlled snapshots.
• Disabled ambient suggestions.
• Disabled the bundled Browser plugin.
• Tested both windows.sandbox = "elevated" and "unelevated".
• Disabled the generated node_repl MCP server and verified zero Node REPL processes.
• Grouped diagnostics into single tool calls to reduce process creation.
• Confirmed that only restarting the Windows service recovers the leaked service resources.

Expected behavior

• Completed local tool calls should release their Windows/WSL service resources.
• Codex should reuse or clean up its local runtime processes instead of accumulating one process per tool call/session.
• A native Windows workspace should not continuously grow wslservice.exe handles/threads when no WSL command or workspace is in use.

Related issues

• #13764 - Windows App: WSL agent causes severe lag when running threads
• #29639 - Browser Use Node REPL fails in Windows Desktop app with WSL workspace
• Microsoft/WSL#9851 - related wslservice.exe handle growth behavior
• Microsoft/WSL#8703 - related WSL service leak pattern

I can provide additional sanitized CSV samples and repair logs if needed.

Start with the documented Windows reproduction and the PowerShell Get-Process measurement for wslservice.exe, then compare native tool calls with node_repl.exe disabled. Trace the node_repl.exe and local tool-call lifecycle against WslService handle and thread counts. Done means completed native Windows calls no longer accumulate processes or leave WslService resources above baseline.