›_ Codex Issues
Codex Issues / #30635

Codex app-server spins on repeated git rev-parse when workspace has invalid empty .git directory

Open 💬 4 comments Opened Jun 30, 2026 by Getwrongg
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

If a Codex workspace contains a .git directory that exists but is not a valid Git repository, the local Codex app-server appears to enter a tight Git root detection loop. It repeatedly launches:

git -c core.hooksPath=/dev/null -c core.fsmonitor= rev-parse --show-toplevel

On my machine this kept the app-server around one CPU core continuously until the invalid .git directory was fixed.

Environment

  • Codex CLI: codex-cli 0.142.4
  • Build path indicated: 0.142.4-x86_64-unknown-linux-musl
  • OS: Linux x86_64, Ubuntu kernel 7.0.0-27-generic
  • Surface: Codex desktop/local app-server, process shown as codex app-server --listen unix://

Likely repro

  1. Create or open a workspace directory that contains an empty/broken .git directory:

``bash
mkdir -p /tmp/codex-broken-git/.git
cd /tmp/codex-broken-git
git rev-parse --show-toplevel
``

  1. Confirm Git exits with:

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

  1. Open that workspace in Codex desktop/app-server.
  2. Watch the app-server process CPU and child process creation.

Observed behavior

  • The app-server stayed hot for several minutes, typically around 90% to 160% CPU in interval readings.
  • A short strace sample showed 1494 execve attempts involving git ... rev-parse --show-toplevel in roughly 3 seconds.
  • The app-server repeatedly searched PATH for git, then launched /usr/bin/git.
  • The loop persisted after the Codex log database was replaced with a fresh small database, so this did not appear to be caused by log DB corruption.
  • Running git init in the affected workspace, turning the empty .git directory into valid Git metadata, immediately dropped app-server CPU from roughly one core to low single digits.

Expected behavior

Codex should treat an invalid .git directory as either:

  • not a Git repository, or
  • a recoverable workspace metadata error that is logged/surfaced once,

and then cache/back off the failed root detection. It should not continuously spawn git rev-parse in a tight loop.

Workaround

Either remove the broken .git directory or initialize/fix it:

rm -rf .git
# or
git init

After git init, the app-server CPU returned to normal.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #29492

Powered by Codex Action

wgu9 · 1 month ago

Current-main source trace for the likely split here:

  • codex-rs/git-utils/src/info.rs::get_git_repo_root is a lightweight marker walk. It treats any ancestor .git file or directory as a repo root marker without validating that Git can actually open it.
  • ThreadMetadataSync::for_create in codex-rs/thread-store/src/thread_metadata_sync.rs then uses that marker result as the gate for collect_git_info(cwd).await.
  • collect_git_info immediately shells out to Git (rev-parse --git-dir, then other metadata commands if successful).
  • Separately, codex-rs/git-utils/src/operations.rs::resolve_repository_root shells out to git rev-parse --show-toplevel, and the shared run_git helper injects -c core.hooksPath=/dev/null, matching the command shape reported in this issue.

So an empty/broken .git directory can be classified as "git workspace" by Codex's marker-only path while Git itself rejects it as not a repository. If that classification is recomputed by a workspace/status/watch loop without negative caching, the app-server can keep spawning short-lived failing Git commands.

Suggested fix boundary:

  • Introduce one canonical "validated git workspace" probe that distinguishes:
  • no marker,
  • valid git repository,
  • malformed/inaccessible git metadata.
  • Cache the malformed result for the current workspace until a relevant filesystem change happens under .git or the cwd changes.
  • Make callers that only need telemetry or metadata treat malformed git metadata as non-git plus a one-shot diagnostic, not as a reason to repeatedly retry Git commands.

Regression shape:

  • Create a temp workspace containing an empty .git directory.
  • Exercise the app-server path that opens/observes the workspace.
  • Assert no tight retry loop occurs: at most one/few Git probes during the observation window, and the workspace is surfaced as non-git or malformed-git instead of repeatedly running rev-parse.
ro4st · 1 month ago

Same issue on a Linux SSH remote used from Codex Desktop on Windows. The workspace contained an empty/invalid .git-directory. After deleting the .git-directory the high CPU issue appears to be resolved.

kalayciburak · 1 month ago

I prepared a fix branch for this, but GitHub says this repository only allows collaborators to open pull requests.

Branch: https://github.com/kalayciburak/codex/tree/fix/validated-git-metadata-root
Compare: https://github.com/openai/codex/compare/main...kalayciburak:fix/validated-git-metadata-root

The change adds metadata-specific Git root validation so empty .git directories and broken gitdir: pointer files are ignored before background Git metadata probes. It covers turn metadata, memory workspace metadata, rollout session metadata, thread metadata sync, and git_diff_to_remote.

Validated with:

  • cargo test -p codex-git-utils git_repo_root_for_metadata --lib
  • cargo check -p codex-git-utils -p codex-core -p codex-rollout -p codex-thread-store
  • cargo fmt --check
  • git diff --check