How to Use Command Line Coding Agents Safely

A command line coding agent runs as you, so it can often reach what you can reach. Use it safely by starting in one project folder, keeping approvals on, turning on a sandbox, blocking access to secrets, and reviewing every change. Avoid modes that skip all prompts unless the agent is inside a disposable environment.

Tools such as Claude Code, Codex and Gemini CLI can read code, run tests and fix bugs for you. They work from your terminal and can start other programs. That is what makes them useful, and it is also why a bad instruction hidden in a file or web page can matter. This guide gives you settings to use and habits to build. Options change quickly, so check the docs for your version.

What a coding agent can reach

Think through these before your first session:

Files. Your project, and possibly other folders, including ~/.ssh, ~/.aws/credentials and .env files.
Commands. Anything your shell can run, including package installs and scripts.
Network. Downloads, uploads and calls to other services.
Accounts. Whatever you are signed in to through tools like git, gh or cloud command line tools.
Added tools. MCP servers, plugins and hooks, which can run outside the agent's normal limits.

The main risk is prompt injection, where text the agent reads changes what it does. It can arrive in a README, an issue, a package or a web page. OWASP says no method reliably prevents it, so plan to limit the damage.

How to set up Claude Code

These details come from the permissions docs and the sandbox docs.

Start in your project folder, not your home folder.
Run /permissions to see every rule and which file it comes from.
Keep the default manual approvals while you learn the tool. Plan mode is useful when you want the agent to look around without editing source files.
Add deny rules for secrets to .claude/settings.json, such as Read(./.env). These rules cover Claude's file tools.
Run /sandbox to turn on the sandbox for commands. It is off by default.
Lock down reads. The docs say the sandbox allows reads across most of the machine by default, including ~/.ssh and ~/.aws/credentials, so restrict those paths yourself.
Allow only the network hosts you need. The sandbox's list of allowed domains starts empty.
Set sandbox.failIfUnavailable to true. Otherwise commands run unsandboxed if the sandbox cannot start.

On Linux and WSL2 the sandbox needs bubblewrap and socat. On native Windows, commands run unsandboxed, so use WSL2 instead. Hooks and local MCP servers run outside the sandbox.

How to set up Codex

These details come from OpenAI's sandbox docs.

Use read-only when you only want the agent to look at code.
For normal work, run codex --sandbox workspace-write --ask-for-approval on-request. OpenAI describes this as the lower-risk preset for local automation.
Use /permissions in the command line tool to review or switch modes during a session.
Avoid danger-full-access with an approval policy of never. That removes the filesystem and network boundaries.

You can save these choices in config.toml with sandbox_mode and approval_policy. Older guides mention an untrusted policy, which OpenAI's docs now say is no longer selectable.

How to set up Gemini CLI

Check which tool you have first. The Gemini CLI docs say it was replaced by Antigravity CLI on 18 June 2026 for unpaid tier and Google One users, so settings may differ for you.

Start it with gemini --sandbox, or set "sandbox": true under tools in settings.json.
Turn on trusted folders by setting folderTrust to enabled under security in your user settings.json. The feature is off by default.
Choose Don't trust for code you did not write. In that safe mode, the tool ignores project settings and .env files, does not connect to MCP servers, and asks before any tool runs.
Avoid YOLO mode, which runs all tools without asking.

Rules that apply to every agent

Keep secrets out of the project folder. Use a secrets manager and load values only when needed. Our API key guide shows how to find the ones already there.
Use narrow credentials. Give the agent read-only or test tokens. Never leave production keys in your shell while an agent runs.
Work on a branch. Commit before you start, so a bad change is easy to undo.
Read each command. Be careful with anything that pipes a download into a shell, changes a config, or sends data out.
Review the diff. Check changes to build files, dependencies and agent settings as closely as you check the code.
Be careful with cloned projects. A repository can carry its own agent settings, hooks and MCP config. Read them before you trust the folder.
Limit auto-approval. A rule that always allows a broad command, like npm or bash, can allow much more than you meant.
Watch for tampered tools. Install from the official source, and pin or delay updates where you can. The Cursor marketplace incident showed a trusted listing can carry bad code.

When to use no-prompt mode

Skipping prompts is sometimes reasonable, such as a long task in continuous integration. If you do it, use a throwaway container or virtual machine with no personal files, short-lived credentials and limited network access. Assume anything inside it could be changed or read. A disposable environment is what makes this acceptable, not trust in the agent.

What to do if an agent went wrong

Stop the session.
Check git status and git diff, and look at recent commits.
Check your shell profile, scheduled tasks, SSH keys and agent settings for changes.
If it may have read a secret, rotate the secret.
Review recent activity in the accounts it could reach.

Prycheck can list the agent configs and plain text keys on your computer, so you can see what a new agent would find.

Frequently asked questions

Is a sandbox enough on its own?

No. A sandbox limits commands, but built-in file tools and added servers may follow different rules. It can also still allow reads of sensitive files unless you restrict them. Use it together with approvals and narrow credentials.

Can I stop an agent from reading my .env file?

You can make it much harder with deny rules and sandbox limits. The safest option is not to keep real secrets in that file, because rules can have gaps and vary by tool.

Are coding agents safe for work code?

That depends on your company's rules and the plan you use. Check whether your code is used for training and how long it is kept. Then get approval before pointing an agent at private code.