[Bug]: New worktree creation fails when git fetch exceeds the hardcoded 30s timeout

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Add a repository whose git fetch origin takes longer than 30 seconds, for example a large or stale monorepo with many remote refs.
2. Configure new threads to use New worktree with Start from origin enabled.
3. Start a new chat/thread.
4. Wait while T3 prepares the worktree.

This was reproduced with a remote advertising about 1,503 heads and 10,494 tags. Basic authentication and connectivity were healthy: a targeted git ls-remote completed in 1.61 seconds.

Expected behavior

T3 should allow the fetch to complete and then create the worktree. A long-running network Git operation should not fail solely because it exceeds a fixed 30-second budget. Ideally the operation should provide progress/cancellation, or use a configurable timeout.

Actual behavior

Thread/worktree creation fails after almost exactly 30 seconds:

Git command failed in GitVcsDriver.fetchRemote (<repo>): Git command timed out.

The installed implementation has a default Git timeout of 30,000 ms. fetchRemote runs git fetch --quiet <remote> without overriding that default.

Running the same command directly, without T3's deadline, completed successfully in 64.90 seconds. Immediately afterward, the identical fetch took 2.73 seconds. Repeated T3 attempts had left 56 incomplete tmp_pack_* files totaling about 199 MB, consistent with Git being terminated mid-download before it could install the pack.

This creates a retry loop: every new-thread attempt downloads part of the pack, gets terminated at 30 seconds, and has to begin the catch-up again.

Impact

Major degradation or frequent failure

Version or commit

t3@0.0.41-nightly.20260908.1400

Environment

macOS 26.6.1 (arm64), Node.js 26.4.0, Apple Git 2.50.1, HTTPS GitHub remote, Codex app-server provider.

Logs or stack traces

GitVcsDriver.fetchRemote
durationMs: 30011.46
outcome: Failure
cause: GitCommandError: Git command failed in GitVcsDriver.fetchRemote (<repo>): Git command timed out.

$ time git ls-remote --heads origin refs/heads/<base-branch>
real 1.61
exit 0

$ time git fetch --quiet origin
real 64.90
exit 0

$ time git fetch --quiet origin
real 2.73
exit 0

Workaround

Run the full fetch manually outside T3 and allow it to finish, then retry creating the thread:

git -C <repo> fetch origin

This unblocked the affected repository because subsequent incremental fetches fit within 30 seconds.

Related issues

• #9780 reports the analogous fixed-timeout failure for git clone; this issue concerns GitVcsDriver.fetchRemote during new-worktree thread creation.
• #9340 covers the same bootstrap fetch path but a different bug involving hardcoded origin selection and missing progress.
• No existing issue found for the 30-second fetchRemote timeout itself.

Suggested direction

Consider running remote fetches with timeoutMs: null, as push operations already do, or use a substantially larger/configurable timeout. Fetching only the selected branch with --no-tags could also avoid downloading and negotiating unrelated refs during worktree bootstrap.

Start in apps/server at the GitVcsDriver.fetchRemote entry point and inspect how its default Git timeout is applied; compare it with the push operations that already use no timeout. Reproduce with a fetch that exceeds 30 seconds, then verify that new-worktree thread creation completes successfully without terminating the fetch prematurely.