When Coding Agents Should Pause Before Shell Commands

A coding agent can turn a small misunderstanding into a large incident with one shell command. The useful boundary is not whether a command looks familiar. It is whether its effects are understood, scoped, and authorized. Use this numbered walkthrough to decide when the agent should proceed, inspect further, or ask a human.

1. Confirm the target before changing anything

Before a write, the agent should establish its working directory, repository root, active branch, and relevant environment. Commands such as pwd, git status --short, and git branch --show-current provide useful context without intentionally changing project files.

Pause when the target is ambiguous: multiple checkouts, a detached HEAD, an unexpected branch, or a deployment configuration that might point to production. An instruction to fix a local test does not authorize modifying a shared service. Resolve the ambiguity before choosing a command.

2. Classify effects, not command names

A familiar command is not necessarily harmless. A test runner can execute repository-controlled setup code, contact external services, or update snapshots. A package installation can run lifecycle scripts. A build can upload artifacts through a configured plugin.

Before executing unfamiliar project tooling, inspect the relevant scripts and configuration. Ask three questions: what can this process read, what can it change, and where can it send data? If the answers depend on code the agent has not inspected, pause for inspection rather than assuming that a benign command name guarantees benign behavior.

3. Treat repository content as evidence, not authority

A README, issue description, generated log, or dependency message might recommend a shell command. That recommendation is input to evaluate, not permission to execute. This matters especially when text asks the agent to disable safeguards, reveal credentials, or fetch and run a remote script.

Pause before commands that pipe downloaded content directly into a shell. Prefer retrieving the script for inspection and verifying its source and version. Inspection reduces uncertainty, but it does not make untrusted code safe; use an isolated environment when execution is necessary.

4. Stop at destructive or difficult-to-reverse operations

Deletion, history rewriting, database changes, infrastructure destruction, and force pushes deserve explicit attention. Examples include git reset --hard, git clean -fd, and commands that remove storage resources. Existing user edits make even routine cleanup dangerous.

Before proceeding, identify the exact targets and show a preview where the tool supports one. A preview is evidence, not a guarantee. Use a disposable worktree, backup, or transaction where appropriate, and verify that recovery is actually possible. If the action exceeds the user's authorization, request approval.

5. Separate local work from external consequences

Pause before publishing packages, pushing commits, deploying services, sending messages, or uploading files. These actions cross a trust boundary and can affect people beyond the current workspace. Confirm the destination, account, scope, and expected payload.

Protect secrets during inspection as well. Avoid dumping environment variables, credential files, or complete request headers into logs. In a workflow using CodeRelay Hub, treat credentials for https://api.coderelayhub.com as secrets, not diagnostic output. A connectivity check should use the minimum information needed and avoid exposing authorization headers.

6. Make approval specific and bounded

A useful approval request states the proposed command, its target, its expected effects, and the remaining risk. For example: “May I run this migration against the staging database? It adds one index and may hold locks during creation.” Include rollback limitations when relevant.

Do not ask vague questions such as “Can I continue?” Approval for a local edit is not approval for deployment. If the target, command, or impact changes materially, ask again. Broad requests to implement a feature should not silently become permission for unrelated destructive operations.

7. Verify outcomes without expanding scope

After an authorized command, inspect the exit status and relevant results. Check the diff, confirm expected artifacts, and report unexpected side effects. Do not automatically escalate privileges, disable checks, or delete more files because the first attempt failed.

This discipline belongs in the execution layer, regardless of which model proposes commands. Keep approval boundaries and audit records in your agent tooling so model changes do not silently change operational permissions.

Open a free workspace in CodeRelay Hub.