Skip to content

[Bug]: Worktree threads always write a full checkout, which fills the disk on large monorepos #26851

Closed as not planned

Description

@mikeohuo

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

  1. Add a large monorepo as a project. The example here is a Unity game repository with a working tree of about 30 GB and 277k files.
  2. Start three threads in a new worktree, or run three delegate_task calls with worktree isolation.
  3. Watch the free space on the drive that holds the worktrees directory. The default is ~/.t3/worktrees, on the system drive.

Expected behavior

A large monorepo often keeps its working tree small with git sparse checkout. T3 worktrees can use the same sparse-checkout patterns, so a new worktree writes only the files that an agent needs.

Actual behavior

Every T3 worktree runs a full git worktree add in GitVcsDriverCore.createWorktree, which writes every tracked file. In the example repository, each worktree wrote about 30 GB. Three worktree threads used about 90 GB, and the 1 TB system drive ran out of space.

A runOnWorktreeCreate project script cannot prevent this, because it runs after git has written every file. With the repository's non-cone sparse-checkout pattern file, the same worktree checks out as 1.79 GB and 63k files in about 36 s.

The problem does not depend on Unity. Any repository with a large working tree gets one full copy per worktree thread: a game repository with binary assets, a monorepo with many packages, or a repository with vendored dependencies.

Impact

Major degradation or frequent failure

Version or commit

main @ fe219c4

Environment

Windows 11 Pro x64, Git 2.45.2.windows.1, T3 Code desktop

Workaround

Move the worktrees directory to a larger drive, or create the worktree outside T3 with git worktree add --no-checkout, git sparse-checkout set --no-cone --stdin, and git checkout. The second route does not cover delegate_task worktree isolation or PR threads, which always go through createWorktree.

Proposal and fix

Done with Claude Opus 5.5 in Claude Code, run from T3 Code, with Claude Fable 5.1 and GPT-6 Astra looped in.

Activity

  1. Diogenesoftoronto commented on Nov 9, 2026

    @Diogenesoftoronto

    A related implementation gap is Linux copy-on-write filesystem support for full worktrees.

    Current upstream already has a private, Git-written checkout cache in apps/server/src/vcs/worktreeCheckoutCache.ts. Its CheckoutCloner.layer is macOS-only and uses APFS clonefile; on Linux it returns no cloner. That gives a smaller path to supporting complete worktrees on reflink-capable Linux filesystems without requiring sparse checkout.

    Proposed extension:

    • Reuse the existing environment-wide, opt-in Fast worktree checkout path for Linux.
    • Probe the cache volume using a forced reflink operation before enabling the cache. Unsupported filesystems must fall back to ordinary Git without accumulating private full checkout caches.
    • Preserve independent files/copy-on-write behavior, symlinks, executable modes, Git index/stat correctness, hooks, and existing rollback/fallback semantics.
    • Keep Git responsible for writing the private cache, so dirty or ignored files from another working tree cannot leak into a new checkout.

    I am trying this in https://github.com/Diogenesoftoronto/t3code, building on the current checkout-cache implementation rather than changing the installed app. I will report focused checkout-parity and actual filesystem results once validated.

  2. juliusmarminge commented on Nov 12, 2026

    @juliusmarminge
    Member

    Thanks for writing this up. It asks for new behaviour rather than reporting a defect, so it does not belong in the bug tracker and I'm closing it as not planned here. Feature ideas are discussed in Discussions: please post it there.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions