Sign up
View stargazersSign up

[Bug]: Automatic worktree submodule checkout can wait indefinitely and blocks /side#33017

opened1d agobyQQuentinWach

Observed

T3 Code Beta 0.1.7, bundled commit 322f6544dfad, macOS. Creating a worktree for a repository with four top-level submodules appears to hang; cancelling leaves the Git checkout usable. /side reports that the worktree must be set up first.

Read-only inspection of local server traces on 2026-11-08 isolated the delay:

  • GitVcsDriver.createWorktree: success in 478 ms.
  • GitVcsDriver.createWorktree.initSubmodules: success in 350 ms.
  • GitVcsDriver.createWorktree.updateSubmodules: interrupted after 124,163 ms by worktree setup cancellation.
  • A subsequent attempt also completed worktree creation in 467 ms and was interrupted during submodule update.
  • Ordinary switchRef.checkout completed in 61 ms.

No project worktree setup scripts are configured. Some submodule URLs use SSH and some HTTPS. The trace establishes the blocking operation, but does not establish which remote or whether this particular wait was transfer time or authentication.

Code path

GitVcsDriverCore.createWorktree runs git submodule update --init --recursive with timeoutMs: null. Unlike background upstream fetches, the command does not receive the non-interactive authentication environment (GCM_INTERACTIVE, GIT_ASKPASS, GIT_TERMINAL_PROMPT, SSH_ASKPASS, SSH_ASKPASS_REQUIRE). Hidden credential prompts therefore have no deadline. The non-interactive environment must be supplied with and without progress callbacks.

dispatchThreadFork rejects side chats while orchestrationV2WorktreePending is true. That guard protects against starting in the wrong checkout; removing it would not fix the underlying setup delay.

Expected and proposed focused fix

Automatic submodule initialization should use the same non-interactive authentication policy as background fetches and report an authentication failure through the existing submodule progress result, allowing preparation to settle. Cached credentials/SSH agents remain available. Preserve support for long legitimate clones rather than restoring the old 30-second timeout.

This is a narrow mitigation for credential waits, not a claim to solve all stalled networking or large downloads. #23269 separately addresses repeated downloading of submodule objects; #26390 and #26409 document why a short fixed timeout is inappropriate.

Prepared regression coverage uses the existing real Git/SSH fixture to verify inherited interactive authentication settings are suppressed during submodule initialization, both with and without line-progress callbacks.