FIELD GUIDE

VS Code Agent Permissions: Terminal Approvals, MCP Tools and Workspace Trust

An AI agent inside Visual Studio Code may offer to edit files, invoke tools or run terminal commands. These are different operations with different risks. An approval dialog is a decision about a concrete operation, not proof that the

An AI agent inside Visual Studio Code may offer to edit files, invoke tools or run terminal commands. These are different operations with different risks. An approval dialog is a decision about a concrete operation, not proof that the model has understood the repository, and a previously trusted workspace should not make an untrusted MCP server automatically safe.

What the tool actually does

Microsoft documents agent approval controls and distinguishes tool access, execution permissions and sandbox-related configuration. Tools can be provided by the editor or through Model Context Protocol integrations, expanding what an agent can ask other programs to do. Security depends on the effective policy at runtime, where the tool executes, and whether permission is scoped to the action or remembered more broadly. Product documentation evolves; publish a version-pinned policy walkthrough only after verifying the VS Code build in use.

A practical workflow and what to verify

A practical onboarding test has three stages: first request a read-only summary of a small test project, then permit one bounded file edit, and finally ask to run the exact unit-test command. Inspect the tool-call payload each time. If an MCP server is involved, identify its executable, supplier, environment variables and outbound endpoints before enabling it. Test what happens when the server returns an instruction-like string rather than ordinary task data; the agent should not promote that response into user authority.

Limits and failure modes

Successful editor interaction does not establish a secure sandbox. A terminal tool can invoke package lifecycle scripts or exfiltrate environment variables through seemingly routine diagnostics. Workspace content, fetched web pages and MCP tool results are lower-trust inputs; instructions embedded in them should never overrule developer approvals. Settings names and default modes may change across releases, so describe controls by verified local version rather than claiming that every reader sees identical menus.

Data governance, approvals and security

Keep a separate dev-container or disposable worktree for unknown projects, avoid inheriting production cloud credentials, and require manual approval of commands with network, deployment or credential effects. Enterprise administrators should test policy inheritance, extension installation restrictions, telemetry settings and logging. Verify exactly which MCP servers are installed, including transitive tool configuration, and use version control to review any project-scoped agent instructions.

Who should use it—and alternatives

This workflow is useful for teams adopting GitHub Copilot or any agent integration within VS Code and wanting a repeatable permission baseline. Terminal-first tools such as Codex and Claude Code require their own sandboxes and policy audits, while Continue and Cline have separate product-specific tool permissions. This guide is not a substitute for any extension vendor’s data-processing policy.

Documented scope and evidence date

This article reports the development workflow documented in the linked first-party sources accessed on 25 October 2026. It is not a hands-on product test or an independent performance claim. Client behavior, account entitlements and supported countries can differ across releases. Exact per-seat charges, quotas, trial allowances, API-model versions, and deployment guarantees are intentionally not supplied without a dated, tier-specific verification. For engineering procurement, capture the installed client version and active contract as separate evidence.

Acceptance checklist before production

  1. Check the exact editor, extension or CLI version in the actual installation, and the applicable sign-in or admin policy.
  2. Give the task a clear behavioral acceptance criterion and specify files, branches, credentials and networks outside its permitted scope.
  3. Use a disposable branch/worktree and preserve the baseline; do not rely on an agent summary as proof of test execution.
  4. Review the diff, new packages, build scripts and CI configuration, then rerun targeted and regression tests in a trusted environment.
  5. Require normal peer review and release approvals; keep a record of external code/context processors before using confidential repositories.

Sources & Further Reading

CONTINUE EXPLORINGExplore related files ↗