Opening a source-code folder is not always a passive action. Editor tasks, debugger configuration, extensions, and workspace settings can influence what runs on a developer’s machine. Visual Studio Code’s Workspace Trust feature creates a deliberate checkpoint between inspecting unfamiliar material and allowing the editor to operate on it with more capability.
The safest mental model is simple: read first, decide later. Restricted Mode helps reduce automatic execution while you examine a project, but it is not a complete sandbox and does not make every installed extension trustworthy. This guide explains the boundary using VS Code’s official Workspace Trust documentation, then turns it into a practical repository-review workflow.
What Restricted Mode is for
The documentation describes Workspace Trust as an additional security layer for unfamiliar code. In Restricted Mode, VS Code disables or limits features including the terminal, tasks, debugging, workspace settings, extensions, and AI agents. The goal is to prevent automatic code execution from the workspace while you assess its contents.
That is different from promising that no code can ever execute anywhere on the computer. The documentation explicitly warns that Workspace Trust cannot prevent a malicious extension from executing code and ignoring Restricted Mode. Extension selection therefore remains an independent trust decision. A mode badge is not a reason to install an unknown extension suggested by an unknown repository.
Restricted Mode can also limit useful features, which is intentional. If debugging or a task requests trust, pause rather than approving reflexively. The prompt is asking you to cross the boundary from inspection to execution. A blocked operation is not automatically a malfunction to fix by turning off the security control.
A repository is more than its main source files
Review the project’s .vscode directory, particularly tasks, launch configuration, and settings that affect executables or tool paths. VS Code’s documentation explains that task definitions can run scripts and binaries, and that they travel with committed workspace content. A task that looks convenient can still invoke commands you have not examined.
Also inspect the build and package-manager scripts you intend to run. Workspace Trust is an editor control; it does not independently approve an external terminal command. If you leave the editor and execute a project’s setup script manually, that is a separate decision with its own consequences. Do not mistake the absence of an editor warning for a completed code review.
Look for unexpected downloads, broad filesystem access, credential requests, and commands unrelated to the stated project. Context matters: a compiler invocation may be normal in a build task, while an unexplained script fetching and running remote content deserves further scrutiny. The point is to understand intended execution, not declare all automation suspicious.
Start unfamiliar projects in a separate review location
Keep unreviewed repositories outside parent folders you have already trusted broadly. The documentation says trust can be inherited from a trusted parent folder, covering its subfolders. If every download lands under a trusted directory, the usual checkpoint can disappear before you notice the new project’s status.
Use the Workspace Trust editor to inspect the trusted-folder list. If the expected “Don’t Trust” control is absent, check whether trust comes from a parent. A path-based policy is convenient, but it needs a directory layout that distinguishes reviewed projects from new material. Otherwise, convenience can quietly expand the trust scope.
For a team, document a simple folder convention and the review criteria for moving a project into a trusted location. Do not make trust depend on an arbitrary folder name alone. The location should reflect a completed decision, not substitute for checking the project’s source, configuration, and expected execution.
Review extensions independently
Extensions may be disabled, limited, or allowed in Restricted Mode depending on their declared support. VS Code shows relevant information in the Extensions view, and authors can explain their limitations. Read that information, but remember that a declaration is not a guarantee that an extension is safe or appropriate for your environment.
Choose extensions from publishers you have a reason to trust and review the capabilities you are adding. A repository’s recommendation list is a suggestion, not authorization. Consider whether an extension is actually necessary to read the code. You can often inspect the project first and defer installation until you know which development tools are required.
The documentation describes overrides through extensions.supportUntrustedWorkspaces. Do not use an override merely to silence inconvenience. Enabling unsupported functionality can change the intended boundary. If a team chooses an override for a reviewed extension, document the version, reason, and risk rather than applying a broad global exception without understanding it.
AI agents belong inside the same trust decision
The current documentation says workspace trust is shared between the VS Code window and the Agents window. When a workspace is untrusted, agents do not run in either place. That reinforces an important distinction: unfamiliar project text is material to inspect, not an instruction source that should automatically gain execution capability.
Even after trusting a workspace, review the permissions of the agent or tool you use. Repository trust does not mean every generated command is correct, every external document is reliable, or every credential request is justified. Keep high-impact actions reviewable and avoid granting broader access merely because an assistant asks for it.
For code-review workflows, decide which actions are permitted before enabling the agent. Reading files, proposing a patch, installing dependencies, and deploying a service are different operations. A clear scope makes it easier to notice when a workflow moves from useful assistance into an unexpected side effect.
Use a staged execution plan
After inspection, run the smallest necessary action in an appropriate environment. For an unfamiliar project, that may be a disposable development environment with no production credentials and only the files needed for evaluation. Restricted Mode and isolation solve different problems; combining them can reduce the consequence of a mistaken trust decision.
Avoid giving a first-run environment your usual cloud credentials, SSH agent, password-manager access, or sensitive project directories without a specific need. A legitimate test suite rarely needs every credential available on your primary workstation. Narrow access is easier to reason about and easier to revoke if the evaluation goes wrong.
Record the commands you actually run and their expected effects. Begin with checks that help you understand the project, then proceed to builds or tests according to its documented workflow. If a command behaves unexpectedly, stop and inspect the cause rather than repeatedly retrying with more privileges.
Common misunderstandings
“Restricted Mode means this repository is malware-free” is false. The feature limits selected editor behavior; it does not certify the repository. “The code came from a public hosting service” is also not a trust decision. Public availability says little about what a task or dependency-install script will execute.
“The extension was recommended by the project” is insufficient too. Review the publisher and purpose independently. And “I trusted the folder last month” does not guarantee every later change is acceptable. Trust should be supported by ongoing review of changes that introduce new execution paths or permissions.
If a feature remains limited after you expected to enable it, inspect the workspace’s trust state and extension support rather than disabling the entire mechanism. Troubleshooting should explain the constraint. It should not erase the boundary as the first step.
The practical takeaway
Use Workspace Trust as a deliberate inspection-to-execution checkpoint. Keep unfamiliar repositories outside broadly trusted parents, review tasks and settings, choose extensions independently, and give first-run environments only the access they need. When in doubt, leave the project restricted and gather more evidence.
Source checked October 8, 2026. Consult the official Workspace Trust guide for current behavior and setting names. Editor features and agent integration can evolve over time.
