auditing-editor-extension-workspace-trust

name	auditing-editor-extension-workspace-trust
description	Audit an editor or IDE extension for actions it runs on untrusted workspace contents, after the workspace-trust capability and activation events are resolved. Covers a task, debug preLaunchTask, or command that auto-runs on folder open, a tool path or command template read from workspace settings and executed, a workspace-trust bypass where a risky operation runs in restricted mode, a language server that loads or executes a workspace-declared binary, repo-controlled data reaching a shell or task-execution sink, and an extension webview that renders repo content without a content-security policy. Use when reviewing an extension manifest (activation events, the untrusted-workspace capability), its workspace config handling, or its language-server tool resolution. A cloned untrusted repository is the source, an action the extension auto-runs on open is the sink, and repo-controlled code reaching execution without a trust gate is the bug.
license	MIT

Auditing editor extension workspace trust: what an untrusted repository makes the editor do on open

An editor extension turns dangerous the moment merely opening a cloned repository makes it run code the repository controls. The threat is not a user choosing to run something; it is a drive-by, a hostile .vscode/tasks.json, a settings.json that names the compiler binary, an activation event that fires on folder open and shells out before the user has trusted anything. You audit it by resolving, per risky action, whether a workspace-trust gate or an explicit user gesture stands between the untrusted repo and the execution sink. The discipline is separating an action that genuinely fires on open from one that needs a deliberate click, and a value read from workspace settings from one read from user or global settings a repo cannot set.

When to use

• You are reviewing an editor or IDE extension manifest, its activation events, and its trust capability.
• The extension reads workspace configuration, runs tasks, or resolves a tool or binary path from a repo.
• You want to know whether opening a hostile repository executes code before the user trusts it.

Scope check

Audit only extensions you own or are authorized to assess, and open a crafted hostile workspace only on a machine and account in scope, an auto-executed task runs real code on your host. Adjudicate on the manifest and the handler. If you can't name the authorization, stop.

The loop

1. Resolve the trust capability and activation events first. Read the manifest for the untrusted-workspace capability (does it declare it unsupported, limited, or fully supported) and for the activation events. An event like folder-open, a startup-finished event, or a workspace-contains glob makes the extension activate on any repo; a narrow language or command event does not. The gate and the activation trigger decide whether a sink is drive-by reachable, so settle both before flagging.

2. Check auto-run tasks and debug launches. Look for the extension running a task, a command, or a debug preLaunchTask on activation or on open, before or without a trust gate. A task defined in the workspace that fires automatically is repo-controlled code executing on open.

3. Check tool and command paths read from workspace settings. Look for a compiler, linter, formatter, or runner path, or a command template, read from workspace-scoped settings and then executed. A repo that ships a settings.json naming the binary chooses what runs; the same value read from user or global settings is not repo-controlled.

4. Check the workspace-trust bypass. Look for a risky operation that still runs when the workspace is untrusted or in restricted mode, or that trusts a repo-supplied directive the core mis-validates. An extension that declares trust support but performs the dangerous action anyway defeats the gate.

5. Check language-server execution and webviews. Look for a language server that loads or executes a workspace-declared binary or plugin on open, for repo-controlled data (env, args, cwd) reaching a shell or task-execution call, and for an extension webview with scripting enabled that renders repo-controlled content without a content-security policy or message-origin validation.

6. Confirm and record. Confirm by opening a crafted hostile workspace and showing the extension executes repo-controlled code, or resolves and runs a repo-specified binary, with no trust gate and no explicit user action. Kill the lead if the extension declares the untrusted-workspace capability unsupported (or gates the risky feature when limited) so it refuses to run untrusted, if the action requires an explicit user gesture (a palette command, a button) rather than firing on open, if the tool path or command is read only from user or global settings a repo cannot set, if the activation event is narrow and its body does no execution, if the webview uses a strict content-security policy and validates message origins, or if the repo value is used only as display or config data and never reaches an execution sink. Record the extension, the trigger, and the sink the repo reaches.

Where workspace trust leaks

• The trigger decides drive-by, not the sink alone. A shell call is only a workspace-trust bug when an on-open activation or an auto-run task reaches it; behind an explicit gesture it is user intent.
• Workspace settings are attacker-writable; user settings are not. A tool path read from the repo's configuration is repo-controlled; the same key read from the global scope is out of the attacker's reach.
• Declaring trust support and then bypassing it is the bug. An extension that runs the dangerous action in restricted mode gives the gate away; the capability has to actually withhold the feature.
• A broad activation event is the on-ramp. Folder-open, startup-finished, and workspace-contains globs activate on any repo; a language-specific or command-specific event does not.
• A scripting webview rendering repo content needs a policy. Without a strict content-security policy and origin-checked messages, repo-controlled markup becomes an extension-context injection into a bridge.

Worked example (a confirm and a kill)

Confirm. An extension activates on folder open and, on activation, reads a runner command from the workspace settings and executes it to index the project. A cloned repository ships a settings.json setting runner to an attacker command. Opening the repo runs it, with no trust prompt and no user action. Confirmed repo-controlled command execution on open with no trust gate, high rising to critical, remediation = gate the feature behind workspace trust, read the runner from user or global settings only, and require an explicit gesture to execute.

Kill. The same extension declares the untrusted-workspace capability unsupported, so on an untrusted folder it activates in restricted mode and does not run the indexer until the user trusts the workspace. Opening a hostile repo executes nothing. Killed, kill_reason = "the extension declares untrusted workspaces unsupported and withholds the execution path until the user grants trust; no drive-by sink."

Rationalizations to reject

• "The user has to open the folder." -> Opening a folder is the whole attack; if activation runs code on open, cloning and opening a hostile repo is the drive-by. Ask what fires without a further gesture.
• "It only reads a setting." -> From which scope? A workspace-scoped setting is repo-controlled; if that value becomes a command or a binary path, reading it is reaching a sink.
• "We support workspace trust." -> Declaring support is not enforcing it; confirm the risky feature is actually withheld in restricted mode, not run anyway.
• "The activation event is fine." -> Is it folder-open, startup-finished, or a broad glob? Those activate on any repo; only a narrow event with an inert body is safe.
• "The webview just shows repo files." -> With scripting enabled and no content-security policy, rendered repo content is an injection into the extension context; check the policy and the message origins.

Executing this in practice

You need the manifest (activation events and the untrusted-workspace capability), the activation handler, every place a task, command, or debug launch can auto-run, every tool or command path and the settings scope it is read from, the language-server tool resolution, and any webview and its content-security policy. For each risky action, decide whether a trust gate or an explicit gesture stands between the untrusted repo and the sink. Reading the manifest tells you what activates on open; reading the handler tells you what the repo can make it run.

Related

• auditing-browser-extension-trust - the sibling client-surface audit for a browser extension, where the untrusted source is a web page or another extension rather than a cloned repository.
• auditing-electron-ipc-trust - the desktop-app sibling, where untrusted renderer content rather than a workspace reaches a native capability across the preload bridge.
• vetting-skills-before-install - audits the skill or MCP artifact you install into an agent; this skill audits an editor extension's handling of an untrusted workspace it opens, a different source and sink.
• FINDING-SCHEMA.md - source = a cloned untrusted repository, sink = an action the extension auto-runs on open, evidence = the resolved trust gate, the activation trigger, and the executed repo-controlled code.