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

[Pratham-commits-code]

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

• [Bug]: Clone fails when git clone exceeds a fixed 120s timeout #9780 reports the analogous fixed-timeout failure for git clone; this issue concerns GitVcsDriver.fetchRemote during new-worktree thread creation.
• [Bug]: New worktree thread on upstream/* base sits with no progress for ~1min on remote (bootstrap hardcodes origin fetch, streams no progress) #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.

[juliusmarminge]

Thanks for the tight repro — this checks out on current main (6c583620ff7ad3235b135af7107c0543467eecfa) and is still distinct from #9780 and #9340.

What’s going wrong

New-thread Start from origin bootstrap in apps/server/src/ws.ts always runs a full remote fetch before createWorktree:

yield* gitWorkflow.fetchRemote({
  cwd: bootstrap.prepareWorktree.projectCwd,
  remoteName: "origin",
});

GitVcsDriver.fetchRemote then runs git fetch --quiet <remote> with no timeout override and no refspec / --no-tags:

yield* executeGit(
  "GitVcsDriver.fetchRemote",
  input.cwd,
  ["fetch", "--quiet", input.remoteName],
  { env: STATUS_UPSTREAM_REFRESH_ENV, fallbackErrorDetail: `git fetch ${input.remoteName} failed` },
);

The Git driver default is a hard 30s (DEFAULT_TIMEOUT_MS = 30_000). If the caller does not pass timeoutMs, execute() kills the child and surfaces Git command timed out. — which matches the reported durationMs: 30011.46.

That deadline is the wrong budget for a catch-up fetch of ~1503 heads / ~10494 tags. Your unattended git fetch --quiet origin at 64.90s (then 2.73s incremental) plus a healthy 1.61s ls-remote rules out auth/connectivity. Killing Git mid-pack also explains the leftover tmp_pack_* files and the retry loop: the ref never advances, so the next attempt renegotiates the same transfer and dies at 30s again.

Why this isn’t a duplicate

• [Bug]: Clone fails when git clone exceeds a fixed 120s timeout #9780 is the same timeout shape on git clone (timeoutMs: 120_000 in SourceControlRepositoryService.cloneRepository). Sibling open PR: fix(source-control): allow clones to finish without a deadline #9844 (timeoutMs: null).
• [Bug]: New worktree thread on upstream/* base sits with no progress for ~1min on remote (bootstrap hardcodes origin fetch, streams no progress) #9340 is the same bootstrap path, but about hardcoded origin and missing progress — not the 30s kill.

The codebase already treats long network Git as unbounded or generously bounded: every pushCurrentBranch variant uses timeoutMs: null, and createWorktree uses WORKTREE_ADD_TIMEOUT_MS = 300_000 with a comment that the default 30s is too short on large trees. There is no user-facing Git command timeout setting.

Related work that does not close this

• fix(server): ignore tags during remote fetch #7619 (open) adds --no-tags --no-prune-tags to fetchRemote. That would help the 10k-tag case, but it still fetches every head under 30s.
• fix(server): start-from-origin worktrees no longer wait on a full git fetch #8393 / perf(server): parallelize worktree checkout and narrow the bootstrap fetch #9039 (closed, not merged) tried narrowing the bootstrap fetch to the selected branch. fetchRemoteTrackingBranch already exists (--no-tags + a single refspec) and is unused on this path.
• fix(server): fall back to local worktree base when origin fails #7667 (open) would fall back to the local base after a typed fetch error. That avoids a hard fail, but still kills the fetch and skips latest origin.
• [Bug]: Git status poller can fill the disk with orphaned tmp_pack_* files when the upstream fetch exceeds its 5s timeout #4296 / fix(server): clean status fetch temporary packs #4338 are the same tmp_pack_* leak pattern on the status 5s fetch, not this bootstrap call.

Suggested fix

1. Run this fetch without the 30s knife (timeoutMs: null, or a much larger bound), matching push / fix(source-control): allow clones to finish without a deadline #9844.
2. For Start from origin, fetch only the selected branch with --no-tags instead of every remote ref. Bootstrap only reads origin/<baseBranch> afterward.
3. Clean incomplete tmp_pack_* if a fetch is still interrupted, so retries cannot pile up ~200MB leftovers.

Workaround remains: finish git fetch origin once outside T3, then retry the thread.

Triage: confirmed bug on apps/server. Not a duplicate. Accepting for a server fix.