Windows Desktop background Git probes can create CPU/I/O storms via conhost and AV scanning
This was generated by AI during triage.
Summary
Codex Desktop on Windows can become very expensive while a Git workspace is open because several background paths spawn short-lived Git/helper processes. On Windows each process can create conhost.exe and can be inspected by Defender or corporate AV, so otherwise small metadata probes can turn into system-wide CPU/I/O pressure.
This appears related to, but more source-specific than, #17229 and #26812. Those issues report the user-visible symptom: many git.exe / conhost.exe processes and severe machine slowdown. This issue tracks the code paths and concrete guardrails that should reduce the blast radius.
What I observed
While investigating a current main checkout, a short local process sample on Windows saw Codex-owned background Git commands such as:
git -c core.hooksPath=NUL -c core.fsmonitor= merge-base HEAD origin/mastergit -c core.hooksPath=NUL -c core.fsmonitor= write-tree
The same machine had more than one Codex app-server process alive (Desktop plus extension-hosted app-server), which means each background Git probe path can be multiplied across clients.
The exact sample was taken from inside Codex, so PowerShell/conhost counts in that sampling window are partially polluted by the diagnostic command itself. The Git command names above were still useful for tracing the code paths.
Source paths that look risky
codex-rs/core/src/turn_metadata.rsTurnMetadataState::spawn_git_enrichment_task()callsfetch_workspace_git_metadata().- That concurrently runs
get_head_commit_hash,get_git_remote_urls_assume_git_repo, andget_has_changes. get_has_changesrunsgit status --porcelain, which can scan a large worktree.- The lower-level Git command has a 5s timeout, but this metadata field does not currently have a short best-effort budget.
codex-rs/git-utils/src/info.rs- Internal Git commands use
tokio::process::Commandwith timeout andkill_on_drop, but on Windows they do not suppress console creation. diff_against_sha()runsgit ls-files --others --exclude-standardand then launches onegit diff --no-indexper untracked file viajoin_all, with no fan-out cap.
codex-rs/tui/src/branch_summary.rsplus app-servercommand/exec- Status-line summary can run
rev-parse,remote,remote show,merge-base,diff --numstat,gh pr view, etc. - These run through non-tty app-server command execution. On Windows pipe-backed background commands should not need a visible console host.
codex-rs/app-server/src/request_processors/git_processor.rsgitDiffToRemoterecomputes the full diff on each request. There is no apparent single-flight/debounce/cache at the server boundary.
Why this matters
The individual Git commands are often fast when run by hand, but Desktop can spawn them repeatedly and concurrently. On Windows, process creation plus conhost.exe plus AV inspection can dominate the cost, especially on large repositories, HDD-backed workspaces, workspaces with many untracked files, or machines with enterprise security tooling.
This makes the app feel idle while the OS is busy doing process, filesystem, and AV work.
Suggested fixes
- Treat turn metadata
has_changesas best-effort.
- Give the
git status --porcelainbranch a short budget, e.g. 250ms. - If it times out, omit only
has_changes; still keep commit hash and remote URLs.
- Suppress Windows console creation for non-interactive background commands.
- Add
CREATE_NO_WINDOWfor internal Git metadata commands. - Add the same for pipe-backed, non-PTY app-server commands used by status surfaces and background probes.
- Cap untracked diff fan-out.
- Avoid launching unbounded
git diff --no-indexcommands for every untracked file. - Consider a cap such as 32 files plus an omitted-files marker in the diff payload.
- Add single-flight or short TTL caching for
gitDiffToRemote.
- Concurrent requests for the same cwd should share one computation.
- A short cache window would avoid repeated full diffs during UI refreshes.
- Consider status-line Git summary backoff.
- If branch summary commands are slow or fail, back off instead of retrying on every turn boundary.
Expected behavior
Opening or idling in a Git workspace should not continuously create enough Git/conhost activity to make the whole system sluggish.
Actual behavior
In affected Windows workspaces, Codex Desktop can spawn repeated background Git/helper commands. The OS and AV overhead around those short-lived processes can make the machine very slow even when Codex appears idle.
Environment
- OS: Windows
- Product area: Codex Desktop / app-server / Git metadata
- Current source inspected:
openai/codexmain aroundc464468493
Triage recommendation
Category: bug
State: needs-triage
Suggested labels: bug, windows-os, app, performance, Git
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗