Skip to content

Threads from the pre-v2 multi-repo branch lose their per-repo worktrees after upgrading to v2 #340

Closed

Description

v2 multi-repo (#338) doesn't read projection_threads.worktrees_json, and v2 copies worktree_path over unchanged (LegacyV1ThreadImporter.importedThread). On the pre-v2 branch, an isolated multi-repo thread's worktree_path pointed at the first repo's worktree, e.g. …/worktrees/<project>/<thread>/zipline. So after the upgrade these threads behave as single-repo threads in that one worktree. The agent, diffs, checkpoints and Git panels don't see the other repos. The transcripts are preserved.

The on-disk layout (<thread>/<repo> folders plus a .code-workspace) already matches v2's container layout. So the fork-only ledger repair could rewrite worktree_path to the parent folder for threads whose worktrees_json lists more than one worktree under a common folder. Without a <container>.t3-isolated-run.json file next to it, v2's cleanup on thread delete probably won't remove those worktrees. Writing that file is worth considering too.

Checked against a real dev DB: 15 of 25 threads are affected.

Activity

  1. added a commit that references this issue on Oct 12, 2026
    635fe0f
  2. LoganRupe commented on Oct 12, 2026

    @LoganRupe
    Owner

    Fixed by #341, now on multi-repo-workspaces.

    On startup the server looks for threads whose worktrees_json lists more than one worktree in one per-thread folder, and whose v2 worktree path still matches the imported worktree_path. For each one it writes <container>.t3-isolated-run.json beside the folder and moves the thread's worktree path up to the folder. This covers databases that already upgraded, not only fresh ones. Threads you moved yourself since the upgrade are left alone.

    Checked with real dev servers on a scratch fork-shaped database. Before the fix the Git panel showed only the first repository. After it showed one section per repository. Deleting the thread now removes every worktree too. The fork's generated .code-workspace is a regular file, so deletion leaves it and its folder behind.

  3. added a commit that references this issue on Oct 14, 2026
    1126aa5
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

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions