Codex App worktree pre-flight hangs after checkout during AGENTS.override.md scan in large repo

🤖 Filed by an AI agent on behalf of the reporter. Repo names, local paths, branch names, commit SHAs, and other private details have been intentionally sanitized.

What version of Codex is running?

Codex App 26.609.41114 (CFBundleVersion 3888)

Codex CLI:

codex-cli 0.140.0-alpha.2

What platform is your computer?

macOS 26.5.1 (Build 25F80), arm64
git version 2.54.0

What issue are you seeing?

Codex App worktree pre-flight can appear stuck after Git finishes checkout in a large repository.

The UI shows:

[info] Starting worktree creation
Preparing worktree (detached HEAD <sha>)
Updating files: 100% (...), done.
HEAD is now at <sha> <commit subject>

At that point the UI remains on "Creating a worktree and running setup" for a long time. In one observed run, the worktree directory was created at about 14:46, but the Codex thread did not get registered and become usable until about 15:00, roughly 14 minutes later.

During the apparent hang:

• git worktree add had already finished.
• The new detached worktree existed under $CODEX_HOME/worktrees/<id>/<repo>.
• No thread/session was visible yet for that worktree.
• If the user clicked "Work locally instead" before waiting long enough, the detached worktree was left behind with no thread associated with it.

The live process tree showed Codex Desktop's main UI process running this Git command in the original/base checkout, not in the new worktree:

git -c core.hooksPath=/dev/null -c core.fsmonitor= \
  ls-files --others --ignored --exclude-standard -z -- ':(glob)**/AGENTS.override.md'

That command was still running after more than 4 minutes in the base checkout. After it eventually completed, the Desktop-created worktree became a normal active Codex thread and read-only repo exploration worked.

This looks related in product area to #26154, but the observed failure point appears different:

• In #26154, git worktree add itself hangs when Codex forces core.fsmonitor=true.
• In this case, git worktree add appears to complete, and the delayed step appears to be a post-checkout AGENTS.override.md discovery scan over ignored/untracked files.
• The repo's effective core.fsmonitor was false during this investigation; core.untrackedCache was true.

Repo shape

The repository is large:

• Around 160k tracked files.
• Multiple worktrees.
• Large ignored/generated directories in the base checkout, including roughly:
• build/: about 9 GiB
• .gradle/: about 3 GiB

Those ignored directories existed before, and Codex App worktree creation used to work acceptably in this repo. This feels like either a recent behavior change or a regression in pre-flight instruction discovery.

Steps to reproduce

In a large Git repository with sizable ignored/generated directories:

1. Start a new Codex App thread using Worktree.
2. Select the default/base branch.
3. Submit a simple prompt, for example "Explore the codebase."
4. Wait until the pre-flight log reaches:

``text
Updating files: 100% (...), done.
HEAD is now at <sha> <commit subject>
``

1. Inspect local processes while the UI is still stuck.

Observed command:

git -c core.hooksPath=/dev/null -c core.fsmonitor= \
  ls-files --others --ignored --exclude-standard -z -- ':(glob)**/AGENTS.override.md'

Expected behavior

After Git finishes creating the worktree, Codex App should open/register the thread promptly.

If Codex needs to discover AGENTS.override.md, it should avoid a blocking full ignored/untracked recursive scan in very large repositories, or it should use a bounded timeout/fallback and show progress that explains what is happening.

Actual behavior

The UI appears stuck for many minutes after checkout is complete. The worktree exists, but the thread is not visible/usable until the post-checkout scan completes. Users may click "Work locally instead", leaving detached orphan worktrees behind.

What was ruled out

The issue still reproduced after disabling the repo's local environment setup file and clearing Codex App's remembered local environment selection for the repository. That suggests the delay is not caused by the local environment setup script.

Suggested fix direction

For AGENTS.override.md discovery, consider avoiding git ls-files --others --ignored --exclude-standard with a repo-wide recursive glob. Possible alternatives:

• Check only tracked/project-scope candidate paths along the current directory ancestry.
• Use direct filesystem existence checks for known candidate locations.
• Avoid traversing ignored/generated directories.
• Add a timeout/fallback around this discovery step.
• Show progress or a diagnostic if instruction discovery is still running after checkout.