Skip to content

[Bug]: Bare-root worktree layouts are silently accepted as a normal repo, making the project root the parent of every worktree #8164

Description

@tettoffensive

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

A common layout for worktree-heavy work puts a bare repo at <root>/.bare, a <root>/.git file pointing at it, and every branch as a sibling checkout — no primary working copy:

mkdir myproj && cd myproj
git clone --bare git@github.com:owner/repo.git .bare
echo "gitdir: ./.bare" > .git
git worktree add develop develop
git worktree add feature-x -b feature-x

Result:

myproj/
├── .bare/
├── .git          → gitdir: ./.bare
├── develop/
└── feature-x/
  1. Add myproj/ as a project in T3 Code.
  2. Open the Changes/Diff view, or start a thread.

Expected behavior

The root is rejected at add time with a message explaining that it is a bare-root layout and that an individual worktree should be added instead. Adding myproj/develop directly already works correctly today, so the fix is to stop accepting a root that cannot be a coherent workspace — not to add support for the layout itself.

Actual behavior

The root is accepted as an ordinary repository with no warning. detectRepository in apps/server/src/vcs/GitVcsDriver.ts gates on git rev-parse --is-inside-work-tree, and because the clone leaves core.bare=false, git reports:

$ git -C myproj rev-parse --is-inside-work-tree --show-toplevel --git-common-dir
true
/path/to/myproj
/path/to/myproj/.bare

So rootPath becomes myproj — the parent directory of every worktree. Downstream that means git status treats develop/ and feature-x/ as untracked entries, the diff/changes view is scoped to a directory that contains N independent checkouts, and any thread started there runs an agent whose cwd spans all of them. .bare/ itself is correctly rejected (--is-inside-work-tree is false), so the failure is specific to the root.

There is no bare-specific handling anywhere in the git layer — GitManager.ts mentions "bare" once, about branch names.

Impact

Minor bug or occasional failure

Version or commit

0.0.33 (macOS desktop)

Environment

macOS 26.5.2, git 2.50.1

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Add each worktree directory as its own project and never add the root.

detectRepository already calls git rev-parse --git-common-dir alongside --show-toplevel, so the detection needs no new git calls: a common dir that sits inside rootPath but is not rootPath/.git identifies this layout.

Activity

  1. added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Aug 25, 2026
  2. added a commit that references this issue on Aug 29, 2026
    48fc1cd
  3. juliusmarminge commented on Sep 5, 2026

    @juliusmarminge
    Member

    I reran the exact bare-clone layout with real Git against main 89ee69e44 on Linux, September 5, 2026 UTC. One distinction matters: git clone --bare initially leaves core.bare=true, so detectRepository(root) rejects it. Calling T3's initRepository(root) then changes it to false; the parent is accepted and the sibling worktrees appear as untracked entries. Adding an individual worktree works. The macOS client add/start flow still needs integrated verification.

    The existing candidate #8646 is not ready. I tested its full patch rebased onto main 82f64cd8 and found two real-Git counterexamples to the missing-index heuristic: it rejects a valid unborn separate-git-dir checkout after an orphan linked worktree is created, and it accepts a genuinely bare root after git read-tree --empty creates an index. The native core.bare values remain unchanged in both controls. The reproduction details are on the PR. These classification failures need fixing before a maintainer decides the rejection behavior.

    GPT 6 Astra via Codex in T3 Code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions