A coding agent runs commands as you, with your files, your keys and your network. Most of the time that's the point. But it also reads whatever instruction files sit in the folder you start it in, and it can be talked into things. This guide covers the setup that keeps a bad file or a bad guess from turning into a bad day: where to start the agent, how to sandbox it, which approval settings to use in Claude Code, Cursor, Codex, Copilot, Cline and Gemini CLI, how to keep secrets out of reach, and how to check its work before it ships. Every setting name below comes from the tool's own docs, checked on October 27, 2026.
Our take: the middle column is where most of the damage happens. Every one of those switches is fine inside a throwaway container. On your everyday laptop, at the top of your home folder, it's a bad idea.
Agent settings change every few weeks
Hotfix Daily flags the changes that matter, with the source. Free, weekdays, about 3 minutes.
Join free and get 13 ready-to-paste Starter Prompts for coding agents, vibe coding and game dev right away.
Agents read instruction files such as AGENTS.md and CLAUDE.md from the folder you launch them in, and treat what's inside as guidance from you. So the folder you start in decides what the agent believes it was told to do.
That's why issue #5's Hotfix of the Day was "never start a coding agent in your Downloads folder." On October 22, 2026, Forever Security reported finding a planted AGENTS.md in a real customer's ~/Downloads. A website can drop a file there without a click. In their tests, the file got Codex to add an MCP server to ~/.codex/config.toml and install an npm package in over 90% of runs, and a planted CLAUDE.md got Claude Code to write an ANTHROPIC_BASE_URL into .claude/settings.json, which could leak its login token, about half the time. They also say roughly half of their customers run an agent from Downloads.
The tool makers say the same thing about broad folders. GitHub's Copilot CLI docs put it plainly: "Typically, you should not launch Copilot CLI from your home directory." Claude Code only lets you trust your home directory for the current session (docs), and Codex starts folders that aren't under version control in read-only mode (docs).
Use one folder per project, inside a folder like ~/code/, with git init and a first commit before the agent touches it.
For quick experiments, use a scratch folder such as ~/scratch/2026-10-27-test, or a container. Never Downloads, Desktop or $HOME itself.
Read the instruction files in any repo you didn't write before you start an agent in it: AGENTS.md, CLAUDE.md, GEMINI.md, .cursor/rules, .github/copilot-instructions.md.
Check agent config for things you didn't add. Forever Security suggests looking for unexpected [mcp_servers.*] blocks or a changed chatgpt_base_url in ~/.codex/config.toml, and for ANTHROPIC_BASE_URL in .claude/settings.json. If you find one, remove it and rotate the token.
Don't click past the trust prompt. Copilot CLI, Claude Code and Gemini CLI all ask whether you trust a folder. Gemini CLI's --skip-trust flag skips that check (reference), so save it for folders you know.
2. Sandboxing basics
A sandbox limits what the agent's commands can reach, so a bad command fails instead of doing damage. There are three levels, from lightest to strongest:
The agent's own sandbox. Codex sandboxes by default. Cursor sandboxes shell commands in Auto-review and Allowlist. Claude Code, Copilot CLI and Gemini CLI have one you switch on. These mostly cover shell commands. Claude Code's docs say file tools, MCP servers and hooks run outside its sandbox, and that by default sandboxed commands can still read most of your machine, including ~/.ssh and ~/.aws/credentials, unless you deny those paths (docs). GitHub calls its local sandbox "lighter-weight" isolation that doesn't use a VM or container (docs).
A container or dev container. The whole agent runs inside, so everything it does stays inside. Claude Code has a dev container guide, Gemini CLI can run its sandbox in Docker or Podman (GEMINI_SANDBOX=docker, docs), and OpenAI's Codex docs suggest a Dev Container as the outer boundary. One warning from Anthropic's page: with permissions skipped, a malicious project can still take anything inside the container, including the agent's own credentials, so don't mount ~/.ssh or cloud credential files into it.
A remote sandbox. Cloud agents run on someone else's throwaway machine: Copilot cloud agent works in "an ephemeral cloud development environment" (docs), Cursor Cloud Agents "run inside their own dedicated machine" (docs), and Copilot CLI has cloud sandboxes in public preview. Your laptop is out of reach, but anything you give the session, like repo access or tokens, is not.
Our take: turn on the built-in sandbox everywhere you can, since it's free and costs you a few prompts. Move to a container the day you want to stop answering prompts.
3. Approval and sandbox settings, agent by agent
Only settings we found in each tool's official docs today. Names change often, so check the linked page if a menu looks different.
Approvals:/permissions manages allow, ask and deny rules, checked in that order: deny first, then ask, then allow. Permission modes are default (shown as Manual), acceptEdits, plan, auto (a classifier reviews actions), dontAsk and bypassPermissions. Set the starting one with defaultMode. The docs say to use bypassPermissions only "in isolated environments like containers or VMs", and admins can turn it off with permissions.disableBypassPermissionsMode.
Sandbox: off until you run /sandbox or set sandbox.enabled. It limits shell command writes to the working folder and sends network traffic through an allowlist (network.allowedDomains) that starts empty. Add filesystem.denyRead entries for secret folders. Set failIfUnavailable if you'd rather it refuse to start than run unsandboxed.
Our take: start in Manual or acceptEdits with the sandbox on. Add deny rules for .env and secrets (see below).
Approvals: Settings > Agents > Approvals & Execution has three Run Modes. Auto-review (the recommended default since Cursor 3.6) runs allowlisted calls, sandboxes other shell commands when it can, and sends the rest to a classifier. Allowlist runs only what you've listed. Run Everything runs every call without checks. Cursor's docs say plainly that "Auto-review is not a security boundary." You can steer it with plain-English block_instructions in ~/.cursor/permissions.json or .cursor/permissions.json.
Sandbox: sandboxed shell commands can read and write the workspace, can't touch protected paths like .git/config, .git/hooks and .vscode, and have network blocked except for your sandbox.json allowlist plus Cursor's package-manager defaults. Since 3.23 (Oct 1, 2026), Read Access: Workspace makes the agent ask before reading files outside the project. On Linux the sandbox needs kernel 6.2 or later with Landlock. Without it, Cursor asks before running commands.
Our take: keep Auto-review, switch Read Access to Workspace, and leave File-Deletion and External-File Protection on. The Cursor CLI has its own permission settings, so set those separately.
Approvals and sandbox: Codex has two layers, a sandbox mode and an approval policy. Locally it starts with no network and writes limited to the workspace. The Auto preset is --sandbox workspace-write --ask-for-approval on-request. There's also read-only, --ask-for-approval never, --sandbox danger-full-access, and --dangerously-bypass-approvals-and-sandbox (alias --yolo), which the docs label "not recommended." In workspace-write, .git, .agents, .codex and .aws stay read-only. Network stays off unless you set network_access = true under [sandbox_workspace_write]. Use /permissions to switch modes and /status to see which folders it can write.
Our take: Codex has the safest default of the six. Keep Auto, and don't turn on network access for a whole project when one command needs it. If an old config still says approval_policy = "untrusted", change it, because the docs now list that value as retired.
Approvals: on launch, Copilot asks whether you trust the folder "for the currently running session only" or for future sessions too. Permanent trust goes in trustedFolders in ~/.copilot/config.json. In manual approval mode it asks before tools that aren't already allowed. --allow-tool and --deny-tool take patterns like shell(git:*), write(src/*.ts) or read(.env), and deny always wins, even over --allow-all. --allow-all (or --yolo) equals --allow-all-tools --allow-all-paths --allow-all-urls. /permissions assisted lets a model approve requests it judges safe.
Sandbox: local sandboxing is off by default. Until you run /sandbox enable, Copilot's shell commands "can read, write, and delete wherever you can." GitHub's own risk advice is a sandbox, or "a virtual machine, container, or dedicated system."
Our take: trust per session, run /sandbox enable once, and add --deny-tool='shell(git push)' so pushing stays your job.
Approvals: Auto Approve has separate toggles: Read project files, Read all files, Edit project files, Edit all files, Execute safe commands, Execute all commands, Use the browser, Use MCP servers. "Safe" is decided by the model, which flags each command with requires_approval. Cline's docs say "Cline does not use a fixed allowlist." Their recommended start: enable Read project files and "leave edits, commands, browser, and MCP off until you have a specific reason," with Checkpoints on if you allow edits.
YOLO: Cline's docs still describe a YOLO Mode checkbox that auto-approves everything and "disables all safety checks." A change merged in August 2026 (cline/cline#13126) removed that toggle from the newer VS Code extension and turns on every auto-approve action for people who had it on. Either way, all toggles on means nothing asks first.
Our take: Cline's auto-approve docs don't describe an OS sandbox, so if you want commands to run unattended, run Cline inside a dev container.
Approvals:--approval-mode takes default, auto_edit, yolo or plan. The old --yolo / -y flag is deprecated in favor of --approval-mode=yolo. Folder trust is checked on start unless you pass --skip-trust.
Sandbox: off by default. Turn it on with -s / --sandbox, the GEMINI_SANDBOX variable (true, docker, podman, sandbox-exec, runsc or lxc), or "tools": {"sandbox": ...} in settings.json. Note that the default macOS profile, permissive-open, limits writes to the project but allows network.
Our take:GEMINI_SANDBOX=docker is the easy win. Also note that Google's docs say Gemini CLI was replaced by Antigravity CLI for unpaid-tier and Google One users on June 18, 2026. We haven't checked Antigravity CLI's settings, so they aren't covered here.
Assume anything the agent can read could end up in a prompt, a log or a commit. The fixes are boring and they work:
Keep .env out of git. Put it in .gitignore and commit a .env.example with fake values instead.
Block it in the agent. Claude Code: deny rules like Read(./.env) and Read(./secrets/**). Cursor: list it in .cursorignore, though Cursor's docs warn that terminal and MCP tools can't be blocked that way. Copilot CLI: --deny-tool='read(.env)'.
Know the limit. Claude Code's docs note that Read and Edit deny rules don't stop a script the agent runs from opening the file. Only the sandbox enforces that at the OS level. So don't keep production keys in a folder an agent works in.
Use small, short-lived keys. Give the agent a test key or a token scoped to one repo. Anthropic's dev container page says to prefer "repository-scoped or short-lived tokens" and not to mount ~/.ssh or cloud credential files.
Redact in logs. Copilot CLI's --secret-env-vars hides named variables in output.
Turn on push protection. GitHub's push protection blocks pushes that contain detected secrets before they reach the repo.
If a key leaks, rotate it. Deleting the commit doesn't make the key safe again.
5. Review the diff, not the summary
The agent's "Done! All tests pass" is a claim, not proof. OpenAI's Codex docs give the habit that works with any agent: work on a feature branch, start from a clean git status, commit often, and review the agent's diffs the way you'd review a pull request (docs).
Run git status and git diff --stat first. Files you didn't expect are the first warning sign.
Look hard at changes to agent and build config: AGENTS.md, CLAUDE.md, .claude/, .cursor/, .codex/, .mcp.json, .github/workflows/, package.json scripts and lockfiles. That's where a hijacked agent hides its changes.
Check new dependencies by name. A package you've never heard of is worth a 30-second search.
Keep pushes and merges for yourself, for example with a deny rule for git push.
6. Make CI on a clean checkout the gate
Your laptop has caches, local files and keys that the repo doesn't. CI starts from a fresh checkout of what you actually committed, so it catches the file the agent forgot to add, the test that only passes with your .env, and the step it skipped. Then make that check required: with GitHub's required status checks, "all required status checks must pass" before changes merge into a protected branch.
A minimal GitHub Actions workflow looks like this. Swap in your own install and test commands:
name: ci
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
Our take: this is the one step that still protects you on the day you skip the others. Hotfix Daily's own site works this way: every change is built and validated on a clean runner before it goes live.
The 10-minute checklist
Start agents in a git project folder or a scratch folder, never Downloads or $HOME.
Read AGENTS.md / CLAUDE.md in repos you didn't write.
Turn on the agent's sandbox: /sandbox (Claude Code), /sandbox enable (Copilot CLI), -s (Gemini CLI). Codex and Cursor have one on by default.
Pick the middle approval setting, not the hands-off one.
Block .env and secret folders. Use test keys.
Check ~/.codex/config.toml and .claude/settings.json for MCP servers or base URLs you didn't add.
Branch, commit often, read the diff.
Require CI to pass before merging.
FAQ
Is it safe to run an AI coding agent on my laptop?
It can be, if you start it in a project folder you trust, keep approvals on, and turn on the built-in sandbox where the agent has one. The risky setups are the hands-off modes (Claude Code bypassPermissions, Codex --yolo, Copilot --allow-all, Cursor Run Everything, Gemini CLI yolo approval mode) on your normal machine. Each tool's own docs say to keep those for isolated environments.
Why shouldn't I start a coding agent in my Downloads folder?
Coding agents read instruction files such as AGENTS.md and CLAUDE.md from the folder you start them in. A website can drop a file into Downloads without you clicking anything. On Oct 22, 2026, Forever Security reported finding a planted AGENTS.md in a real customer's Downloads folder that tried to make the agent add an MCP server and install an npm package. Start agents in a project or scratch folder instead.
Which AI coding agents have a built-in sandbox?
As of Oct 27, 2026: Codex CLI sandboxes by default (workspace writes, no network). Cursor sandboxes shell commands in its Auto-review and Allowlist modes. Claude Code, GitHub Copilot CLI and Gemini CLI have sandboxes you turn on yourself. Cline's auto-approve docs don't describe one, so use a container. Built-in sandboxes mostly cover shell commands, so a container or VM is still the stronger boundary.
How do I keep my .env file away from an AI agent?
Keep .env out of git, then block it in the agent: a Read(./.env) deny rule in Claude Code, a .cursorignore entry in Cursor, or --deny-tool='read(.env)' in Copilot CLI. These rules don't stop every script the agent runs, so don't keep long-lived production keys in a folder an agent works in. Use scoped, short-lived tokens and turn on GitHub push protection.
Do I still need CI if the agent says the tests pass?
Yes. An agent runs tests in your working copy, with your local files and caches. CI runs them on a fresh checkout of what you actually committed, which catches missing files, secrets that only exist on your machine, and steps the agent skipped. Make the CI check required before merging to main.
Found this useful? Hotfix Daily covers changes like these every weekday. Get the updates free, plus 13 Starter Prompts. Or share it on X.
How we write these: we read each tool's official docs on the date shown and link the page for every setting we name. "Our take" lines are our opinion. Settings change often, so check the linked page before you rely on a detail. This guide has no affiliate links.
Get the next issue in your inbox
Five things worth your attention in AI, agents, vibe coding and game dev, every weekday. Plus 13 free Starter Prompts and the AI Builder Starter Stack PDF when you join.
