codex - 💡(How to fix) Fix Codex stuck unresponsive in large git repos (autogen selfreport from codex) [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20200Fetched 2026-04-30 06:32:09
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
labeled ×4unlabeled ×1

Error Message

  • optionally warn when cwd is a repo with huge tracked dependency/cache directories such as .venv.

Fix Action

Fix / Workaround

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.
RAW_BUFFERClick to expand / collapse

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.

extent analysis

TL;DR

Avoid running Codex CLI commands from a repository with a large number of tracked files, and consider disabling local gc.auto to prevent Git auto-gc operations from causing hangs.

Guidance

  • Identify and avoid using repositories with large tracked directories like .venv as the current working directory for Codex CLI commands.
  • Disable local gc.auto to prevent Git from triggering auto-gc operations that can cause slow downs.
  • Run small logging commands from a safe directory outside of the problematic repository to avoid hangs.
  • Consider implementing stronger subprocess lifecycle handling in Codex CLI to prevent silent blocking on shell commands.

Example

No specific code example is provided, but running commands like git config --local gc.auto 0 can help disable local gc.auto and prevent auto-gc operations.

Notes

The issue seems to be specific to Windows 11 on ARM64 and PowerShell, and the presence of a large tracked .venv directory in the repository. The suggested improvements are focused on improving subprocess handling in Codex CLI to prevent hangs and silent blocking.

Recommendation

Apply workaround: Avoid running commands from problematic repositories and disable local gc.auto to prevent auto-gc operations, as this can help mitigate the issue until a more permanent fix is implemented in Codex CLI.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Codex stuck unresponsive in large git repos (autogen selfreport from codex) [1 participants]