A CLI that runs commands named in a project file should ask the user to trust that folder first, and do nothing risky until they say yes. VS Code's Workspace Trust is a public model: unfamiliar folders open in Restricted Mode, which disables features that run code automatically.
The problem in one sentence
When a user clones a repository and runs your tool, whoever wrote that repository can influence what your tool does, if your tool reads instructions from files in the repository.
Typical examples are a task list, a pre-run hook, a plugin path, a custom linter command or a setup script field in a config file. Each is convenient and each is code execution by another name.
What Workspace Trust does
VS Code's documentation says the feature lets users decide whether code in a project folder can be executed by the editor and extensions without explicit approval. When a new, unfamiliar folder is opened, it starts in Restricted Mode. The documentation lists the things limited there: AI agents, the terminal, tasks, debugging, workspace settings and extensions.
The same page adds a caution worth repeating to tool authors. Workspace Trust cannot prevent a malicious extension from executing code and ignoring Restricted Mode. A trust prompt protects against files in the folder. It does not protect against tools you installed yourself.
The page also says that when in doubt, leave a folder in Restricted Mode, and trust can be enabled later.
A design you can copy
- Default to untrusted. First run in a folder is read-only: parse files, report findings, run nothing named by the project.
- Split safe from unsafe settings. Settings that only change output format can load. Settings that name a command, URL or script path wait for trust.
- Store trust per folder, in user config. Record the absolute path, and ideally a hash of the config file. If the file changes, ask again.
- Ask once, plainly. Say which file wants to run what. Offer yes, no and inspect.
- Provide a non-interactive switch for CI. Make it explicit, for example an environment variable that names the trusted path, so a pipeline cannot be tricked into a blanket yes.
- Log the decision. A line in the output saying which folder was trusted and by what means helps later audits.
Why a hash matters
If trust is stored by folder only, a later commit can change the config and your tool will run the new version without asking. Binding approval to the content closes that gap. It costs a few lines of code.
Trade-offs
A prompt adds friction, and some users will click yes without reading. Reduce the number of prompts by keeping safe features outside the gate, so people only see the prompt when something actually wants to run code.
Quick check
Does a trust prompt stop a malicious plugin I installed?
No. VS Code's documentation says Workspace Trust cannot stop a malicious extension from ignoring Restricted Mode. Vet what you install separately.
Should CI jobs bypass the prompt?
They need a way to proceed, but make it an explicit setting that names the trusted path rather than a global yes.
Safeguard's free scan at gold.safeguard.sh/scan can list the dependencies and plugins a project pulls in.
Sources
Last reviewed: 19 October 2026.
