fix(server): a folder that only holds a repository's worktrees is refused as a project - #36366

Nothing needed changing this round; the head is unchanged at 68c24c4. The pull request #36366 was watched until its checks and bot reviews finished: all 35 checks passed on 68c24c4 (8 required), mergeable state is clean, Macroscope's approvability review approved with no line findings, and the thread-transfer report is within every ceiling. CodeRabbit left one finding, rated Trivial (nitpick), on apps/server/src/project/worktreeContainer.test.ts:16 and the matching helper in ProjectService.test.ts: the Git fixture helpers do not assert a zero exit code, so a failed setup command would not fail the test by itself. It is below the 'high or above' bar and was left as the brief directs; the observation itself is accurate. The watch has been removed. The change itself is as described in the previous round: ProjectService.create, bootstrap and a workspace-root change refuse a folder whose .git file points at metadata inside it, with a linked worktree inside it, when the repository is bare or has commits but no index; ws.ts forwards the guidance message; auto-bootstrap skips a refused folder with a warning instead of aborting startup.

Supersedes #23407. The change is @juliusmarminge's; their commits are kept.

Reproduction on main

Not executed during screening. In a terminal, create myproj, clone an existing repository with a commit into myproj/.bare using git clone --bare, and write 'gitdir: ./.bare' into myproj/.git. From myproj, run git worktree add develop -b develop HEAD and git config core.bare false. In T3 Code, add myproj as a project and open Changes: main accepts it and includes metadata/sibling checkout entries; this PR rejects it with individual-worktree guidance. Adding myproj/develop should succeed on both. For the reported compatibility regression, initialize a fresh primary directory using git init --separate-git-dir .metadata ., create an external orphan worktree using git worktree add --orphan -b feature ../feature, then add primary in T3 Code: main accepts it, while this PR's missing-index heuristic rejects it.

Evidence

Create a committed sample repository, clone it bare into myproj/.bare, write gitdir: ./.bare into myproj/.git, add develop with git worktree add develop -b develop HEAD, and set core.bare=false. Also initialize primary with git init --separate-git-dir .metadata . and create an external orphan feature worktree. In the web UI, add develop, primary, then myproj through Add project > Local folder.

Proven: scenario fails on base and passes on head. Environment: Chromium, 1280×800, light theme, fresh isolated databases and synthetic repositories.

Evidence	Before: 9efd960925	After: 68c24c48c1
Container admission	Accepted; Changes shows +894 −1.	Rejected with individual-worktree guidance.
Individual worktree
Fresh separate-metadata primary
Scripted interaction	Before recording	After recording

Scenario source

Not shown:

• The core.bare=true variant and startup auto-bootstrap behavior were not exercised.
• The Changes summary was captured; the detailed metadata and sibling-worktree file listing was not opened.

Tests

No commands were run locally this round because no code changed. CI on 68c24c4: all 35 checks passed, including Lint, Changes and Test Server 1-8. Previous round on the same head: vp run check:changed passed (format, lint, knip, graphql, typecheck of 3 packages, 7 test files).

Not in this change

• Containers with core.bare=true are still accepted: Git reports no work tree there, so T3 adds the root as a plain non-Git folder exactly as on main. On Git 2.43 the issue's steps as written produce this state; the reported misbehaviour needs core.bare=false.
• Containers whose HEAD is unborn (bare clone of an empty repository with orphan worktrees) are still accepted, because nothing distinguishes them from a fresh checkout.
• The layout where the bare repository is the root's .git directory itself (git clone --bare url .git, core.bare=false, worktrees as siblings) is not detected; the check only looks at a .git file pointing inside the root, which is the layout in the issue.
• Projects already created on a container root are left as they are; the check runs only on create and on a workspace-root change.
• No WebSocket-level test was added for forwarding ProjectInvalidError's message; no existing test covers that mapping.
• A container that has an index is accepted: it cannot be told apart from a valid checkout whose tracked files are all deleted, and refusing a valid checkout is the worse error.
• GitVcsDriver.initRepository and the vcsInit WebSocket handler are unchanged: a container registered before this fix, or one with an index, can still be initialized in place.
• The layout where the bare repository is the root's .git directory itself (git clone --bare url .git with sibling worktrees) is not detected; only a .git file pointing inside the root is examined.
• Projects already registered on a container root are left as they are; the check runs on create, bootstrap and workspace-root change only.
• Auto-bootstrap skips a refused folder with a server log warning only; nothing is shown in the client.
• No WebSocket-level test covers forwarding ProjectInvalidError's message through ProjectMutationError.
• CodeRabbit's Trivial finding: the Git fixture helpers in worktreeContainer.test.ts and ProjectService.test.ts do not assert a zero exit code for setup commands.
• A container that has an index is accepted: it cannot be told apart from a valid checkout whose tracked files are all deleted.
• The layout where the bare repository is the root's .git directory itself (git clone --bare url .git with sibling worktrees) is not detected.
• Projects already registered on a container root are left as they are.

Who did the work

• Written by Claude Fable 5.2, in Claude Code
• Reviewed by GPT-6.1 Sol, in Codex, and by Claude Opus 5.5, each on its own
• Proof captured by GPT-6.1 Sol and checked by Claude Opus 5.5

Run by the t3code factory in T3 Code.