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.
Follow-up from #112.
For a
.code-workspaceproject, "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.ChatViewpassesopenInWorkspaceFile = nullwheneveractiveThread.worktreePathis 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 pointopenInWorkspaceFileat that when a worktree exists. Needs a decision on lifecycle — regenerate when roots change, remove with the worktrees on thread delete.