Agents window: Remote workspace folders cannot be attached as chat context

[tkalpdev]

• Copilot Chat Extension Version: 0.60.0
• VS Code Version: 1.132.0
• OS Version: macOS arm64 client; WSL2 Linux workspace on a remote Windows host
• Feature: Agents window / Add Context
• Selected model: Any
• Logs: Sanitized patterns included below

Summary

Folders from a Remote - WSL workspace cannot be attached as chat context in the standalone Agents window.

Dragging a folder from the Agents window's Files explorer into the composer silently does nothing. The alternative Add Context -> Files & Folders flow also cannot find folders that are visibly present in the workspace Explorer.

This differs from #301847 because that report used an older VS Code version and concerned a detached Copilot Chat view. The current issue reproduces in the dedicated Agents window on VS Code 1.132.0 and also affects the folder context picker. It may share a remote-resource boundary with #328295, but that issue specifically tracks remote MCP availability.

Steps to reproduce

1. Connect to a Windows remote host and open a workspace inside WSL using Remote - WSL.
2. Open the standalone Agents window for that workspace.
3. In the Agents window's Files explorer, drag a workspace folder into the new-session chat composer.
4. Observe that no context item is added.
5. Select Add Context -> Files & Folders.
6. Search for the same folder, which remains visible in Explorer.

Expected

The folder is attached as context, either by drag-and-drop or through the Files & Folders picker.

Actual

• Drag-and-drop silently adds nothing.
• The Files & Folders picker returns no matching remote folder.
• The folder remains visible and accessible in Explorer.
• Reloading the VS Code window does not resolve the problem.
• Opening the workspace Chat view and using its Files & Folders picker can show the same failure.

Sanitized diagnostic pattern

The renderer and agent-host logs repeatedly contain errors shaped like:

[RemoteAgentHostProtocol] Resource not found: file:///home/<user>/<workspace>/<folder>
[ProtocolServer] resourceResolve failed: file:///home/<user>/<workspace>/<folder>

The diagnostic URI uses a plain file: scheme for a resource that belongs to the remote WSL workspace.

Environment

• VS Code: 1.132.0
• GitHub Copilot Chat: 0.60.0
• Remote - WSL: 0.104.3
• Client OS: macOS arm64
• Remote topology: client -> Windows remote host -> WSL2 Linux workspace
• Reproduces after Developer: Reload Window

Extensions disabled

Not tested with all extensions disabled because the reproduction requires the built-in Agents/Copilot experience and Remote - WSL.

[tkalpdev]

Additional Windows tunnel reproduction

This is not limited to WSL. The same folder-specific failure reproduces when the Agents window connects directly to a Windows workspace through Remote Tunnels, without a WSL layer.

Behavior

• An individual file from the remote workspace can be dragged into the composer successfully.
• Dragging a folder from the same Files explorer silently adds no context.
• The remote folders remain visible and accessible in the Files explorer.
• Add Context → Files… opens a picker rooted in the client’s local filesystem instead of the active remote Windows workspace.

Trace results

I enabled Trace logging, cleared the Window output, and reproduced the remote folder drop.

• The composer did not change.
• The only emitted trace entry was generic user-activity detection.
• No attachment command, directory operation, filesystem request, resourceResolve, or Remote Agent Host request was emitted.
• Remote individual files can be resolved through a vscode-agent-host://<remote>/... URI.

This suggests the folder is silently rejected or ignored by the Agents window’s drag-and-drop handling before remote resource resolution begins.

Additional environment

• VS Code: 1.132.0
• Client OS: macOS arm64
• Remote OS: Windows 11 24H2
• Topology: client → Windows host through Remote Tunnels
• WSL: not involved in this reproduction

Together with the original WSL reproduction, this indicates a broader remote-workspace folder-context issue rather than a WSL-specific failure.

Expected behavior

Both individual files and folders from the active remote workspace should be attachable as chat context. If a folder cannot be accepted, the UI should display an explanatory error instead of silently ignoring the drop.