Description
The built-in command workbench.action.chat.attachFile currently supports attaching files to a chat session context. However, its implementation explicitly filters out URIs whose scheme is not one of: file, vscodeRemote, untitled, and vscodeUserData.
This restriction prevents extensions from attaching resources hosted on other registered file systems (e.g., in-memory virtual FSs, workspace-local virtual providers, or ephemeral analysis views). As a result, extension authors are forced to serialize data to disk or forego providing valuable context to chat agents.
Relevant code: chatContextActions L140
Proposal
Permit attaching file URIs from any registered file system provider. This includes virtual file systems provided by extensions (e.g., memfs:).
This change would make the attachFile command more aligned with other resource-consuming APIs in the VS Code API, which already support arbitrary schemes (e.g., TextDocument, openTextDocument, Uri.fsPath, etc.).
Use Cases
- An extension computes intermediate insights (e.g., logs, traces, telemetry summaries) and exposes them via a virtual FS (memfs:/diagnostics/summary.json). Attaching that file gives the agent immediate access to context-rich material without creating temporary files.
- A tool generates user-specific data on-the-fly during an interaction session. This data is not persisted and should remain in-memory, but still be eligible for chat context enrichment.
Design Considerations
- If the restriction is security-motivated (e.g., to prevent agents from reading raw data from unsupported schemes), consider exposing an allowlist mechanism extensions can contribute to (similar to webview URI access control).
- Alternatively, accept any scheme with a valid FS provider and let agents handle unsupported content gracefully.
- Extensions are responsible for recovering the content of the attached files if VS Code is restarted.