Repository navigation
Isolated runs don't open as a multi-root workspace #125
Description
Follow-up from #112.
For a .code-workspace project, "Open in" now correctly opens the workspace file — but only when the thread has no worktree. In an isolated run it opens the anchor worktree as a plain folder, so the other repos aren't in the tree.
ChatView passes openInWorkspaceFile = null whenever activeThread.worktreePath is set. That's deliberate: an isolated run fans out one worktree per repo root under <worktreesDir>/<projectId>/<threadId>/<repoName>, and none of them contains a .code-workspace. Pointing at the project's own file would open the original checkouts instead of the copies the thread is actually working in — worse than the current behaviour.
The fix is to generate a workspace file in the thread's worktree directory listing the per-root worktree paths (alongside the fan-out in WorktreeFanout.ts), and point openInWorkspaceFile at that when a worktree exists. Needs a decision on lifecycle — regenerate when roots change, remove with the worktrees on thread delete.
Activity
fix: open isolated multi-repo runs as a multi-root workspace
fix: open isolated multi-repo runs as a multi-root workspace (#294)
LoganRupe commentedon Sep 23, 2026
Fixed in #294, now on
multi-repo-workspaces(a12e441). An isolated run gets its own.code-workspacenext to its worktrees, and "Open in" opens that, so every repo is in the tree. Threads created before this still open the anchor folder.fix: open isolated multi-repo runs as a multi-root workspace (#294)
fix: open isolated multi-repo runs as a multi-root workspace (#294)
fix: open isolated multi-repo runs as a multi-root workspace (#294)
stefanvandervelden-zipline commentedon Oct 11, 2026
Reopening: not in the orchestrator v2 re-implementation (#338, now
multi-repo-workspaces@2ba7964848). The fix (#294,348a08cef1onmulti-repo-workspaces-pre-v2) wasn't ported.v2 gives an isolated run a container folder that mirrors the project, with one worktree per repo (
WorkspaceWorktrees). "Open in" on the thread opens that container as a plain folder.The project's top-level files, including its
.code-workspace, are symlinked into the container. So VS Code might open the multi-root workspace if pointed at that link, but I haven't verified this. VS Code may resolve the relative folder paths against the link's real location, which is the original checkouts, not the worktrees. If so, it needs a generated copy as in #294.Either way, "Open in" would need to pick the container's
.code-workspacefor VS Code-family editors, which is the #112 work applied to the container.