Repository navigation
Windows Desktop WSL mode: Git watcher retries EISDIR ~6 times/sec on WSL repositories #33764
Description
Summary
When Codex Desktop for Windows runs its agent in WSL2 and opens a repository stored on the native WSL filesystem, the Windows-side Git repository watcher enters a persistent retry loop.
The watcher tries to watch the WSL repository through a \\wsl$\... UNC path, receives EISDIR, restarts, and retries several times per second. The loop continues even while the thread is idle and is associated with sustained Desktop/UI lag and unnecessary CPU, filesystem, and log activity.
Local Git commands executed inside WSL remain fast, so the repository's Linux filesystem performance is not the bottleneck.
Environment
- Codex Desktop:
26.715.2305 - Bundled WSL app-server:
codex-cli 0.145.0-alpha.18 - Windows 11
- WSL2 with Ubuntu
- Agent environment: WSL
- Repository location: native WSL filesystem, e.g.
/home/<wsl-user>/projects/example - Desktop Codex home exposed to WSL as
/mnt/c/Users/<windows-user>/.codex - SQLite state separated to a WSL-native directory
Reproduction
- Configure Codex Desktop on Windows to run the agent in WSL.
- Open a Git repository stored under
/home/<wsl-user>/...through the Windows project picker. - Start a local task, or leave the loaded thread idle.
- Inspect the Codex Desktop logs.
Actual behavior
The Windows Electron worker repeatedly attempts to watch paths resembling:
\\wsl$\Ubuntu\home\<wsl-user>\projects\example\.git
\\wsl$\Ubuntu\home\<wsl-user>\projects\example\.git\refs
\\wsl$\Ubuntu\home\<wsl-user>\projects\example\.git\refs\heads
\\wsl$\Ubuntu\home\<wsl-user>\projects\example\.git\info
\\wsl$\Ubuntu\home\<wsl-user>\projects\example
Each attempt fails with an error resembling:
[git-repo-watcher] Failed to watch git path
errorCode=EISDIR
errorMessage="EISDIR: illegal operation on a directory, watch '\\wsl$\Ubuntu\home\<wsl-user>\projects\example\.git'"
Measurements from one approximately 31-minute run:
- 10,678 watcher failures
- 294–354 failures per minute
- Approximately 5.8 failures per second
- 30 logged watcher restarts
- A roughly 10 MB Desktop log with 10,908 lines, almost entirely watcher failures
- The retry loop continued between active agent turns
During the same session, ordinary Git inspection commands inside WSL completed in approximately 0.5–3.7 seconds.
Expected behavior
Codex Desktop should either:
- use a WSL-side filesystem watcher for repositories stored in WSL;
- use a Windows watcher implementation that correctly supports WSL UNC directories; or
- disable watching after a non-recoverable path-type error instead of retrying continuously.
Opening a native WSL repository should not create a persistent high-frequency watcher/error loop.
Related issues
- Codex Desktop Windows WSL mode shows reconnecting despite app-server connected #21693 — Windows worker attempts to watch Linux/WSL Git paths
- Windows App: WSL agent causes severe lag when running threads (agent restart / high resource usage) #13764 — severe lag and resource usage in Windows Desktop WSL mode
- Windows: Codex spawns many Git for Windows processes causing sustained high CPU after recent update #22085 — repeated Git activity causing sustained CPU usage
- Windows Codex app + WSL: UNC cwd breaks terminal, Windows config leaks into WSL, and worktrees need a WSL-native CODEX_HOME #18506 — WSL UNC path, config, terminal, and worktree boundary problems
The paths and measurements above are sanitized; no private repository, organization, username, thread identifier, or raw log is included.
Activity
github-actions commentedon Jul 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
limitless10101 commentedon Jul 17, 2026
This appears related to #32695, but two distinct behaviors are observable: a high-rate git-repo-watcher process storm tied to saved WSL Git projects, and a lower-rate git-init-watcher retry every five seconds that persists on a non-Git host. The workaround below eliminates the former but not the latter.
Independent reproduction on Desktop build 26.715.2305 with bundled WSL backend 0.145.0-alpha.18.
Selecting a non-Git WSL project made the UI responsive, but did not initially stop the background storm: two inactive saved WSL Git project entries remained globally watched. Before removing them, one session reached 7,530 WSL launches and 8,342 repository-watcher failures.
After removing both saved WSL Git projects from the app UI—without deleting or moving either repository—and restarting with only the non-Git host, a verified continuous ~1h49m active interval recorded:
0 git-repo-watcher events
0 references to the real repository
4 WSL launches, occurring as two bounded hourly pairs rather than continuously
no return of the previous process storm
A lower-rate git-init-watcher EISDIR retry still occurs against the non-Git host approximately every five seconds, so this is a workaround, not a fix.
Current workaround:
Keep a non-Git WSL directory as the saved Desktop project.
Remove WSL Git repositories from the app’s saved-project list.
Access the real repository through absolute WSL paths or an explicit working directory.
Use command-line Git because the Changes panel does not represent the external repository.
Because both duplicate project entries were removed together, this does not distinguish duplicate amplification from the cost of any single saved WSL Git project. It does suggest that inactive saved projects remain globally watched.
A product fix could stop retrying permanent EISDIR failures, avoid watching inactive saved projects, or run the filesystem watcher inside WSL.
akemihomura0105 commentedon Jul 19, 2026
I can independently reproduce this issue on a newer Windows Desktop build.
Environment
26.715.4045.0/home/<wsl-user>/...\\wsl$\Ubuntu-24.04\...Log behavior
The Desktop log repeatedly emits the following error for the repository root and several Git directories, including
.git,.git/refs,.git/refs/heads, and.git/info:The same group of failures repeats approximately once per second. On the day of observation, Codex Desktop had already generated about 49 MB of log files, with several individual rotating logs reaching roughly 10 MB.
Resource usage during the loop
A three-second process sample showed approximately:
The application had remained open since the previous evening, which appeared to amplify the memory and handle usage. The machine had abundant free physical memory, so system-wide memory pressure was not the cause of the UI lag.
Restarting Codex releases the accumulated resources, but the watcher loop returns when the WSL-hosted repository is loaded again.
The repository path, usernames, thread identifiers, and raw logs above have been sanitized.
willguerin commentedon Sep 5, 2026
Additional current-build confirmation (2026-09-05):
The high-rate retry/logging behavior therefore persists on 26.901.5003.0, several Desktop and bundled-engine generations after the original report. I have not modified the repository, Codex configuration, or WSL settings, and I am not asserting that this watcher loop causes the separate app-server termination issue.