VS Code AI extensions and secrets: what Copilot can see

VS Code’s AI extensions — GitHub Copilot, Continue, Cline, and the growing list of similar tools — are not separate programs. They are extensions running inside the editor process, and that single fact defines their access: anything the editor can see, the extension can see, and anything the extension sees can be sent to a model API as context. The practical question is not whether the extension is trustworthy. It is what happens to the secrets sitting in a typical workspace.

What the extension sees

The obvious surface is open files. Every file in the editor — including .env, if it happens to be open — is available as context. The less obvious surfaces matter more:

• Settings and task definitions. settings.json, launch.json, and tasks.json are plaintext on disk and routinely contain env blocks with credentials for debugging and build tasks.
• Terminal and task output. Extensions can capture output from the integrated terminal and from tasks they trigger. A build script that prints a connection string is delivering that string into model context.
• The workspace tree. File listings, git history, and recently opened files are all used for grounding.

None of this is exotic behavior; it is the documented way these extensions work. Copilot uses open files and terminal output to answer questions. The feature is the leak.

Where secrets actually live

VS Code has a secret storage mechanism for extension-owned values — items are stored encrypted at the operating system level and are not offered up as plaintext context. Most workspace secrets, though, never go through it. They sit in:

• .env files, loaded by dotenv-style tooling and readable by any extension that lists the workspace
• settings.json / .vscode/settings.json, plaintext JSON, often committed
• launch.json and tasks.json env blocks
• The integrated terminal’s environment, inherited from the parent shell

For an AI extension, a secret in any of those locations is a secret in context.

A useful habit is a quick sweep before installing any new AI extension: search the workspace for common token patterns and list the files that match. Knowing which files hold credentials is the first step to deciding which ones an extension should never see.

Practical hygiene

1. Move secrets out of workspace files. Keys that must exist per project belong in a password store, injected when the task or debug session starts.
2. Do not open .env files in the editor. Closing them removes an entire class of accidental context.
3. Scope and rotate. Extension-visible tokens should be the narrowest, shortest-lived credentials that work.
4. Sanitize task output. If a task can print a secret, wrap it so stdout and stderr are scrubbed before the extension sees them.
5. Filter the egress. If the extension talks to a custom OpenAI-compatible endpoint, a local DLP proxy can mask known secret patterns before they leave the machine.

The pattern is the same as for any agent: give the extension access by name, not possession. Inject secrets at the process layer when a task or debug session starts, and scrub anything that comes back. trustless implements this as a single Go binary — subprocess injection with stdout/stderr sanitization, plus a DLP reverse proxy for OpenAI-compatible endpoints. The documentation walks through the commands.

When was the last time you checked which files in your workspace contain a value Copilot could quote back to you?