macOS desktop polls Git for historical workspaces while idle (~3.6 git processes/sec, 6–8% CPU)

Summary

On macOS, the Codex desktop app continuously spawns short-lived git subprocesses while the app is idle and unfocused. The polling appears to cover historical/non-active workspace directories rather than only the currently active workspace.

In this capture, the main desktop process remained at approximately 6–8% CPU with no active task. A high-frequency process capture observed 82 distinct short-lived git children in about 23 seconds (~3.6/sec).

This reproduces without a large virtualenv and without a workspace containing nested/embedded repositories.

Environment

• Desktop app version: 26.707.71524 (build 5263)
• Bundle identifier: com.openai.codex
• Application path/name on this build: /Applications/ChatGPT.app
• Codex Framework / Chromium: 150.0.7871.115
• macOS: 15.7.7 (24G720)
• Architecture: arm64

Observed behavior

After startup work had completed and the app was left idle/unfocused, repeated samples showed:

ChatGPT/Codex main process: 5.7–8.0% CPU
Memory:                   ~270 MB
Threads:                  56–57
State:                    sleeping (but waking continuously)

A 5-second sample of the main process showed a Node worker named git repeatedly going through:

node::fs::AfterStat
node::AsyncWrap::MakeCallback
uv_spawn
posix_spawn

The same sample also showed repeated libuv/FSEvents registration activity.

A separate high-frequency process capture found:

82 distinct (git) child PIDs in approximately 23 seconds
≈3.6 git subprocesses/second
direct parent: ChatGPT/Codex main process

The desktop log reported [git] [git-origins] worker-complete batches covering a total of 18 directories during startup. The local thread state contained 22 distinct non-archived working directories, including two stale temporary directories that no longer existed.

The measured spawn rate is consistent with walking roughly 18 historical directories every ~5 seconds.

Steps to reproduce

1. Use Codex Desktop over time with conversations associated with multiple repository/workspace directories.
2. Leave those conversations non-archived.
3. Open Codex Desktop, then leave it idle and unfocused. Do not run an agent task, build, or test.
4. Observe the main process:

top -l 5 -s 1 -pid <CODEX_PID> -stats pid,command,cpu,time,threads,state,mem

1. Capture a short process sample:

sample <CODEX_PID> 5 1

1. Poll children of the main process quickly enough to catch the short-lived Git processes. They frequently appear as (git) by the time ps observes them.

Expected behavior

When no task is active and no files are changing:

• CPU usage should return close to idle.
• Git metadata/status polling should be debounced and substantially reduced when the window is unfocused.
• Only currently relevant workspaces should be polled.
• Missing/stale workspace paths should use failure caching/backoff rather than being retried indefinitely.
• Git results should be cached instead of spawning multiple subprocesses per second.

Actual behavior

The app continues polling Git across a collection of historical workspace directories while idle, producing persistent subprocess churn and a stable 6–8% CPU load in the main desktop process.

Impact

This is less severe than the thousands-of-processes-per-second nested-repository case, but it creates continuous battery drain and unnecessary process/file-system activity whenever the desktop app remains open.

The cost is likely to grow with the number of historical/non-archived workspace directories.

Related issues

• #11524 — background scanning with a large virtualenv and stale workspace paths
• #29084 — nested repositories causing an extreme Git spawn and syspolicyd/trustd storm
• #29408 — repeated/stuck Git polling processes on Windows

This report appears distinct because it reproduces on a recent macOS build with ordinary repositories, no large generated dependency tree, no nested repository trigger, and no active task.

Additional diagnostics

I have a sanitized macOS sample report and the exact process-counting command available if maintainers need them. Raw logs are not attached because they contain local workspace paths.