High idle CPU from background Git scanning of venv/site-packages (desktop)
Summary
Codex desktop shows high CPU while idle when a workspace includes a large Python virtualenv venv/lib/python3.12/site-packages under a Git-visible tree.
At the same time, macOS syspolicyd and trustd also spike.
Environment
- Codex desktop:
260210.1703 - Electron:
40.0.0 - macOS (Apple Silicon)
- Workspace opened in Codex:
/Users/dq/CC - Heavy subtree:
/Users/dq/CC/dq/chatbi-rag-test/venv/lib/python3.12/site-packages- ~14,310 files, ~474 MB
Evidence
Observed around 2026-02-11 09:55-09:57 local time:
- Codex: up to
70.8% - syspolicyd: up to
138.7% - trustd: up to
100.7%
Codex spawned repeated Git child commands like:git --no-optional-locks ... diff --no-index -- /dev/null dq/chatbi-rag-test/venv/lib/python3.12/site-packages/numpy/__init__.pyi
Also observed repeated ENOENT warnings for missing configured workspace paths, suggesting extra background probing.
Repro steps
- Open a large parent folder in Codex.
- Ensure one subtree contains a large Python virtualenv (
venv/site-packages) with many files. - Leave Codex idle.
- Observe high CPU in Codex +
syspolicyd+trustd, with transient Gitdiff --no-indexchildren.
Expected
Idle CPU should stay low, and background scanning should avoid generated dependency directories.
Workaround that fixed it
- Remove stale/overly-broad trusted workspace entries in
~/.codex/config.toml. - Ignore heavy generated folders in experiment area (
venv,.venv,site-packages,vector_data,chroma*).
After this, CPU returned near idle (Codex ~0.0%-0.1%).
Request
Please optimize background repository scanning defaults (exclude generated dirs, debounce/concurrency limits, cache ENOENT with backoff), and add a user setting to limit/disable background scan scope.
<img width="2464" height="306" alt="Image" src="https://github.com/user-attachments/assets/d06e90f8-49f7-4b31-bfb9-44231190a37f" />
3 Comments
We've made a number of perf improvements this past week related to git scanning. Please try the latest version of the app and let us know if you're able to repro this still.
Another data point from a MacBook Air (Apple Silicon) on macOS 26.4 using the Codex desktop app.
What I observed:
trustdandsyspolicyd, which repeatedly sat around ~40-60% CPU each.gitchild processes being spawned by Codex during this time.Important detail from local debugging:
/usr/bin/git(git version 2.50.1 (Apple Git-155)), and that path appears to trigger repeated trust/signature checks on every high-frequency git invocation.syspolicydback togit, andtrustdlogs showed peer connections to Codex process IDs.Workaround that helped a lot:
/usr/bin/git.gitto a non-shim binary instead (first via Xcode’s real git, then with Homebrewgit 2.53.0).After that change,
trustd/syspolicyddropped back near idle (for examplesyspolicydfell to ~2.6% andtrustddisappeared from the top CPU list), and the worst lag/heat issue stopped.So this may not only be about scanning large trees; there may also be a macOS-specific interaction between Codex’s high-frequency git usage and
/usr/bin/git/ trust evaluation.Environment notes:
git is /usr/bin/gitgit is /opt/homebrew/bin/gitIf helpful, I can share a more detailed reproduction / process snapshot, but the shortest summary is: opening Codex caused repeated git activity, which in turn drove
trustd+syspolicydhigh enough to create visible lag, heat, and battery drain; switching away from/usr/bin/gitmitigated it.Adding another current repro/data point on a newer Codex Desktop build.
Feedback ID:
019dbfcc-ddc6-7890-b641-f94a87b43e7bThis still reproduces for me on April 24, 2026 with only one Codex agent/thread actively running. It does not appear to require multiple parallel agents.
This issue has persisted across multiple local troubleshooting passes and app restarts/updates on this machine; the concrete repro details below are from the current build,
26.422.21637.Environment:
26.422.2163741.2.026.4.1/Users/<user>/Documents/Codex/2026-04-24/whenever-i-use-the-codex-appObserved live process usage while one agent was running:
/Applications/Codex.app/Contents/MacOS/Codex: ~240-270% CPU/Applications/Codex.app/Contents/Resources/codex app-server: ~25-35% CPUSkyComputerUseClienthelper processes were present but individually tiny, usually ~0.1-0.2% CPU, so Computer Use itself did not look like the main source of the burn.The current workspace was a projectless Codex folder and not a git repo:
Codex app-state/log evidence showed repeated git metadata failures against that non-repo folder, including:
The app-state snapshot also showed repeated git worker activity while hot:
git_worker_invocations_last_30s: roughly 20-70thread_count_total: 17thread_count_active: 4-5turn_count_total_loaded: ~193-199item_count_total_loaded: ~5,500-5,700host_descendant_mcp_process_count: 43app_server_stdio_bytes_read_last_30s: ~2.3-2.5 MBOne extra wrinkle: logs also repeatedly showed screen-capture/display reconciliation failures:
A short sample of the hot main Codex process pointed mostly at Electron/V8 event-loop and stream processing work, not a native helper spinning independently.
I also verified code signing/notarization for both
/Applications/Codex.appand the bundledSkyComputerUseClient.app; both checks passed. So this does not look like a code-signature/helper crash issue.My current read is that this is still an app-side background loop: repeated git metadata polling against a folder known not to be a git repo, possibly compounded by repeated screen-capture/display enumeration retries, while a single active agent is running. I can include current Codex session logs as supporting evidence.
Note: this report was troubleshooted and generated with help from Codex GPT-5.5 during a read-only local debugging pass.