Codex Desktop: unbounded git process spawning → OOM when the workspace is on a slow / change-notification-limited filesystem (e.g. WSL /mnt drvfs) #26904

Summary

When a workspace folder lives on a filesystem where file operations are slow and change-notifications are unreliable, Codex Desktop appears to keep re-checking the folder's git state and spawning git processes without any upper bound. They pile up faster than they finish, memory climbs steadily, and the machine eventually runs out of memory and the app is OOM-killed.

(I'm describing observed behavior — I don't have the desktop app source.) This appears to be in the same git-repo-watcher / inotify-ENOSPC family as #23574 (VS Code extension allocating ~1M inotify watches on Linux) and #23191 (git-repo-watcher ENOSPC when $HOME is a large repo), and the runaway-child-process family of #24347. But it looks distinct in three ways: this is the Desktop app (not the VS Code extension or CLI); the symptom is unbounded git process spawning (not just inotify watch allocation); and the trigger is a slow / change-notification-limited filesystem (WSL /mnt drvfs), which I haven't seen reported.

Environment

• Codex Desktop app v42.1.0 (same packaged app bundle as macOS/Windows; here running on Linux).
• Codex CLI 0.137.0 is installed separately and is not involved — this is the Desktop app's own behavior (the CLI is a separate binary that has no equivalent file-watcher).
• WSL2, Ubuntu 24.04, kernel 6.6.87.
• Workspace on /mnt/c/... (drvfs) — the Windows drive mounted into Linux: slow for many small operations, with limited/unreliable inotify support.
• fs.inotify.max_user_instances = 128 (Linux default).
• The workspace folder was not yet a git repository (so the app's "watch for git init" path was active).

Observed behavior (evidence)

• Within ~3 minutes of opening the workspace, the number of live git processes climbed steadily — roughly +500 every 30 seconds, monotonically — reaching ~62,000 simultaneous git processes.
• Resident memory rose ~1 GB/min in lockstep; once RAM + swap were exhausted the OS OOM-killer fired and took the whole WSL VM down.
• The app log repeatedly showed the git-init watcher failing on the workspace root:
  ENOSPC: System limit for number of file watchers reached, watch '/mnt/c/.../<workspace>', then re-attempting.
• Adding swap only delayed the crash; the process count kept climbing — i.e. an unbounded spawn, not a transient spike.

Why this generalizes

Nothing here is fundamentally Windows/WSL specific. Any workspace on a slow or notification-limited filesystem — network mounts (SMB/NFS), some FUSE filesystems, container bind-mounts — could plausibly trip the same loop. The pattern is: the change-watch keeps failing and re-arming, and each cycle launches git, which on a slow FS doesn't return promptly, so spawns accumulate without bound.

Suggested direction (not prescriptive)

• Put an upper bound / backoff on the watch-retry + git-state-resolution cycle.
• De-duplicate or serialize concurrent git lookups for the same workspace (don't re-spawn while one is in flight).
• Detect slow/remote filesystems and degrade gracefully (bounded polling instead of unbounded spawn), or surface a one-time warning.

Reproduction

1. WSL2 Ubuntu, default fs.inotify.max_user_instances=128.
2. Put a folder under /mnt/c/... (it need not be a git repo).
3. Open it as the workspace in Codex Desktop.
4. watch -n1 'ps -e | wc -l; free -m | grep Mem' → process count and memory climb without bound until OOM.