Is It Safe to Give an AI Coding Agent Shell Access? A Decision Framework
Every agentic editor now asks for it, most developers grant it, and almost nobody can articulate what they just agreed to. Here is what shell access actually hands over, the three questions that decide whether it is safe in YOUR workspace, and how to grant it without giving away the machine.
"Allow the agent to run terminal commands?" is the most consequential dialog in agentic coding, and it gets clicked through in under a second. The honest answer to "is it safe?" is: it depends on three things you can actually check — what the shell can reach, what the agent reads, and what stands between a generated command and its execution. This guide walks all three, and ends with grant patterns that keep the productivity without the blank check.
What shell access actually is
Shell access is not a capability, it is ALL capabilities not otherwise fenced: every file your user account can touch, every credential in your environment variables and keychains and ~/.aws, every internal service your network position can reach, package installation, process control, and the ability to modify the agent's own configuration — including the rules files and MCP configs that constrain it. That last one matters most and gets discussed least: a shell-holding agent can, in principle, edit the instructions that govern its next action. The boundary you set in a config file is only as strong as the write-protection on that file.
Question 1: What is the blast radius of THIS workspace?
Safety is a property of the environment, not of the agent. The same grant is boring in a throwaway repo and reckless on the machine that holds your production AWS credentials. Inventory honestly: does this machine carry cloud credentials with production reach (~/.aws, ~/.config/gcloud, kubeconfigs)? Long-lived tokens in shell profiles or .env files? SSH keys to systems that matter? A network path to internal services? Each yes raises the stakes of every command the agent runs — not because the agent is malicious, but because a single generated command can now touch things whose loss you cannot shrug off.
Question 2: What does the agent read that you did not write?
An agent with shell access executes commands it composes from its inputs — and its inputs are not just your prompt. It reads rules files, MCP tool descriptions, file contents, issue text, web pages. Every one of those is a channel through which someone else's words can become your machine's commands; prompt injection is precisely the practice of turning that channel hostile. This is why shell access and untrusted input are a dangerous pair: the risk is not the agent deciding to hurt you, it is the agent faithfully executing an instruction that arrived hidden in something it was asked to read. If your agent browses the web or ingests third-party content, its shell grant deserves a stricter fence than a workspace that only ever sees your own code.
Question 3: What stands between generation and execution?
The difference between the grant modes your editor offers is exactly this: per-command approval keeps a human between every generated command and the shell; allowlists narrow what runs unattended to commands you pre-trusted; auto-approve removes the boundary entirely. Approval fatigue is real — a hundred prompts a day trains you to click yes, which is how per-command approval quietly degrades into auto-approve with extra steps. The sustainable posture is narrow-by-default: auto-approve the boring verbs you would never think twice about (test runners, linters, builds), require approval for the irreversible ones (installs, pushes, deletes, network calls), and treat every broadening of the allowlist as the authorization decision it is.
Grant patterns that hold up
The pattern that works in practice: separate WHERE the agent works from WHERE your credentials live (a dev container, a dedicated machine user, or at minimum a workspace that does not share an environment with production secrets); keep the shell allowlist short and reviewed like code, because it IS policy; keep the agent's config files — rules files, MCP configs, allowlists — under version control with human review, so the agent cannot silently rewrite its own constraints; and revisit the grant when the workspace changes, because the safe answer for last month's project is not automatically the safe answer for this one.
Know what you have granted, continuously
The uncomfortable truth about all three questions is that their answers drift. Capabilities accumulate — an MCP server here, a broadened allowlist there — and nobody re-runs the mental audit. The DeepSweep extension makes the audit a command instead of a memory: run Review My Agent Environment and it maps, in about a second, every capability your agent currently holds in this workspace — shell execution, repo write, MCP tool reach, database access — and every gap where it can act beyond what you intended. It runs entirely on your machine, free, no account, and keeps re-checking as the workspace changes. It is on Open VSX, the registry Cursor, Trae, and Antigravity install from.
Related: the eight checks that belong before any MCP server joins your workspace — https://deepsweep.ai/blog/mcp-server-security-checklist — and how to review the rules files your agent obeys: https://deepsweep.ai/blog/how-to-review-cursorrules-security