Sorry. The triage bot closed it incorrectly. Will reopen as soon as the fix is in.

vscode-copilot-chat-code-block is created by the copilot extension. It is cleaned up automatically by the extension host

@jrieken It would be great if we could avoid this. Here's how these documents are used:

• vscode-chat-code-block — Created by core. Copilot registers itself as the exclusive provider for this scheme
• vscode-copilot-chat-code-block — Created by copilot. These documents are duplicates of the vscode-chat-code-block ones. Copilot requests IntelliSense on these code blocks and language extensions get these requests.

I'd love to just have the vscode-chat-code-block doc. Maybe we could add re-entry logic so that when an exclusive provider calls a command such as executeHoverProvider inside its provide function, the command does not go back to call the exclusive provider

I would not do any re-entry logic. Granted the extension (chat) does not call open and is just a provider, the duplicated models should only be around for a short time, e.g the execution of a particular language feature like hover,

To support IntelliSense across code blocks, we need to make sure extensions have TextDocuments for all of them. Unfortunately that means we can't just have one duplicate model, all of them have to be duplicated

Having to keep duplicates open for every single document is not a good solution but I can't think of any other way to get this working with our current apis

Instead of opening all code blocks from a session as text documents (and fighting to keep them open) could we just register a file system for chat code blocks? With that language extensions can simply read all documents/files at their pace and in their ways? I don't know how this plays with TypeScript specifically but I would assume that's generally the better approach and is also more similar to scenarios like web. So, it would be

• chat implement readonly fs for code blocks, e.g vscode-chat-fs://<session>/<codeblock_N>
• chat registers (exclusively) for language features using the actual scheme and redirects to the vscode-chat-fs-uris
• the renderer loads the initial model
• extensions use workspace.fs to load sibling documents