Claude Code and Cursor Can Reach Your Files. What Breaks

Claude Code, Cursor, and the other coding agents on a developer laptop can read the project, run a shell, edit files, and call tools that hold tokens. That is why they are useful. It is also why a routine task becomes a production incident: the agent had a way to act, nothing outside the model stopped the action, and the credential it used was allowed to do the damage.

One documented case, Cursor deleting a Railway volume and the backups stored on it, is written up in when an AI coding agent deleted a production database. This note is the wider permission problem that incident sits inside. The question is not whether one product had a bad day. The question is which actions your agent can take without a person, and which systems those actions can reach.

Two different controls, often confused

A permission mode decides whether a tool call runs and whether you are asked first. A sandbox decides what a command can touch once it is running. Anthropic's guide to choosing a sandbox environment separates them on purpose. They only work together. When a mode lets actions run without a prompt, the isolation boundary is what limits the blast radius. When isolation is missing, the prompt is the only thing between the model and the machine.

The same page warns that sandbox isolation reduces the impact of a breach and does not remove it. Any setup that allows network egress can still leak data the agent can read. Any setup that mounts the project writable can still change that code. Isolation also does not change what is sent to the model. Prompts and files the agent reads are still transmitted to the provider, sandbox or not.

Cursor's run modes make the same split. Auto-review runs allowlisted calls immediately, runs other shell commands in the sandbox when they fit, and sends the rest to a classifier. Allowlist mode runs what you listed, with sandboxing optional. Run Everything runs every tool call automatically, with no sandbox and no classifier. Cursor describes these as controls you choose, not as a claim that the agent is incapable of harm.

If you do not know which mode a machine is in, you do not know what the agent did while you were in another window. Ask. The setting is the control. The marketing name of the mode is not.

What Claude Code's sandbox actually wraps

Anthropic's sandboxing docs describe the Bash sandbox as a boundary the operating system enforces around shell commands Claude runs. You choose which files and network domains those commands can reach. The limits apply to Bash, PowerShell, and Monitor commands and to processes they start. Because the operating system applies the limits while the command runs, Claude Code can run sandboxed commands without asking you each time.

The next sentence is the one teams skip. The sandbox covers shell commands only. Claude's file tools, MCP servers, and hooks run outside it.

Read that against the defaults in the same document. Writes default to the working directory, a per-user temp directory, and directories you added, with protected paths still denied. Reads default to most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials. Network connections have no direct route out. They go through a local proxy that checks each host against an allow list that starts empty, and your permission mode decides what happens for other hosts. Environment variables are inherited from Claude Code, including any secrets in that environment.

So a sandboxed shell is not "the agent cannot see secrets." By default it can read credential files unless you deny those paths or mask credentials. A denyRead entry does not stop the Read tool, which is outside the sandbox. Other processes Claude Code starts — command hooks, local MCP servers, plugin monitors, language servers, and helper commands — run with your full access.

--dangerously-skip-permissions is the mode where this matters most. Claude acts without asking first. Anthropic's sandbox-environment page says that with no prompts to catch mistakes, the isolation boundary is what protects the system, and that you should run those sessions inside a container, a VM, or the sandbox runtime so file tools, MCP servers, and hooks are inside the boundary too. On Linux and macOS, Claude Code refuses to start with that flag when running as root. Run the container as a non-root user. Auto mode, which replaces the prompt with a classifier, is a different setting. A classifier is a model reviewing a model. It is not the operating system.

What Cursor's sandbox actually wraps

Cursor's sandbox lets terminal commands run without full machine access. A sandboxed command can work in the project. It cannot freely read protected files, write outside approved paths, or contact arbitrary network destinations. The defaults, from the run-modes page: read and write inside the workspace, with .cursorignore able to hide files; protected paths such as .git/config, .git/hooks, .vscode, .cursorignore, and sensitive Cursor config; network blocked by default and then opened by your network mode and sandbox.json; temp directories writable unless you disable that.

permissions.json and sandbox.json do different jobs. The first steers which calls Auto-review runs and which it reviews. The second controls what a sandboxed command can reach. You do not need either file to start. You do need to know they exist if someone on the team has already widened them.

Some commands need full system access and bypass the sandbox. Cursor says it will indicate when a command runs outside the sandbox and ask for approval. If a sandboxed command fails because of a sandbox restriction, the agent can rerun it outside the sandbox, and the classifier reviews that rerun. A failure inside the sandbox is therefore not the end of the attempt. It is a path to a broader attempt. That path is fine when a person sees it. It is a hole when the classifier is wrong or Run Everything is on.

Read access outside the workspace has its own switch. System mode, the default, lets the agent read files outside the workspace without approval. Workspace mode reads freely inside the project and asks for anything outside unless it is on a read allow list. The default is the wider one.

Three protections can still require approval even when a mode would otherwise run automatically: browser protection, file-deletion protection (including rm), and external-file protection for creating, modifying, or deleting files outside the workspace. Those are useful. They are also switches. A setup guide that turns them off to "reduce friction" has removed the prompts that were doing the work.

Where the damage actually happens

The agent does not need a novel exploit. It needs a credential and a task it wants to finish.

Destructive shell commands. Recursive delete, a database drop, a volume delete, a terraform destroy. File-deletion protection in Cursor is aimed at this class, and it is off if someone disabled it. Claude's sandbox can deny writes outside the work directory and still miss a shell that is not the one inside the sandbox, or a hook that runs with full access.

Production credentials on the laptop. A shell that can read ~/.aws/credentials can use them if the network path is open, or can print them into a context that later gets sent out. Staging and production that share one key are the same system. A comment in .env that says "staging" is not a different secret.

Deployment configuration. A change to a workflow file, a Dockerfile, a terraform variable, or a hosting dashboard is a production change even when the diff looks like a typo. The agent was asked to "fix the deploy." It fixed it by pointing production at a branch, widening a security group, or setting a public bucket. The app code in the pull request can look perfect.

Files and backups. Deleting the working copy is recoverable when the remote and the backup are elsewhere. Deleting the disk that holds the backup is not. The check is physical separation: the thing the agent can delete and the thing you restore from are not the same object. Someone has restored it on a date you can point to. A backup setting that has never been used is a hope.

The home directory. Agents that can read outside the project can read SSH keys, cloud CLIs, browser stores, and other repos. System mode in Cursor and the default read scope in Claude's sandbox both allow a version of this unless you narrow them. The agent does not have to be malicious. A debugging step that "looks around" is enough.

What a prompt cannot do

PocketOS had an explicit rule against destructive commands the agent had not been asked to run. The agent deleted the volume anyway and later said it had guessed. The write-up is linked from the outage note. The lesson that generalizes: a rule inside the context is advice. The API the token can call is the capability. If the API accepts the call without a second person, the advice already failed.

The same limit applies to "do not touch production" written in CLAUDE.md or a Cursor rule. Those files steer the model. They do not remove a key from the environment. They can also be edited by the agent or by a pull request, which means the safety policy is itself a file the agent can change. Treat instruction files as code, reviewed like code, and do not confuse them with an access-control list.

Approval fatigue is the practical failure of a mode that asks every time. People click through. Anthropic has written about that risk next to its isolation docs. The answer is not to disable prompts. It is to make the common safe actions quiet and the dangerous ones loud: reads and edits inside the project can proceed, writes outside the project and anything that changes a shared system cannot.

What to check on a machine that runs an agent

1. Name the mode. For Claude Code, say whether permission prompts are on, whether auto mode is on, and whether --dangerously-skip-permissions is used anywhere, including CI. For Cursor, say whether the machine is on Auto-review, Allowlist, or Run Everything, and whether file-deletion and external-file protection are still on.
2. Say what the sandbox wraps. If the answer is "the shell," list the tools that are outside it: file reads, MCP servers, hooks. Those need their own boundary or their own approval.
3. Read the default read scope. If the agent can read ~/.ssh, ~/.aws, and other repositories without a prompt, narrow it or move the agent into a machine that does not have those files.
4. List credentials in the environment the agent inherits. Remove production keys. Staging keys are different secrets. A read-only token is not a token that can also apply migrations.
5. Try a destructive command in a scratch directory you can afford to lose, with the mode you actually use. See whether you are asked. Then try the same command from a hook or an MCP tool, not only from the chat. The second path is the one people forget.
6. Confirm backups are on a different system, and that a restore has been done. The permission check and the backup check fail together in the incidents that hurt.
7. Look at repository instruction files and agent settings as code. Who can change them? Does CI run an agent with the same skip-permissions flag a developer used locally?

If the repo itself can no longer be changed safely, start with AI-generated code technical debt. If the tools the agent calls are the worry, start with MCP server security.

What to stop doing

Do not put production in the same environment file as the editor because it was faster to copy. Do not share one cloud key across staging and production and rely on the agent to notice the resource id. Do not treat Run Everything, or a skipped-permissions flag, as a senior engineer's laptop setting and then copy that setting into CI. CI has no person at the keyboard, which is the case the sandbox docs say needs a container.

Do not allow-list the shell, bash, node, or a package runner as a class. A command name is not the effect. npm test and npm run migrate are the same binary with different arguments. Review the arguments, the paths, and whether the action can be undone.

Do not let the agent edit the files that define its own permissions and then trust the next session. A change to a settings file, a hook, or an ignore file is a security change. It belongs in review the way a change to a CI workflow does.

A workable split

Allow the agent to read and edit the project, run the test suite, and build locally. Deny writes outside the project unless a person approves the path. Keep production credentials off the machine the agent runs on. Require a person for destructive commands, releases, and anything that transfers data to a new destination. Log the commands that ran. When you need the agent to work unattended, put it in a container or VM that does not have the host's keys, and accept that this is slower to set up than a flag.

That split is more boring than a new model. It is also the difference between an agent that can ruin a local branch and an agent that can ruin the product.

How Techtribe locks an agent's permissions down

We separate the agent's credentials from production, put a check a person controls in front of irreversible calls, and walk a restore until it works. The write-up says which mode each machine is in and what the token can still do. We do not hand the same key back to the editor and call it fixed.

If something has already been deleted, the call is about what can be rebuilt from the provider, from billing records, and from backups that were actually elsewhere. Say that in the first sentence.

When agents keep shipping into a live product and you want engineers on the repo after the lock-down, that is a Dedicated Team: your cloud, your keys, a person who can explain the path from the editor to production. A single broken path in the app itself is a smaller scope. The scope call is where we say which one you are in.

The fixed scope for taking a generated app to production is a page per tool: Lovable, Bolt, v0, and Replit.