Worktree bootstrap fetch hangs for the full 30s timeout when a GUI SSH agent is waiting on key authorization #11930

Activity

1. juliusmarminge commented on Sep 15, 2026

   

   juliusmarminge

   on Sep 15, 2026

   Member

   More actions

   Thanks for the tight repro and the 1Password / git ls-remote timings. This checks out on current main (7235701de) and is still distinct from #10916.

   What’s going wrong

   New-thread New worktree + Start from origin in apps/server/src/ws.ts always runs gitWorkflow.fetchRemote before createWorktree:

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

   GitVcsDriver.fetchRemote then runs git fetch --quiet <remote> (scoped to the selected branch after #11633) with STATUS_UPSTREAM_REFRESH_ENV and no timeoutMs override:

   const STATUS_UPSTREAM_REFRESH_ENV = Object.freeze({
     GCM_INTERACTIVE: "never",
     GIT_ASKPASS: "",
     GIT_TERMINAL_PROMPT: "0",
     SSH_ASKPASS: "",
     SSH_ASKPASS_REQUIRE: "never",
   });
   
   // …
   const options = {
     env: STATUS_UPSTREAM_REFRESH_ENV,
     fallbackErrorDetail: `git fetch ${input.remoteName} failed`,
   };

   execute() still applies DEFAULT_TIMEOUT_MS = 30_000 when timeoutMs is omitted, then surfaces Git command timed out. That matches the traces (fetchRemote 30004ms / runGitCommand killed at exactly 30s) and the mobile card (COULD NOT START TASK + draft restore).

   Those five env vars only suppress terminal / askpass prompting. They do not touch an agent speaking over SSH_AUTH_SOCK. Git inherits process.env (so the socket is present), and IdentityAgent in ~/.ssh/config reaches the agent even if the server process never saw that socket. The child sits on the agent handshake; git makes no progress; Effect interrupts at 30s.

   GitVcsDriverCore.test.ts (makes background upstream status fetches non-interactive) asserts the five variables are set, but the GIT_SSH wrapper exit 1s immediately. It never exercises an agent that blocks.

   This is why it looks intermittent: it fails when nobody is at the machine to approve the tray prompt, which is exactly the mobile / tailnet case. The 30s knife also fires before 1Password’s own 60s prompt deadline, so a user who does notice the icon still has a short window.

   Repo size is a red herring here. 18 refs / 3.5M .git / one pack, and the same fetch is ~1.1s once authorized. Direct git ls-remote under the driver’s env, left unanswered, ran 60.86s and then communication with agent failed — the agent’s timeout, not a transfer timeout.

   Why this isn’t a duplicate of #10916

   Same symptom string, different cause:

   	#10916	this issue
   Remote	HTTPS	SSH + GUI agent (1Password)
   What git is doing	actually transferring a large/stale remote	blocked on key authorization; no pack progress
   Auth	healthy (ls-remote 1.61s)	agent prompt waiting, then agent timeout
   Repo	~1503 heads / ~10494 tags; unattended fetch 64.90s	18 refs, 3.5M; authorized fetch ~1.1s
   Leftovers	tmp_pack_* from mid-download kills	none reported

   #11633 already scoped the bootstrap fetch. That helps #10916’s 10k-tag case. It does nothing for an SSH handshake that never starts the transfer.

   Related work that does not close this

   • Open PR fix(server): let the start-from-origin fetch outlive the 30s git timeout #10943 (timeoutMs: null on fetchRemote) is the right fix for [Bug]: New worktree creation fails when git fetch exceeds the hardcoded 30s timeout #10916 and must stay Fixes #10916 only. Do not attribute Closes #11930. Lifting the deadline turns a 30s false timeout into a stall until the agent’s own prompt timeout (60s here), then a real auth error. Better message, worse latency for the mobile case.
   • [Bug]: OrbStack systemd service misses SSH_AUTH_SOCK, causing worktree creation to fail at git fetch #10179 / open PR fix(server): recover the login shell SSH agent #10312 are the inverse: SSH_AUTH_SOCK missing under OrbStack systemd / login-shell hydration, so the agent is unreachable (Permission denied (publickey)), not prompting. If fix(server): recover the login shell SSH agent #10312 lands, more service-launched servers will have a socket — and GUI agents on that socket will start hitting this hang instead of a fast publickey failure.
   • Closed [Bug]: Keeps on asking to unlock the SSH keys even when doing nothing (when using 1Password ssh agent) #1190 / Git fetch running constantly in the background is very annoying #356 / [codex] add configurable automatic git fetch interval #2605 are repeated unlock prompts from the background status fetch (fetchRemoteForStatus, 5s budget, now configurable / disableable). [codex] add configurable automatic git fetch interval #2605 added SSH_ASKPASS_REQUIRE=never and the fetch-interval setting. That closed the askpass UI loop. It does not cover per-app agent authorization over SSH_AUTH_SOCK, and it is not the start-from-origin bootstrap path.

   Suggested fix

   Do not retune the deadline. Detect an outstanding agent handshake with no fetch progress and fail with an authorization-specific error (and keep the prompt in the project draft). A short “no git/ssh progress” window on an SSH remote is enough to distinguish this from a slow pack. The current Git command timed out. string points at the network/repo and is why this is hard to self-diagnose.

   A timeout-only change, including #10943, is the wrong tool for this issue.

   Workaround

   Move origin to HTTPS and use gh auth git-credential. The reporter verified fetch/ls-remote under the driver’s env (with GIT_SSH_COMMAND=/bin/false and SSH_AUTH_SOCK unset so SSH cannot sneak back). Alternatively, grant the T3 server process standing approval for the key so the agent does not prompt per request.

   Triage: confirmed bug on apps/server. Not a duplicate. Accepting for a server fix. #10943 must not close this.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 15, 2026