The shell is a powerful boundary
A coding agent with terminal access can inspect files, install packages, run tests and edit a repository. The same capability can remove data, read credentials or call remote services. Treat a terminal command as an action with a scope, working directory and effect. A seemingly harmless one-liner may invoke a script defined in a package manifest, which can do more than its name suggests.
The goal is not to forbid shell use. Tests and build tools are essential to trustworthy software changes. The goal is to make commands understandable and proportionate to the task. Before approval, identify what program will run, what files or services it may touch, and how the result will be observed.
Classify commands by effect
Read-only inspection includes listing files, searching source and reading Git status. Mutating local actions include edits, dependency installation, code generation and cleanup. External actions include publishing, opening network endpoints and writing to remote APIs. The categories can overlap: a test may rewrite snapshots, and a package install can execute lifecycle scripts or reach the network.
Ask the agent to show the exact command, working directory and reason. Prefer a narrow file search over a script that crawls an entire disk. Prefer a targeted test before a broad command with side effects. If a command's effect depends on project scripts, inspect the script definition. The surface label 'test' is not proof of read-only behavior.
Reduce the blast radius
A dedicated workspace, sandbox or container can limit what an agent can access. Restrict credentials to the minimum scope needed. Keep production secrets out of the environment when the task only requires local code checks. Run from a clean Git state or an isolated worktree so changes are easier to attribute. These controls make mistakes less expensive and review more reliable.
Sandbox rules are only useful if they are enforced by the runtime. A policy sentence in a prompt cannot stop a process with unrestricted filesystem rights. Test the boundary with safe examples and understand which commands require human approval. Auto-approval should be narrow and based on actual impact, not merely on a familiar command prefix.
Beware of indirect execution
Commands can invoke other programs. A build script may fetch dependencies, a task runner may call a deployment command, and a shell alias may change the meaning of a familiar word. A copied command from a document or issue could contain malicious substitutions. Agents should treat external text as data and derive commands from the user's task and trusted project configuration.
Inspect scripts before running them in an unfamiliar repository. Avoid piping remote content directly into a shell. Prefer pinned dependencies and documented package commands. If a tool proposes a long composite command that is difficult to audit, split it into smaller steps with visible output. Each step should answer a specific question or perform a specific approved mutation.
Approval must include context
An approval prompt is useful when it identifies the action and its consequences. 'Allow terminal' is too broad for a command that could delete a directory. A better prompt includes the command, target path, environment and whether network or secret access is involved. The user can then decide from concrete facts instead of guessing what the agent intends.
High-impact operations deserve a separate decision even if earlier read-only commands were allowed. In a repository, deployment and database migrations are qualitatively different from running a unit test. Credentials, external users and irreversible state may be involved. The agent should prepare a reviewable result before requesting approval for such steps.
Read output and verify effects
A zero exit code means the process reported success. It does not prove the intended behavior or that no unrelated files changed. Read the command output and inspect Git diff or filesystem state afterward. Tests can pass while generated files are stale; an install can update a lockfile unexpectedly. The agent should report exactly what it checked and what remains unverified.
If a command fails, diagnose before retrying. A failure caused by missing credentials should not trigger a creative workaround that exposes a different key. A network timeout does not justify repeating a non-idempotent external write without checking whether it succeeded. Safe terminal use includes careful response to ambiguous results.
An example review sequence
For a small bug, the agent can search relevant source, read a test, propose a focused patch and run that test. The developer reviews the command and output, then checks the diff. If typechecking is needed, the agent explains why and runs it. A package installation is not automatically necessary merely because the test failed; the failure may reflect an existing setup issue.
This sequence keeps evidence connected to action. The agent earns broader autonomy by behaving predictably on bounded tasks, while the user retains control over credentials, data deletion and deployment. Terminal safety is less about one warning dialog than about a workflow that makes intent and result inspectable at every consequential step.
Terminal autonomy should grow only with clear permissions, bounded scope and observable results.
Sources & further reading
References support the concepts and product descriptions discussed above. Features, prices and account eligibility can change; check the live documentation. Inclusion here is not a hands-on test or vendor endorsement.