Declare workspace trust and virtual workspace capabilities in the manifest

[MariusStorhaug]

VS Code asks each extension to declare what it does in two reduced-functionality modes:

• Workspace Trust — when the user opens a folder marked as untrusted, VS Code disables extensions that have not opted in
• Virtual Workspaces — when no local file system is available (github.dev, remote SSH, dev containers using virtual FS providers)

When an extension does not declare its support, VS Code shows an "Extension is disabled" indicator in untrusted/virtual workspaces with a generic warning, and users have no way to know whether the extension would actually work. Declaring intent makes the experience explicit and unblocks usage in the cases where the extension is safe.

Request

Current experience

package.json does not declare capabilities.untrustedWorkspaces or capabilities.virtualWorkspaces. Users opening a repository in Restricted Mode or in a virtual workspace see VS Code's default warning treatment, even though the extension only:

• Reads file paths and the Git remote URL
• Opens external URLs via vscode.env.openExternal

It executes no code from the workspace, runs no shell commands against workspace files, and does not write to disk. It is therefore safe in both restricted and virtual scenarios.

Desired experience

The manifest declares both capabilities explicitly:

• Untrusted workspaces: Fully supported — the extension performs no operations that depend on workspace trust
• Virtual workspaces: Fully supported — the extension only needs the Git API and external URL opening, both available in virtual hosts

Acceptance criteria

• package.json includes a capabilities.untrustedWorkspaces object set to { "supported": true }
• package.json includes a capabilities.virtualWorkspaces set to true
• A security review confirms the extension does not execute workspace-controlled code, shell out, or evaluate workspace data
• The extension activates and operates correctly when a folder is opened in Restricted Mode
• The extension activates and operates correctly in a virtual workspace (e.g., github.dev once the web-extension issue is resolved)

---

Technical decisions

Untrusted workspaces — supported with no caveats.

Reviewing src/extension.js and src/remoteUrl.js:

Capability used	Trust-sensitive?	Notes
vscode.extensions.getExtension('vscode.git')	No	Built-in extension, not workspace code
repo.state.remotes, repo.state.HEAD	No	Read-only Git API access
vscode.workspace.fs.stat / fs.readdir	No	Read-only file metadata
vscode.env.openExternal	No	Just opens a URL in the user's browser
vscode.workspace.getConfiguration('remoteFolders').get(...)	No	Reads user-scoped settings

No workspace code is executed. No shell commands are run with workspace input. The remote URL is computed from the Git remote (already trusted by virtue of the user having configured it) and the workspace-relative path of the selected file/folder, which is structural information.

Manifest declaration:

{
  "capabilities": {
    "untrustedWorkspaces": {
      "supported": true
    },
    "virtualWorkspaces": true
  }
}

If a future feature adds workspace-trust-sensitive behavior (e.g., reading .gitconfig from disk to apply custom remote rewrites), untrustedWorkspaces should be downgraded to { "supported": "limited", "description": "..." } at that time.

Virtual workspaces — supported, with the web-extension issue as a prerequisite for the github.dev case. The desktop case (e.g., remote SSH where the workspace is a virtual file system from VS Code's perspective) already works; declaring virtualWorkspaces: true is correct for that environment too.

Coordination with the web extension issue: Adding virtualWorkspaces: true is part of the web-extension migration. To keep the manifest changes coherent, this issue and the web-extension issue should land together, or this issue should land first and the web-extension issue confirm the declaration.

---

Implementation plan

• Review src/extension.js and src/remoteUrl.js for any workspace-trust-sensitive operations and document the audit in the PR description
• Add capabilities.untrustedWorkspaces set to { "supported": true } in package.json
• Add capabilities.virtualWorkspaces set to true in package.json
• Manually verify the extension functions correctly in Restricted Mode (open a folder, accept restricted mode, run all commands)
• Manually verify the extension functions correctly in a virtual workspace (deferred to web-extension issue if not yet possible)
• Update README.md to mention untrusted/virtual workspace support