Repository navigation
"Open in VS Code" opens the workspace file's parent folder instead of the .code-workspace #112
Description
For a multi-repo project defined by a .code-workspace file, the Open-in picker launches the editor on the containing directory, so VS Code opens it as a plain folder rather than as a multi-root workspace. The repo roots don't appear in the editor's tree.
Cause looks like ChatView.tsx:5904 passing openInCwd={gitCwd}, where gitCwd resolves from activeProject.workspaceRoot (ChatView.tsx:2446-2451) — which for a workspace-file project is the anchor directory by design (WorkspaceManifest.ts module docs).
The project already carries workspaceFile (contracts/orchestration.ts:216, migration 038_ProjectionProjectsWorkspaceFile), so passing that when present should fix it. Passing a file path is already supported — FilePreviewPanel.tsx:910 passes openInCwd={absolutePath} for a single file.
One caveat: this probably wants to be editor-aware rather than an unconditional swap. vscode / vscode-insiders / cursor understand .code-workspace files, but zed (contracts/editor.ts) would just open it as JSON text, which would be worse than the current behaviour.
Version: multi-repo-workspaces @ 92de5d9a, macOS arm64, dev build (pnpm dev).
Thanks for maintaining this fork — the multi-repo support is exactly what I needed.
Activity
LoganRupe commentedon Aug 10, 2026
Fixed in b79f415 on
multi-repo-workspaces, and confirmed working on a real multi-repo project.The
.code-workspacepath is now passed alongside the anchor directory and chosen between per editor, resolved server-side inexternalLaunchersince the right target depends on which editor you pick. Your caveat was correct, so the editor registry gained an explicitsupportsWorkspaceFileflag: the VS Code family gets the workspace file, while Zed, JetBrains and the file manager keep getting the directory.One known limit: isolated runs still open the worktree rather than a multi-root workspace. The fanned-out worktrees have no
.code-workspaceof their own, and the project's would open the original checkouts instead — tracked in #125.Note the branch is rebased onto upstream
mainperiodically and force-pushed, so reset rather than pull. The pre-rebase tip is atmulti-repo-workspaces-prerebase.Closing — thanks for the precise report, the file:line pointers made this straightforward.
stefanvandervelden-zipline commentedon Oct 11, 2026
Reopening: this isn't in the orchestrator v2 re-implementation (#338), which is now
multi-repo-workspaces@2ba7964848. The fix (ced2fc04e1onmulti-repo-workspaces-pre-v2) wasn't ported.On v2, projects no longer store a
workspaceFile. Repos are found at runtime from the folder's.code-workspace(WorkspaceRepositories). But "Open in" still passes only the folder:ThreadDetailsPanelpassesopenInCwd={props.gitCwd}, andexternalLauncherlaunches the editor oninput.cwdwith no.code-workspacehandling. So VS Code opens the containing folder as a plain folder again.To re-implement on v2: when the project folder has a
.code-workspaceand the editor is in the VS Code family (vscode,vscode-insiders,cursor, …), open the file instead of the folder. Other editors (Zed, JetBrains, file manager) keep getting the folder. That's the same split as the original fix.