You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Threads from the pre-v2 multi-repo branch lose their per-repo worktrees after upgrading to v2 #340
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.
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.
Activity
fix(server): threads from the pre-v2 multi-repo fork reach every repo…
LoganRupe commentedon Oct 12, 2026
Fixed by #341, now on
multi-repo-workspaces.On startup the server looks for threads whose
worktrees_jsonlists more than one worktree in one per-thread folder, and whose v2 worktree path still matches the importedworktree_path. For each one it writes<container>.t3-isolated-run.jsonbeside 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-workspaceis a regular file, so deletion leaves it and its folder behind.fix(server): threads from the pre-v2 multi-repo fork reach every repo…