microsoft / microsoft/vscode

Agents window: sessions from different folders with the same basename collapse into one workspace section

Open
#334,397 0 comments 0 reactions 1 assignee Claimed by @TylerLeonhardt View on GitHub
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

### Summary

In the Agents window, the sessions list groups sessions into workspace sections keyed by the workspace's **display label** rather than its URI. Any two distinct folders that share a basename therefore collapse into a single section, and their sessions are silently interleaved as if they belonged to one workspace.

This is very easy to hit with layouts that put the code in a conventionally-named subfolder — ROS 2 workspaces (`/src`), Rust/Java/CMake projects (`src`), monorepo packages (`app`, `packages/*/src`), and git worktrees.

### Environment

- VS Code 1.136.1 (`a44adf7f53e00964ab890f9f8758a334f1fc15bc`, x64), Linux
- Agents window / Agent Sessions view, grouped by workspace

### Steps to reproduce

1. Have sessions in two or more folders that share a basename but live under different parents. In my case, three ROS 2 workspaces:
- `/home/eric/workspaces/eric/ros2_ws/src`
- `/home/eric/workspaces/eric/rl_ws/src`
- `/home/eric/workspaces/eric/ros2_perception_ws/src`
2. Open the Agents window with the sessions list grouped by workspace.

### Expected

Three separate workspace sections, one per folder, each disambiguated so it is clear which parent it belongs to (e.g. label `src` with the parent path shown as the description — `ISessionWorkspace.description` already exists for exactly this: *"parent folder path"*).

### Actual

One section titled `src` containing the sessions from all three folders, with no way to tell which session came from which workspace. Picking a session to resume becomes guesswork.

### Likely cause

In `src/vs/sessions/contrib/sessions/browser/views/sessionsList.ts`, `groupByWorkspace()` builds its `Map` keyed on the label string alone:

```ts
/** The workspace group label a session belongs to (matches {@link groupByWorkspace}). */
function sessionWorkspaceLabel(session: ISession): string {
return session.workspace.get()?.label || localize('unknown', "Unknown");
}

export function groupByWorkspace(sessions: ISession[]): ISessionSection[] {
const groups = new Map();
for (const session of sessions) {
const label = sessionWorkspaceLabel(session);
...
}
const result: ISessionSection[] = order.map(label => ({
id: `workspace:${label}`,
label,
sessions: groups.get(label)!,
}));
```

`ISessionWorkspace` (`src/vs/sessions/services/sessions/common/session.ts`) carries a `uri` alongside `label`, so the identity information needed to keep these apart is already available — it just isn't used for grouping.

The same label-as-identity assumption appears to leak into neighbouring behaviour in the same file, so the effects are likely broader than the visual grouping:

- Section ids are `workspace:${label}` (l. 4425, 4433), and expanded-section state is tracked with the same string (l. 3694) — so collapse/expand state is shared across unrelated workspaces, and reorder identity is documented as `workspace:` (l. 1920).
- Drag-and-drop "same workspace" checks compare labels (l. 3526-3527, 3554-3555), so a session can be dropped into what looks like its own section but is actually a different folder's.

### Suggested fix

Key the grouping on the workspace URI (falling back to the label only when no URI is present), keep `label` purely for display, and populate/render `description` (parent path) on the section header so same-named sections remain distinguishable to the user. Section ids and the DnD scope checks would follow the same key.

### Related

- #312770 — group worktree sessions by repository root (adjacent grouping-identity concern; worktrees are another common source of duplicate basenames)
- #333998 — dragging a grouped session back into its workspace section
- #264555 — agent sessions support for multi-root workspaces

— Claude (posted on Eric's behalf via Claude Code)

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.