What happens when you open a folder you have never seen before and your editor immediately starts running setup scripts, loading extensions, and letting an AI agent suggest terminal commands? That single moment is where the Cursor vs VS Code workspace trust audit gets interesting. Both editors look almost identical on the surface. Underneath, they answer the “should I trust this folder?” question in ways that can leave very different audit trails.
This matters more in 2027 than it did a few years ago. AI-assisted editing has moved from autocomplete to agents that read files, propose patches, and sometimes run commands. The trust boundary is no longer just about tasks and debuggers. It is about what an autonomous layer is allowed to do with your code and your machine. Here is how the two editors differ in practice, and what a real audit should check.
Why workspace trust became an audit problem
Workspace trust is a simple idea with messy edges. When you open a folder, the editor asks whether you trust the people who wrote its contents. If you say no, the editor enters a restricted mode: tasks do not auto-run, some extensions stay quiet, and workspace settings are limited. If you say yes, the folder gets full privileges.
VS Code shipped this model in version 1.57 in June 2021, and its official documentation on workspace trust lays out exactly which features get gated in Restricted Mode and which settings control the prompts. That documentation is the reference point most auditors still use, because it is versioned, public, and stable.
The problem is that trust is a human decision stored as machine state. A developer clicks “Yes, I trust the authors” on a cloned repo at 11 p.m. and forgets about it. Six months later, an auditor asks which folders on that laptop are trusted and why. Nobody knows. That gap is what a trust audit is designed to close. (Does passwordless authentication work keys passkeys trust)
The structural difference: one is a spec, the other is a fork
VS Code publishes a formal contract. Extensions declare whether they support untrusted workspaces, and the editor exposes a documented Trust API so extension authors can degrade features gracefully when trust is missing. An auditor can enumerate installed extensions, read their manifest declarations, and compare actual behavior against the documented contract. That is a checkable standard.
Cursor, by contrast, is a VS Code fork. It inherits much of the extension host and settings model, which means many trust-related behaviors look familiar. But a fork drifts. Features get added, defaults change, and the AI layer sits on top of everything. There is no public, versioned “Cursor Workspace Trust” specification comparable to VS Code’s docs. Any claim that Cursor “has” or “lacks” workspace trust should be tied to a specific release and tested, not asserted in general.
That asymmetry is the single most important thing to understand before auditing either tool. With VS Code you audit against a published contract. With Cursor you audit against observed behavior on a pinned version.
| Audit dimension | VS Code | Cursor |
|---|---|---|
| Public trust specification | Yes, versioned docs | No equivalent public spec |
| Restricted Mode behavior | Documented and gated | Inherited in part, verify per release |
| Extension trust declarations | Formal manifest contract | Inherited, verify per release |
| Trust state storage | Per-user profile | Per-user, verify location |
| AI context leaving the machine | Not part of core trust model | Core risk surface, cloud models by default |
| Agent command execution | Requires approval by default | Configurable, not a guaranteed default |
Where the AI layer changes the threat model
Here is the workflow difference that catches people out. VS Code’s trust model is essentially local. Trusting a folder means you allow local tasks, local extensions, and local settings to run. The question is whether code on your disk can execute.
Cursor adds a second question: what leaves your machine? Its headline features, including chat, the agent, and tab completion, send code context to cloud models during normal use. Privacy controls exist, but their exact scope and defaults have shifted across releases. So a folder can be perfectly safe to execute locally and still be a data exposure problem, because the AI layer reads it.
That is not a knock on Cursor. It is a structural consequence of how the product works. But it means a trust audit that only checks “is this folder trusted?” is incomplete. You need a second column: “what does the AI layer do with this folder’s contents, and is that acceptable for this repository?”
For teams thinking through the broader privacy tradeoffs of picking tools that route traffic differently, the comparison of Tor vs VPN privacy, anonymity, trust, and threat model differences is a useful mental model. Both approaches can be legitimate. What matters is that the threat model matches the tool, not the marketing.
The auto-run question
Agentic command execution is the sharpest audit delta. In Cursor, an AI agent can propose and, if permitted, execute terminal commands. Whether that respects a trust boundary is a configuration question, not a guaranteed default. In VS Code, the equivalent agent mode also requires explicit user approval by default, but the approval flow is documented and tied to the editor’s security notes.
The practical audit step is boring and essential: sit with a developer, open an untrusted folder, and watch what the agent can do without a click. Then check the settings that govern command approval. If nobody on the team can answer “can the agent run commands in a folder we have not trusted?” from memory, the answer is probably “sometimes,” and that is the finding.
A practical audit checklist that works
Audits fail when they become questionnaires. The version that actually works is short, repeatable, and tied to artifacts you can inspect.
- Pin the versions. Record the exact VS Code and Cursor build numbers under audit. Fork behavior changes between releases, so an unpinned audit is a snapshot of nothing.
- List trusted folders. VS Code stores trust decisions per user in the global profile, as well as in the UI. Export the stored trusted-folders list and review every entry against the repositories people actually work in.
- Review the trust settings. Check the values of the workspace trust keys that control whether trust is enabled, whether the startup prompt appears, and how untrusted files are handled. Enterprise policies can disable or force prompts, so confirm what policy is actually applied rather than what the default is.
- Enumerate extensions and their declarations. For each installed extension, find whether it declares support for untrusted workspaces. Extensions that do not declare trust support may run with full capability or be blocked depending on their manifest, so read the declaration.
- Test the agent boundary. In an untrusted folder, attempt to trigger an agent-proposed terminal command. Note whether approval is required, whether it is requested once or every time, and where the setting lives.
- Map data egress. For each repository, decide whether its contents may be sent to a cloud model at all. Repositories with regulated data should be excluded at the tool level, not left to individual discipline.
If your team is also tightening network-level assumptions, the zero trust networking checklist that actually works in practice covers the complementary side of the same problem: verify explicitly, assume nothing, and log the decision.
Common mistakes people make
The most frequent error is treating a trust prompt as a one-time nuisance. Developers click through it because the folder is their own clone of their own repo, which is usually fine. The mistake is that the same reflex fires on a vendor sample, a conference demo repo, or a fork pulled from a stranger’s branch. Trust prompts train click-through behavior, and click-through behavior is exactly what an attacker relies on.
The second mistake is assuming a fork inherits security defaults perfectly. It often inherits the code but not the intent. A setting that defaults to safe in the upstream project may be changed, deprecated, or shadowed by a new AI feature in the fork. Verify, do not assume.
The third mistake is auditing the editor but not the workflow around it. If developers keep one repo open for weeks, trust state barely matters. If they clone and open a dozen repos a day, trust prompts become noise and the audit needs to focus on policy and defaults instead of individual clicks.
The fourth mistake is forgetting that AI context is a separate axis. A folder can be trusted, safe to execute, and still contain code that should never leave the building. Trust and confidentiality are different questions, and conflating them is how data leaks happen quietly.
How the two editors fit different teams
For a team that wants a documented, auditable trust contract and treats AI assistance as an optional add-on, VS Code is the easier audit. The spec exists, the extension declarations exist, and the settings are named and stable. You can write a control that says “trust must be enabled and prompts must not be suppressed” and check it mechanically.
For a team that wants the AI layer as a first-class part of the workflow, Cursor’s value is real, but the audit has to be behavioral. That means pinned versions, scripted tests, and a written record of what the agent could do on the day of the test. If your team is weighing which AI editor to standardize on, the comparison of Antigravity vs Cursor vs Claude Code in 2026 is a reasonable starting point for the feature and workflow tradeoffs, separate from the trust question.
There is also the question of how much the AI editor should own. Some teams split the difference: a conventional editor for trust-sensitive repositories and an AI editor for greenfield work. That is a legitimate architecture, not a cop-out, as long as the split is written down and enforced by policy rather than habit. The same logic applies when teams evaluate whether Cursor alternatives work inside the AI code editor race; the trust posture of each option should be part of the comparison, not an afterthought.
What to document for the audit
A trust audit is only as good as its paper trail. At minimum, record the editor versions, the trust settings and their effective values, the trusted-folders list, the extension inventory with trust declarations, the results of the agent boundary test, and the data egress policy per repository. Date everything. Re-run the agent test after every major editor upgrade, because that is where behavior shifts.
One more habit pays off: keep a short note in each repository’s README stating whether it is safe to open with cloud AI features enabled. It takes two minutes to write and saves an awkward conversation later.
Conclusion
The Cursor vs VS Code workspace trust audit is not really a fight between two editors. It is a question of what kind of evidence you can produce. VS Code gives you a published contract, named settings, and extension declarations you can check. Cursor gives you a familiar fork with a powerful AI layer on top, which means your evidence has to come from testing a pinned version rather than reading a spec.
The teams that get this right do three things. They pin versions and test behavior instead of assuming inheritance. They treat trust and confidentiality as separate axes, because a trusted folder can still be a data exposure risk. And they write down what they found, so the next audit starts from a known state rather than a guess. Do that, and the trust prompt stops being a nuisance click and becomes what it was always meant to be: a recorded decision.
Frequently asked questions
Does Cursor have workspace trust like VS Code?
It inherits much of VS Code’s model because it is a fork, and it has shipped its own trust-related prompts and settings. But there is no public, versioned specification comparable to VS Code’s documentation. Treat the answer as version-specific and test the build you actually run.
Is VS Code’s Restricted Mode enough to protect a repository?
It is a strong local control. It gates tasks, debugging, some extensions, and workspace settings until you trust the folder. It does not govern what an AI assistant sends to a cloud model, so it is one layer, not the whole answer.
Where does VS Code store trust decisions?
Trust is stored per user in the editor’s global profile, and the prompt you see is not the only record. An audit should export the stored trusted-folders list and review every entry, rather than confirm only that prompts appear.
Can an AI agent run terminal commands in an untrusted folder?
In VS Code, agent mode requires explicit approval by default. In Cursor, whether the agent can execute commands depends on configuration rather than a guaranteed default. Test it directly in an untrusted folder and record the result.
How often should a workspace trust audit be repeated?
After every major editor upgrade, after any change to enterprise policy, and at least once a quarter. Agent behavior and privacy defaults are the parts most likely to shift between releases, so re-test those first. (Principle of least privilege)
What is the biggest mistake in a trust audit?
Assuming a fork inherits security defaults perfectly. Code gets inherited; intent and defaults drift. The second biggest mistake is conflating “safe to execute” with “safe to send to a cloud model.” They are different questions with different controls.
