[Bug]: New worktree thread on upstream/* base sits with no progress for ~1min on remote (bootstrap hardcodes origin fetch, streams no progress)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 23k
- Forks
- 5.9k
- Avg merge
- 11h 14m
- Merged PRs (30d)
- 357
Description
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
- Connect to a remote server (remote environment) whose project repo has both
originandupstreamremotes. - Set the project new-thread mode to New worktree with Start from origin enabled.
- Start a new conversation, set the base branch to
upstream/main, type a prompt and submit.
Expected behavior
The client shows what is happening while the worktree is prepared (fetching the base ref, creating the worktree), and the server fetches the base branch's actual remote (upstream) before basing the worktree on it.
Actual behavior
After submit, the new conversation is created but there is no meaningful UI feedback about what is going on for roughly a minute; only then does the status flip to Working.
Root cause (all on main):
apps/server/src/ws.ts:1097-1121hardcodesremoteName: "origin". With baseupstream/mainit runsgit fetch origin(slow and irrelevant on a remote server), then checksremoteBranchExists({ refName: "upstream/main", remoteName: "origin" })which testsrefs/remotes/origin/upstream/main— a ref that can never exist (apps/server/src/vcs/GitVcsDriverCore.ts:1295-1303concatenates blindly). So it always falls back to the unfetched localupstream/mainstring. Theupstreamremote is never fetched, so the worktree may also be based on a stale commit.- The entire bootstrap (
fetch+worktree add(up to 300s timeout, plus recursive submodule update:GitVcsDriverCore.ts:2826-2863) + setup script + turn start) runs inside a single blockingthread.turn.start+bootstrap WS RPC (ws.ts:1093-1143). Nothread.activity.appendprogress is emitted during fetch/worktree creation (unlike the setup-script steps, which do emitsetup-script.requested/started), so the client can only show its local optimistic status with no step detail and no way to cancel.
Related: #8191 (same code area, local-only bases — closed), #8922 (generic client-side setup status).
Impact
Major degradation or frequent failure
Version or commit
main @ a81a52a (also observed on recent nightly)
Environment
Remote server environment; repo with origin + upstream remotes; defaultThreadEnvMode: worktree, newWorktreesStartFromOrigin: true.
Logs or stack traces
No error — the operation eventually succeeds; it is just silent for ~1min. Server trace shows the time going to GitVcsDriver.fetchRemote (origin) and GitVcsDriver.createWorktree inside dispatchBootstrapTurnStart.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in apps/server/src/ws.ts:1093-1143 and trace the bootstrap calls into apps/server/src/vcs/GitVcsDriverCore.ts:1295-1303 and 2826-2863. Verify remote selection for upstream/main and identify where fetch/worktree progress is absent; done means the correct remote is fetched and the client receives meaningful bootstrap status before the turn reaches Working.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, typescript
- Domain
- backend, devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100