Codex App has ~5s lag when opening a new durable thread in a git repo

What version of the Codex App are you using (From "About Codex" dialog)?

26.601.21317

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.19044.0 x64

What issue are you seeing?

Opening a new thread in the Codex App causes an obvious stall of about 5-6 seconds when the working directory is inside a git repository.

This appears to be a backend thread-start regression in the durable thread path, not just a UI rendering issue.

What steps can reproduce the bug?

1. Open the Codex App in a git repository.
2. Start a new thread.
3. Observe an approximately 5 second stall before the thread is ready.

Measured against the installed app-server over JSON-RPC:

• thread/start in H:\openai\codex: about 5.3s
• thread/start with ephemeral: true: about 14ms
• thread/start in a non-git temp directory: about 180ms
• thread/start in a tiny fresh git repo: about 5.9s

This isolates the regression to the non-ephemeral thread-persistence path when cwd is in a git repo.

What is the expected behavior?

Starting a new thread should be near-instant, or at least should not synchronously block for about 5 seconds on repo metadata collection during thread startup.

Additional information

Primary code path:

• codex-rs/thread-store/src/live_thread.rs calls ThreadMetadataSync::for_create(...) before thread/start returns.
• codex-rs/thread-store/src/thread_metadata_sync.rs eagerly collects git metadata during for_create(...).
• codex-rs/git-utils/src/info.rs defines GIT_COMMAND_TIMEOUT as 5 seconds.
• codex-rs/git-utils/src/info.rs collect_git_info(...) runs:
• git rev-parse --git-dir
• git rev-parse HEAD
• git rev-parse --abbrev-ref HEAD
• git remote get-url origin

Those subprocesses are launched in parallel and awaited together. If any one hangs until timeout, thread startup inherits almost exactly the 5 second pause.

git blame points the eager collect_git_info(cwd.as_path()).await call to commit c51c65ad09 (Unify thread metadata updates above store, 2026-05-12).

Likely fix directions:

1. Move git metadata collection off the thread/start critical path.
2. Create the durable thread immediately and backfill git info asynchronously via metadata update.
3. If some git metadata must remain synchronous, skip or heavily shorten the startup-time timeout budget, especially for remote get-url origin.

Notes from investigation:

• Disabling app instructions, skill instructions, plugins, bundled skills, MCP servers, and shell snapshotting did not materially change the delay.
• The lag reproduced with an empty temporary CODEX_HOME, so this does not depend on large local history or unusual user config.