microsoft / microsoft/vscode

Smart window reuse: seamlessly accept files/folders in multi-root workspace windows from external tools

Open
#336,105 0 comments 0 reactions 1 assignee Claimed by @Yoyokrazy View on GitHub
triage-needed
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

## Describe the feature you'd like

When a VS Code window contains a multi-root workspace, it should seamlessly accept and open files or folders from external tools (CLI, IDE integrations, error handlers, etc.) that are part of that workspace. Currently, external tools cannot reliably target these multi-root windows, breaking integration workflows.

**Current behavior:**
- Single folder window + open file from that folder → reuses window ✓
- Single folder window + open different folder → new window ✓
- **Multi-root workspace window + open ANY file/folder from CLI → new window ✗ (BREAKS INTEGRATION)**
- **Multi-root workspace window + error link from IDE/tool → new window ✗ (BREAKS WORKFLOW)**

## Why this matters

**The multi-root workspace problem:**

When you open multiple folders in a single window, they become a multi-root workspace. This is powerful — you get a unified editor, shared terminals, consistent settings, and ephemeral state (open tabs, debug sessions, terminal scrollback). However, VS Code then **rejects all external requests** to open files/folders that belong to that workspace, creating new windows instead.

This breaks critical integration scenarios:

1. **Error handling & IDE integration** — Build tools, linters, debuggers emit file paths to open at specific lines (e.g., `code /path/to/file.ts:42:10`). When the file is in a multi-root workspace, it opens in a new window instead of the active workspace. Users lose context (terminals, debug state, layout).

2. **CLI/Git integration** — `git commit` with `core.editor = code --wait` can't target the right window when you're using multi-root. Different worktrees open in different windows, breaking developer workflow.

3. **Tool automation** — Test runners, deployment scripts, and documentation generators that emit deeplinks (`vscode://file/...`) or CLI calls can't reliably send files to the active workspace.

4. **Ephemeral state loss** — Every external tool invocation that opens a file creates a new window, losing:
- Open tabs and file history
- Terminal sessions and scrollback
- Debug breakpoints and watch expressions
- Workspace layout and panel sizes
- Search context and find history

5. **Window fragmentation** — A single workspace spawns multiple VS Code windows, fragmenting the development environment.

## Proposed solution

Implement intelligent window reuse for multi-root workspaces:

1. When `code ` or `code ` is invoked from external tools
2. Check if any open multi-root workspace window contains that file/folder in one of its workspace roots
3. **If yes → activate that window and open the file/folder there** (preserving context)
4. If no → open in a new window (current behavior)

This should also apply to:
- `vscode://file/...` URL handler when the file is in an open multi-root workspace
- Files opened via IDE integrations or error dialogs
- Folders added to existing multi-root workspaces

## Examples

**Before (broken workflow):**
```bash
# Terminal in multi-root workspace window showing: /project/service-a /project/service-b /project/tools
$ npm run test # Test fails, emits: code /project/service-b/src/bug.ts:42:10
# Opens in NEW window ✗ (loses terminals, debug state, ephemeral layout)
```

**After (seamless workflow):**
```bash
# Same multi-root workspace window
$ npm run test # Test fails, emits: code /project/service-b/src/bug.ts:42:10
# Opens in EXISTING workspace window at line 42 ✓ (preserves all context)
```

## Related issues

- #323880 — `vscode://` URL handler with window reuse options
- #299540 — File reuse misbehaves with git worktrees (opens in wrong window)
- #215749 — Original request to reuse windows with multi-root workspaces (closed, not planned)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.