Build · founder · 8 min read

What Is Your Coding Agent Actually Allowed to Touch?

Every AI coding tool now ships permission controls. They mean different things, and both major vendors say theirs are not a security boundary.

You have clicked “Allow” on an approval prompt without reading it. Everybody has. The agent wanted to run something, you were mid-thought, you clicked yes.

The question worth asking is what you were agreeing to. Not in the legal sense — in the literal sense. Which files can that agent open? Which commands can it run without asking again? And where on the internet is it allowed to send what it found?

Those are three separate questions with three separate answers, and every tool answers them differently. Here is where the two most-used tools actually stand as of today, and what to change this week.

The three levers, in plain English

Strip away the marketing and every coding agent has the same three dials:

What it can read. By default, everything in your project folder. Reading is almost never gated behind an approval prompt, because gating it would make the tool useless — reading your code is the product.

What it can run. Shell commands, package installs, migrations, deploys. This is what approval prompts are usually about.

Where it can send data. Web fetches, API calls, package registries, the model provider itself. Almost nobody looks at this dial, and it is the one that decides whether a bad day is embarrassing or expensive.

Most founders think they are managing the second dial. The first and third are where the actual risk lives.

What Cursor actually does

Cursor’s controls are called Run Modes, and there are three: Auto-review, Allowlist, and Run Everything.

Auto-review is the default and the one Cursor recommends. Allowlisted calls run immediately, other shell commands run inside a sandbox where possible, and anything left over goes to a classifier that decides whether to allow it, ask the agent to try something else, or interrupt you. Allowlist is deterministic: only what you listed runs unprompted. Run Everything does what it says.

Two dates matter here and they are not recent. Auto-review became the recommended default in Cursor 3.6 on May 29, 2026. A week earlier, in 3.5 on May 22, Cursor deprecated the old “Ask Every Time” mode — new users cannot select it at all. If you want to be asked about everything, the supported route now is Allowlist with an empty allowlist. The category moved away from “ask me first” as a default months ago, and mostly nobody announced it.

The sandbox is the more interesting layer. Sandboxed commands get read and write access inside your workspace and — importantly — no network by default. Access is then reopened by whichever network mode you are in, and the default is your own allowlist plus Cursor’s built-in defaults: roughly a hundred domains covering every package manager and language toolchain you would expect.

Read that list closely, though, because alongside npmjs.com and pypi.org it includes general-purpose object storage: *.cloudflarestorage.com, *.public.blob.vercel-storage.com, *.googleapis.com. Those are legitimately there because build tooling needs them. They are also, by definition, places data can go. “Restricted to safe defaults” and “restricted to places nothing can be uploaded to” are not the same sentence.

One more detail founders should know: Cursor’s protected-path list covers .git/config, .git/hooks, .vscode, .cursorignore and Cursor’s own config files. .env is not on it. If you want the agent to not see your secrets file, that is what .cursorignore is for, and you have to write it yourself.

What Claude Code does

Claude Code went the other direction and shipped a flag. On August 27 it added --restricted (or the environment variable CLAUDE_CODE_RESTRICTED=1), which removes the built-in tools that run commands or code, removes web fetching unless you explicitly name it, keeps file tools inside the working directory, refuses to be put into bypass-permissions mode, and ignores user, project and local settings files entirely.

That last clause is the good part: a restricted session cannot be quietly widened back out by a settings file sitting in a repository you just cloned.

It landed thirteen days after Claude Code made auto mode the default, which moves the opposite way — fewer prompts, a classifier deciding. Both shipping in one month is not a contradiction. It is a vendor conceding that “how much power should this agent have” is a per-task question, not a per-product one.

”Restricted” means two completely different things

If you read that Cursor also has a restricted mode, be careful. It does, but it is VS Code’s workspace trust feature, it is disabled by default, and Cursor’s own documentation says plainly that restricted mode breaks AI features and recommends you open untrusted repositories in a basic text editor instead.

So: Claude Code’s restricted mode is a working agent with fewer powers. Cursor’s restricted mode is a text editor. Same word, opposite products. Do not assume a security control transfers between tools because the label matches.

Both vendors tell you this is not a security boundary

This is the part to actually internalise, and you do not have to take a journalist’s word for it because both companies say it in their own docs.

Cursor’s Run Modes page carries a callout headed “Auto-review is not a security boundary,” and goes on: “The classifier can make mistakes. It can allow a call you would have blocked, or block a call you would have allowed.” Elsewhere the same docs describe the whole approval system as “best-effort guardrails rather than a hard security boundary.”

It is also worth knowing what the classifier is. Auto-review runs on a small managed model — currently Claude 4.5 Haiku or GPT-5.4 Mini. A cheap, fast model refereeing a frontier model’s decisions is a reasonable engineering tradeoff. It is not a permission system.

The practical translation: approval modes reduce how often you get interrupted. They are not the thing standing between an agent and your Stripe key. The sandbox and the network allowlist are closer to that, and they only work if you configure them.

What to do this week

Four things, none of which take long.

Check which mode you are actually in. In Cursor that is Settings → Agents → Approvals & Execution. If it says Run Everything, change it. You may have set that during a frustrating afternoon in March and forgotten.

Write a .cursorignore, or your tool’s equivalent. Put .env, .env.*, any *.pem, and any credential directory in it. This is a two-minute file that closes the single most common leak path.

Look at your network mode. If you do not need arbitrary egress, do not grant it. If your project only pulls from npm, an explicit sandbox.json allowlist is stricter than the shipped defaults and costs you nothing.

Use the restricted path for other people’s code. Reviewing a repository you did not write, auditing a dependency, poking at an open-source project — that is what --restricted is for. Use your normal setup for your own work.

The uncomfortable part

There is no consistent permission model across this category, and there won’t be one soon. Cursor’s permissions.json and sandbox.json don’t resemble Claude Code’s flags, which don’t resemble what Replit or Lovable expose. Everything you learn is per-tool, and it expires when the tool ships a release.

So the durable version of this advice isn’t a config file. It’s a habit: before you point an agent at something, decide what it would be allowed to reach if it went wrong, and check that the answer matches what you intended. Every vendor now ships the dials. Almost nobody turns them.

Related reading: your .env file is the first thing your coding agent reads, your coding agent now approves its own actions, and prompt injection is the new SQL injection.

Related guides

Recommended next step

Was this helpful?