codex - 💡(How to fix) Fix VS Code Codex extension can allocate about 1M inotify watches on Linux large workspace [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#23574Fetched 2026-05-20 03:48:09
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Timeline (top)
labeled ×3commented ×1

Root Cause

Closest related issue I found: #23191 reports the same general git-repo-watcher/ENOSPC family in Cursor Remote SSH when $HOME accidentally becomes a large Git repo. This issue is separate because it reproduces in VS Code with an intended repo workspace, measured extension-host watch ownership, and normal VS Code watcher excludes already in place.

Fix Action

Fix / Workaround

  1. On Linux, open a large VS Code workspace with the Codex extension enabled.
  2. Use a workspace with large generated/runtime directories under the repo root. In my case, before local mitigation:

A local mitigation confirmed that real workspace tree size drives the spike. Moving logs/ outside the real workspace tree and symlinking it back removed about 731k watches:

That mitigation is only a workaround. It also shows that the extension host appears to expand the real filesystem tree under the workspace root instead of honoring the configured VS Code watcher excludes.

Code Example

openai.chatgpt disabled in the VS Code Planning profile: about 80k-90k total watches
openai.chatgpt enabled and Codex chats opened/resumed: about 1,048k to 1,234k total watches
VS Code extension host process during bad state: about 900k-1,151k watches
normal VS Code file-watcher process during bad state: about 3k-79k watches
Codex app-server child during bad state: about 213 watches

---

Features enabled ... workspace_dependencies ...
[git-repo-watcher] Starting git repo watcher
codex_file_watcher: failed to watch /etc: OS file watch limit reached
codex_file_watcher: failed to watch /media/S_Drive/projects/strategy-tester/.agents/skills: OS file watch limit reached
codex_app_server_transport::transport: dropping overload response ... outbound queue is full
[git-repo-watcher] Git repo watcher failed ... ENOSPC ... watch '/media/S_Drive/projects/strategy-tester/.git/objects/...'

---

"files.watcherExclude": {
  "**/.sandcastle/worktrees/**": true,
  "**/data/**": true,
  "**/logs/**": true
}

---

repo total:              about 1,071,929 files
logs/:                   about   716,933 files
data/:                   about   129,956 files
.sandcastle/worktrees/:  about   102,877 files

---

"files.watcherExclude": {
  "**/.sandcastle/worktrees/**": true,
  "**/data/**": true,
  "**/logs/**": true
}

---

sudo bash -c 'total=0; for f in /proc/[0-9]*/fdinfo/*; do n=$(grep -c "inotify wd:" "$f" 2>/dev/null || true); total=$((total+n)); done; echo "$total"'

for pid in $(find /proc/*/fd -lname anon_inode:inotify 2>/dev/null | sed 's#/proc/##; s#/fd/.*##' | sort -u); do
  watches=$(grep -h "inotify wd:" /proc/$pid/fdinfo/* 2>/dev/null | wc -l)
  comm=$(cat /proc/$pid/comm 2>/dev/null)
  cmdline=$(tr "\0" " " < /proc/$pid/cmdline 2>/dev/null | cut -c1-220)
  printf '%8s %7s %-18s %s\n' "$watches" "$pid" "$comm" "$cmdline"
done | sort -nr | head -20

---

10:08:58 total_watches=83,205
10:10:08 total_watches=83,205
10:11:18 total_watches=1,234,730
10:12:37 total_watches=1,234,736
10:13:55 total_watches=1,234,736
11:02:12 total_watches=1,234,754

---

normal VS Code file watcher: low watch count
Codex app-server child: about 213 watches
VS Code extension host: about 1,151,500 watches

---

Before: Codex extension host about 1,151,522 watches
After moving logs/ out of the real tree: Codex extension host about 420,306 watches
RAW_BUFFERClick to expand / collapse

What version of the IDE extension are you using?

openai.chatgpt-26.513.21555-linux-x64

What subscription do you have?

ChatGPT Pro

Which IDE are you using?

VS Code 1.120.0

What platform is your computer?

Linux 6.17.0-29-generic x86_64 x86_64

What issue are you seeing?

On Linux, the VS Code Codex extension can drive the user session close to or beyond the inotify watch limit in a large workspace. The high watch count is owned by the VS Code extension host process, not by VS Code's normal file watcher and not by the Codex app-server child.

Observed measurements:

openai.chatgpt disabled in the VS Code Planning profile: about 80k-90k total watches
openai.chatgpt enabled and Codex chats opened/resumed: about 1,048k to 1,234k total watches
VS Code extension host process during bad state: about 900k-1,151k watches
normal VS Code file-watcher process during bad state: about 3k-79k watches
Codex app-server child during bad state: about 213 watches

The impact was desktop-wide inotify exhaustion: logs showed ENOSPC, No space left on device, and OS file watch limit reached, with collateral failures in the Linux desktop session.

Relevant Codex log excerpts from the bad state:

Features enabled ... workspace_dependencies ...
[git-repo-watcher] Starting git repo watcher
codex_file_watcher: failed to watch /etc: OS file watch limit reached
codex_file_watcher: failed to watch /media/S_Drive/projects/strategy-tester/.agents/skills: OS file watch limit reached
codex_app_server_transport::transport: dropping overload response ... outbound queue is full
[git-repo-watcher] Git repo watcher failed ... ENOSPC ... watch '/media/S_Drive/projects/strategy-tester/.git/objects/...'

This workspace has large generated/runtime trees, but they are excluded from VS Code's normal watcher:

"files.watcherExclude": {
  "**/.sandcastle/worktrees/**": true,
  "**/data/**": true,
  "**/logs/**": true
}

The normal VS Code file watcher stayed low, which suggests the Codex extension-side watcher path is bypassing VS Code's files.watcherExclude and/or recursively watching too much Git/workspace state.

What steps can reproduce the bug?

  1. On Linux, open a large VS Code workspace with the Codex extension enabled.
  2. Use a workspace with large generated/runtime directories under the repo root. In my case, before local mitigation:
repo total:              about 1,071,929 files
logs/:                   about   716,933 files
data/:                   about   129,956 files
.sandcastle/worktrees/:  about   102,877 files
  1. Configure VS Code workspace excludes for those large directories, for example:
"files.watcherExclude": {
  "**/.sandcastle/worktrees/**": true,
  "**/data/**": true,
  "**/logs/**": true
}
  1. Start or resume Codex chats in the VS Code Codex panel. A focused repro opened one existing Codex chat, then opened about 3-4 additional Codex chats.
  2. Monitor inotify watches:
sudo bash -c 'total=0; for f in /proc/[0-9]*/fdinfo/*; do n=$(grep -c "inotify wd:" "$f" 2>/dev/null || true); total=$((total+n)); done; echo "$total"'

for pid in $(find /proc/*/fd -lname anon_inode:inotify 2>/dev/null | sed 's#/proc/##; s#/fd/.*##' | sort -u); do
  watches=$(grep -h "inotify wd:" /proc/$pid/fdinfo/* 2>/dev/null | wc -l)
  comm=$(cat /proc/$pid/comm 2>/dev/null)
  cmdline=$(tr "\0" " " < /proc/$pid/cmdline 2>/dev/null | cut -c1-220)
  printf '%8s %7s %-18s %s\n' "$watches" "$pid" "$comm" "$cmdline"
done | sort -nr | head -20

Observed focused repro:

10:08:58 total_watches=83,205
10:10:08 total_watches=83,205
10:11:18 total_watches=1,234,730
10:12:37 total_watches=1,234,736
10:13:55 total_watches=1,234,736
11:02:12 total_watches=1,234,754

The watches did not release after closing the extra Codex chat tabs/panels, and they remained after about 30 minutes. Developer: Reload Window briefly dropped the count, but the extension restarted and re-triggered the high watcher state.

Disabling workspace_dependencies through the bundled Codex CLI did not prevent this extension-side watcher path. The CLI reported the feature as disabled, but after VS Code reload the extension log still listed workspace_dependencies, started [git-repo-watcher], and the extension host climbed back to about 1.23M total watches.

What is the expected behavior?

The Codex VS Code extension should not recursively allocate hundreds of thousands or more than one million inotify watches in the extension host for a workspace where VS Code's own file watcher is correctly constrained by files.watcherExclude.

Expected behavior:

  • Respect VS Code workspace watcher excludes or apply equivalent filtering before recursive extension-side watching.
  • Avoid recursively watching .git/objects and large generated/runtime directories.
  • Bound watcher allocation and degrade gracefully if a workspace is too large.
  • Release extension-created watches when Codex chat tabs/panels are closed or when the triggering state ends.
  • Avoid desktop-wide ENOSPC/inotify exhaustion.

Additional information

The strongest isolation signal is process ownership:

normal VS Code file watcher: low watch count
Codex app-server child: about 213 watches
VS Code extension host: about 1,151,500 watches

A local mitigation confirmed that real workspace tree size drives the spike. Moving logs/ outside the real workspace tree and symlinking it back removed about 731k watches:

Before: Codex extension host about 1,151,522 watches
After moving logs/ out of the real tree: Codex extension host about 420,306 watches

That mitigation is only a workaround. It also shows that the extension host appears to expand the real filesystem tree under the workspace root instead of honoring the configured VS Code watcher excludes.

Closest related issue I found: #23191 reports the same general git-repo-watcher/ENOSPC family in Cursor Remote SSH when $HOME accidentally becomes a large Git repo. This issue is separate because it reproduces in VS Code with an intended repo workspace, measured extension-host watch ownership, and normal VS Code watcher excludes already in place.

Adjacent but not identical: #22421, #17394, #20295.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix VS Code Codex extension can allocate about 1M inotify watches on Linux large workspace [1 comments, 2 participants]