Windows Desktop background Git probes can create CPU/I/O storms via conhost and AV scanning

Open 💬 1 comment Opened Jun 27, 2026 by yuzhiyang1
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/master
  • git -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.rs
  • TurnMetadataState::spawn_git_enrichment_task() calls fetch_workspace_git_metadata().
  • That concurrently runs get_head_commit_hash, get_git_remote_urls_assume_git_repo, and get_has_changes.
  • get_has_changes runs git 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::Command with timeout and kill_on_drop, but on Windows they do not suppress console creation.
  • diff_against_sha() runs git ls-files --others --exclude-standard and then launches one git diff --no-index per untracked file via join_all, with no fan-out cap.
  • codex-rs/tui/src/branch_summary.rs plus app-server command/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.rs
  • gitDiffToRemote recomputes 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

  1. Treat turn metadata has_changes as best-effort.
  • Give the git status --porcelain branch a short budget, e.g. 250ms.
  • If it times out, omit only has_changes; still keep commit hash and remote URLs.
  1. Suppress Windows console creation for non-interactive background commands.
  • Add CREATE_NO_WINDOW for internal Git metadata commands.
  • Add the same for pipe-backed, non-PTY app-server commands used by status surfaces and background probes.
  1. Cap untracked diff fan-out.
  • Avoid launching unbounded git diff --no-index commands for every untracked file.
  • Consider a cap such as 32 files plus an omitted-files marker in the diff payload.
  1. 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.
  1. 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/codex main around c464468493

Triage recommendation

Category: bug
State: needs-triage
Suggested labels: bug, windows-os, app, performance, Git

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗