fix(worktree): fetch trunk before creating worktree to avoid stale base

[richardsolomou]

Problem

Local worktree tasks in the desktop app can start off a stale local trunk. When the user's local main hasn't been refreshed, WorktreeManager.createWorktree bases the new detached worktree on the local ref — so the agent begins iterating on code that's already behind origin/main, surfacing user-visible "worktree starts behind master" reports.

This only affects mode === "worktree" tasks. mode === "local" reuses the user's existing folder (no worktree), and mode === "cloud" returns from doCreateWorkspace before any worktree is created (the cloud runner provisions its workspace separately).

Changes

Add an opt-in fetchBeforeCreate option on the trunk path:

• WorktreeManager.createWorktree({ fetchBeforeCreate: true }) calls a new resolveFreshBaseRef helper that does a best-effort git fetch origin <baseBranch> and bases the worktree on origin/<base> when reachable. Falls back to the local base ref if the fetch fails (offline, no origin, ref doesn't exist on the remote) so existing local-only setups still work.
• CreateWorktreeSaga gets the same option for parity, using this.git directly inside the existing write lock (the fetch query helper would re-enter the lock and deadlock).
• apps/code/src/main/services/workspace/service.ts passes fetchBeforeCreate: true on the trunk path only. The occupied-branch fallback (which bases off a user-local branch they may have committed to) is intentionally left as-is — fetching there would silently bypass their local commits.

We base off origin/<base> rather than fast-forwarding the local branch so the user's local checkout is never mutated; only the worktree picks up the remote tip.

Two small helpers (hasRef, fetchRef) added to packages/git/src/queries.ts to keep the saga and WorktreeManager symmetric.

How did you test this?

• pnpm --filter @posthog/git test src/worktree.test.ts — 3 new tests pass:
  • Without fetchBeforeCreate, worktree is based on the stale local ref (baseline that proves the bug).
  • With fetchBeforeCreate, worktree starts at the remote tip and local main is not mutated.
  • With fetchBeforeCreate and an unreachable remote, falls back to the local base.
• pnpm --filter @posthog/git typecheck, pnpm --filter code typecheck, pnpm lint — all clean.
• The 2 pre-existing failures in the git test suite (forceRemove EACCES, detectDefaultBranch > prefers remote HEAD) reproduce on main and are unrelated.

Publish to changelog?

no

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/git/src/worktree.test.ts:68-117
**Non-parameterized tests for fetch flag variants**

The first two tests share identical setup (clone a separate repo, push a new commit, verify the local is stale, instantiate `WorktreeManager`) and differ only in the `fetchBeforeCreate` flag and the expected HEAD SHA. Per the team's "prefer parameterised tests" convention, they should be collapsed into a single `it.each` entry rather than two copy-pasted bodies. The third test (unreachable remote) has a different setup so it reasonably stays separate.

_{Reviews (1): Last reviewed commit: "fix(worktree): fetch trunk before creati..." | Re-trigger Greptile}

[k11kirky]

Sorry to be annoying - but the comments in here are really verbose, feels like AI dumping thoughts. Can we clean that up - otherwise its looks good to go