Codex stuck unresponsive in large git repos (autogen selfreport from codex)

[nos1609]

What version of Codex CLI is running?

codex-cli 0.125.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.5

What platform is your computer?

Windows 11 26H1 on ARM64

What terminal emulator and version are you using (if applicable)?

Windows Terminal (PowerShell)

What issue are you seeing?

Codex CLI can get stuck for minutes on very small tool calls when the current working directory is a problematic Git repository state.

In my case the repository had:

• a remote repository with a committed .venv and around 28k tracked files;
• a local checkout that was initially an unborn/no-commit branch;
• after attaching it to origin/main, normal git status / fetch triggered very slow Git operations and auto-gc;
• subsequent tiny shell tool calls from Codex, even just appending one line to a file repeatedly hung until I manually interrupted the turn.

Examples of commands that should have been instant but hung:

• simple pre-reply logging commands executed via Codex exec_command
• Git status/fetch in the same repo

The user-facing effect is severe:

• the assistant appears dead;
• the turn must be interrupted manually;
• after interruption, Codex may continue to be unstable in the same window;
• the task cannot proceed reliably.

However, the main reproducible problem here is that shell tool calls can hang due to the repository/Git state, and Codex does not time out or recover cleanly enough.

What steps can reproduce the bug?

1. On Windows 11, open Codex CLI in a repository where the remote contains a very large tracked .venv directory or similar generated
   dependency tree.
2. Make the local repo initially unborn/no-commit, or otherwise attach it manually to the remote branch:
   • add remote
   • fetch origin main
   • update refs / attach HEAD to main
3. Run commands from Codex that should be quick, for example:
   • git status --short
   • git fetch origin main
   • a tiny PowerShell command that appends one line to a local log file
4. Observe that Git may trigger auto-gc / long operations, and after that Codex shell tool calls may hang for minutes.
5. Interrupt the turn.
6. Repeat a tiny shell command. It may hang again even when the command itself is not Git-related.

Thread/context:

• Windows PowerShell, not bash/WSL.
• Remote is local git over LAN via http.

Uploaded thread: 019c6360-a2fd-7c90-bfb4-7404ddfe82f6

What is the expected behavior?

• shell tool calls should respect a hard timeout reliably;
• Codex should surface that the subprocess is still running or was killed;
• Codex should not block the entire assistant turn indefinitely on a simple command;
• Git auto-gc / slow status in the workspace should not make unrelated shell commands appear hung;
• after user interruption, the session should recover cleanly and not keep stale/hung subprocesses around.

Additional information

Important details:

• This is Windows on ARM64 / Snapdragon X Elite.
• The issue happened in PowerShell.
• The repo had a bad remote state: .venv was tracked, causing around 28k tracked files.
• git status emitted:
  Auto packing the repository for optimum performance. See "git help gc" for manual housekeeping.
• The workaround was to:
  • avoid running commands from the problematic repo working directory;
  • run tiny logging commands from C:\Users\<user> or another safe working
    directory;
  • disable local gc.auto;
  • clean up repo ignores/excludes separately.

Suggested improvement:
Codex CLI should have stronger subprocess lifecycle handling on Windows:

• hard kill process trees on timeout/interruption;
• show which command is still running;
• avoid silently leaving the assistant blocked on a shell command;
• optionally warn when cwd is a repo with huge tracked dependency/cache directories such as .venv.

[zhoustan]

+1. From my side, even w/o powershell, the same problem occurs: countless git child processes are launched by codex, causing cpu usage to reach its limit (32 core, 99% usage in total, less than 1% usage per process) and resulting in machine crashes. Is there any plan to fix it?