# fix\(server\): worktree creation no longer times out fetching busy repos · PR \#18537 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/pull/18537)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: open

Source repository: Unavailable fork

Source branch: t3/configure-worktree-fetch-timeout

Target branch: main

Head commit: e0882fad916b3a5f9020313149a87e503aa5ddae

[Discussion and reviews](https://git.cafe/pingdotgg/t3code/pull/18537)

[Commits](https://git.cafe/pingdotgg/t3code/pull/18537/commits?format=markdown)

[Files changed](https://git.cafe/pingdotgg/t3code/pull/18537/diffs?format=markdown)

## Description

---

Creating a worktree from origin could time out during a healthy fetch on a busy repository. That fetch inherited the 30-second command limit even though the following checkout allows five minutes.

`fetchRemote` now uses the same five-minute bound as worktree creation, including its existing ref-lock retry and missing-branch fallback. Slow fetches also stay outside the short-command semaphore, so they do not hold slots needed by status commands. A genuinely hung fetch can now take five minutes to fail.

The regression uses real git and a local bare remote with an Effect test clock: a fetch lasting over 30 seconds succeeds and updates the remote ref. Removing the timeout override reproduces the failure. The existing timeout test still proves that a hung fetch is bounded and not retried.

After merging [current main](https://github.com/pingdotgg/t3code/commit/c274a251510e4bb035f8479a7f1e96443cd2503c), all 166 GitVcsDriverCore tests, server typecheck, targeted lint and formatting pass at [e0882fa](https://github.com/watson/t3code/commit/e0882fad916b3a5f9020313149a87e503aa5ddae). Fresh independent Opus and Sol reviews found no blocking defects.

The broader test run exposed a local executable-bit fixture failure on cups; current main CI already passed that fixture. One `checkout-index --force` call makes the test file on disk match its staged executable mode, retaining both mode-change assertions. The cause of the environment difference was not identified. A real launch against a slow external remote was not exercised; no UI changes require screenshots.

Explicit maintainer approval of the longer timeout policy remains a landing requirement.

Original fix by [@watson](https://github.com/watson) in [#18537](https://github.com/pingdotgg/t3code/pull/18537). Maintainer takeover by Claude Opus 5.5 and Claude Fable 5.1 through T3 Code, independently reviewed by Claude Opus 5.5 and GPT-6.1-Sol through the Codex harness.