High idle CPU from background Git scanning of venv/site-packages (desktop)

Open 💬 3 comments Opened Feb 12, 2026 by daiqi1235
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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

  1. Open a large parent folder in Codex.
  2. Ensure one subtree contains a large Python virtualenv (venv/site-packages) with many files.
  3. Leave Codex idle.
  4. Observe high CPU in Codex + syspolicyd + trustd, with transient Git diff --no-index children.

Expected

Idle CPU should stay low, and background scanning should avoid generated dependency directories.

Workaround that fixed it

  1. Remove stale/overly-broad trusted workspace entries in ~/.codex/config.toml.
  2. 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" />

View original on GitHub ↗

3 Comments

etraut-openai contributor · 6 months ago

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.

Timmycosmos · 4 months ago

Another data point from a MacBook Air (Apple Silicon) on macOS 26.4 using the Codex desktop app.

What I observed:

  • As soon as I opened Codex, app launches became noticeably laggy and the machine got hot quickly.
  • Battery drain was severe while Codex was open, and the problem largely disappeared again after quitting Codex.
  • The main offenders were not just Codex itself, but macOS trustd and syspolicyd, which repeatedly sat around ~40-60% CPU each.
  • I was also able to see many short-lived git child processes being spawned by Codex during this time.

Important detail from local debugging:

  • On this machine, Codex was using /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.
  • I traced at least one of the transient PIDs being validated by syspolicyd back to git, and trustd logs showed peer connections to Codex process IDs.

Workaround that helped a lot:

  1. Restart Codex so it no longer used /usr/bin/git.
  2. Point git to a non-shim binary instead (first via Xcode’s real git, then with Homebrew git 2.53.0).
  3. Reopen Codex.

After that change, trustd/syspolicyd dropped back near idle (for example syspolicyd fell to ~2.6% and trustd disappeared 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:

  • Codex desktop app on macOS (not VS Code extension)
  • Xcode installed
  • Before workaround: git is /usr/bin/git
  • After workaround: git is /opt/homebrew/bin/git

If 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 + syspolicyd high enough to create visible lag, heat, and battery drain; switching away from /usr/bin/git mitigated it.

jordanschwartz-js · 4 months ago

Adding another current repro/data point on a newer Codex Desktop build.

Feedback ID: 019dbfcc-ddc6-7890-b641-f94a87b43e7b

This 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:

  • Codex Desktop: 26.422.21637
  • Electron: 41.2.0
  • macOS: 26.4.1
  • Architecture: arm64
  • Machine: Apple M5
  • Working folder: /Users/<user>/Documents/Codex/2026-04-24/whenever-i-use-the-codex-app

Observed 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% CPU
  • Codex Helper Renderer / GPU: ~10-20% CPU combined at times
  • SkyComputerUseClient helper 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:

fatal: not a git repository (or any of the parent directories): .git

Codex app-state/log evidence showed repeated git metadata failures against that non-repo folder, including:

worker_rpc_response_error errorMessage="Not a git repository"
method=stable-metadata workerId=git
git rev-parse --git-path codex-shell-environment.json
exitCode=128
cwd=/Users/<user>/Documents/Codex/2026-04-24/whenever-i-use-the-codex-app

The app-state snapshot also showed repeated git worker activity while hot:

  • git_worker_invocations_last_30s: roughly 20-70
  • thread_count_total: 17
  • thread_count_active: 4-5
  • turn_count_total_loaded: ~193-199
  • item_count_total_loaded: ~5,500-5,700
  • host_descendant_mcp_process_count: 43
  • app_server_stdio_bytes_read_last_30s: ~2.3-2.5 MB

One extra wrinkle: logs also repeatedly showed screen-capture/display reconciliation failures:

screen recording reconcile failed
error_message=screen capture display enumeration timed out after 5 seconds

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.app and the bundled SkyComputerUseClient.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.