Codex desktop exhausts the Linux file-watch limit by watching .venv, cache, and Git-internal files

Confirming this on a different stack, and adding root-cause evidence from the shipped bundle plus a node_modules case that makes the scale worse than .venv.

Environment: ChatGPT desktop 26.818.41705, Ubuntu 22.04.5 LTS, kernel 6.8.0-138-generic.

Root cause in the shipped code. In /usr/lib/chatgpt/resources/app.asar, the git-repo-watcher class (logger name git-repo-watcher, telemetry op codex.git.watcher_metadata) registers its working-tree watch target with recursive: true. That watch target carries no ignore list at all — there is no node_modules/.venv exclusion, no .gitignore awareness, and no setting that scopes or disables it. On Linux the backend is inotify, so a recursive watch costs one watch per directory in the tree. For contrast, the neighbouring git-init-watcher in the same bundle correctly uses recursive: false.

Scale on a JS monorepo. My workspace is a multi-repo Node.js tree:

dirs total:            103,725
inside node_modules:    90,600   (87%)
fs.inotify.max_user_watches: 65,536

So a single connected folder asks for ~1.6x the entire per-user allowance, and 87% of that is dependency directories that can never produce a meaningful git change. Failures in one day:

$ journalctl --since today | grep -c inotify_add_watch
6,493      # all from chatgpt.desktop, none from any other process

Sample paths it tried to watch:

job-watcher/node_modules/@opentelemetry/otlp-transformer/build/esm/metrics/protobuf
login-service/node_modules/@elastic/transport/node_modules/@opentelemetry/api/build/esm/baggage/internal
node_modules/@radix-ui/react-checkbox/node_modules/@radix-ui/react-slot/dist

Why this deserves priority over a normal watcher bug. max_user_watches is a per-user, system-wide resource. Once the desktop app drains it, every other process on the machine silently loses file watching — editors, dev servers, bundlers, test runners. The app degrades tools it has nothing to do with, and the failure surfaces in those tools, so users do not attribute it to Codex.

Suggested fix, cheapest first: the working-tree watcher only needs to know that the tree changed, so honouring .gitignore (or even a hardcoded skip of node_modules, .venv, __pycache__, .git/objects) at the recursive-watch level would remove the overwhelming majority of watches. A user-facing opt-out would be a reasonable stopgap while that lands.

Neither documented workaround is acceptable as a default: not connecting large repos defeats the product, and raising max_user_watches asks every Linux user to re-tune a kernel limit because one app has no exclusion list.

Confirming this on another supported Ubuntu system, including direct /proc mapping and an independent check of the latest shipped bundle.

Environment

• Ubuntu 24.04.4 LTS, kernel 6.8.0-138-generic, x86_64
• ChatGPT desktop 26.820.60940
• Installed package matched the current APT candidate when measured
• Multiple complete application restarts have provided only temporary relief; the same exhaustion returns

Direct inotify evidence

At one verified high-water snapshot:

• fs.inotify.max_user_watches = 65,536
• Total watches owned by the user: 65,496
• Main ChatGPT process: 62,202 watches across four inotify instances
• All other processes combined: 3,294 watches

The same main PID released and recreated large watch groups during sampling; observed counts included 29,824 -> 4,909 -> 26,675 -> 4,909 -> 15,437 -> 62,202. This is not merely one stable legitimate watch set.

I mapped the two dominant instances through their /proc/<pid>/fdinfo inode/device records:

• About 15,432 watches mapped entirely to Git metadata trees.
• A 46,762-watch working-tree instance mapped completely to repository paths:
• 29,171 under .venv
• 13,854 under generated dependency trees
• 955 under generated build output
• 1,485 under nested worktrees outside the categories above
• 556 under node_modules
• 741 other paths

Repository names, usernames, and absolute paths are intentionally omitted.

Independent latest-build implementation check

In the current /usr/lib/chatgpt/resources/app.asar, I independently confirmed that git-repo-watcher adds the repository root as a working-tree directory target with recursive: true. The file-watch request contains no registration-time ignore list. Failed watch sessions are scheduled for retry after 1,000 ms. The Git-internal-path predicate is used when handling delivered events, not to prevent recursive watches from being allocated.

A separate 30-second observation found main-process RSS cycling between roughly 646 MiB and 1.39 GiB while the PID remained unchanged. I am not claiming that short sample alone proves a monotonic memory leak, but it is consistent with the repeated watcher construction and teardown.

This evidence supports an application defect triggered by large but ordinary project layouts, rather than an inotify or disk configuration problem. The key fixes appear to be registration-time exclusions, repository-level watcher deduplication, and bounded/backed-off recovery after quota exhaustion.