Cursor agent on a Mac: keeping an eye on what it edits

The interesting question about the Cursor agent is not what it can build. It is what it is allowed to touch while nobody is looking at the screen. An agent that reads files, edits them, and runs shell commands is a process with write access to a working directory, and the defaults that govern it are documented, adjustable, and easy to misread.

On a Mac this matters more than it looks, because the folder the agent is working in is almost never the only folder involved. There is a reference directory somewhere else, an export folder on an external disk, a notes vault in iCloud. The agent sees one workspace. The work spans several.

What runs without asking, by default

Cursor's own agent security documentation draws the line in a specific place, and the line is worth knowing before turning autonomy up.

Reading files and searching code need no approval. That is the baseline, and it is the reason .cursorignore exists: it is the mechanism for keeping specific files out of reach rather than trusting a prompt to avoid them. Anything holding credentials, client data, or a private export belongs in that file before the first long-running task, not after.

Editing is where the default surprises people. Workspace files can be modified without approval, and the changes save straight to disk. There is no staging step and no held buffer. Configuration files are the exception and need explicit approval first, which is a sensible carve-out, though the documentation adds a warning worth reading twice: if auto-reload is on, agent changes to configuration can take effect before anyone has looked at them.

Terminal commands need approval by default. This is the setting most people relax first, and it is the one where relaxing it changes the shape of the risk rather than the size of it.

Network access is narrower than expected. The built-in tools reach GitHub, direct link retrieval, and web search providers. With default settings the agent cannot make arbitrary network requests, which removes a whole family of exfiltration routes without any configuration.

One more default is easy to miss. Cursor supports workspace trust, the VS Code mechanism for opening an unfamiliar repository in a restricted mode, but it ships disabled. Turning it on means adding "security.workspace.trust.enabled": true to user settings, and the documentation is blunt about the consequence: restricted mode breaks the AI features, so the recommendation for a repository nobody trusts yet is to open it in a plain text editor instead. That is a more honest answer than a half-restricted agent session, and it is worth deciding in advance which repositories fall into that category.

The tools, and why the count matters

An agent is described in the documentation as three parts: the instructions that shape its behavior, the tools it can call, and the model chosen for the task. The tool list is the part that determines what supervision has to cover, and it is longer than a chat interface suggests.

Beyond reading, searching, and editing files, the agent can run shell commands, generate search queries and perform web searches, fetch rules on demand, and drive a browser to take screenshots, navigate pages, interact with elements, and verify that a visual change looks right. Image files are read as images rather than as text, which means a screenshot dropped into a conversation becomes context for a vision-capable model.

The detail that changes how a long task should be watched is this: there is no limit on the number of tool calls the agent can make during a single task. A prompt that looks small can expand into hundreds of operations. That is the intended behavior, and it is also why the approval mode chosen at the start matters far more than the wording of the prompt. One decision at the beginning governs a number of actions nobody can predict at the beginning.

Run Modes, and the thing they are not

Approval behavior for shell, MCP, and Fetch calls is set in one place: Settings, then Agents, then Approvals and Execution. Three modes are offered, and they differ in what happens to a call nobody has pre-approved.

Mode	What runs unprompted	Classifier	Best suited to
Auto-review	Allowlisted calls run at once. Other shell commands run sandboxed where possible. The rest go to a classifier.	Yes	Long tasks where constant prompts defeat the purpose
Allowlist	Only the actions explicitly listed	No	A small, repeated set of trusted commands
Run Everything	Every tool call	No	Throwaway repositories and containers

Auto-review is the mode Cursor recommends for most people, and the documentation is unusually direct about its limits: it states plainly that Auto-review is not a security boundary, and that the classifier can allow a call that should have been blocked or block one that should have run. The classifier itself runs on a small Cursor-managed model rather than the frontier model chosen for the task.

That framing is the useful part. Auto-review reduces interruptions. It does not transfer responsibility. A reviewer that is right most of the time is a productivity feature, and treating it as a permission system is where people get hurt.

Sandboxing sits on top of the mode rather than replacing it. A shell command is sandboxed when it fits inside the sandbox's file and network limits. Commands that need writes outside the workspace, or privileged operations, cannot be sandboxed and go to the classifier instead. So the commands most worth containing are precisely the ones the sandbox cannot contain.

MCP follows a stricter path. Every connection needs approval, and after a connection is approved each individual tool call still needs approval unless it has been added to an MCP allowlist. Given that an MCP server is third-party code with network access, that default is the right way round.

Where the agent actually runs

The same agent is reachable from three places, and the choice changes what supervision is even possible.

In the editor it lives in the side pane, opened with Cmd+I. The diff view updates as edits land, which makes the run watchable in the literal sense. A wrong turn can be cut short with Cmd+Shift+Backspace rather than waiting for the task to finish and then reverting it.

In the terminal, the Cursor CLI installs with a single curl command and runs as agent. It carries the same three modes as the editor: Agent for full tool access, Plan for designing an approach before any code changes, and Ask for read-only exploration. Ask mode is underrated as a supervision tool, because a read-only pass over a branch cannot damage anything while still answering the question of whether the work is going the right way.

Print mode, invoked with -p, is the CI and scripting path. It is also the mode where approval settings deserve the most thought, since there is nobody present to answer a prompt.

There is a handoff worth knowing about: prefixing a message with & pushes the conversation to a Cloud Agent that keeps running after the laptop closes, and the task can be picked up later at cursor.com/agents. For a larger piece of work such as a migration, a Project assigns a coordinating agent that plans and delegates to others, which is a different supervision problem again, since the plan is now also generated rather than written.

Reviewing what came back

Cursor's own guidance on reviewing agent output makes a point that survives outside Cursor: the standard for what gets merged should not depend on who wrote it. Generated code can compile, follow existing patterns, pass the tests already written, and still be subtly wrong in the cases nobody wrote a test for.

Two habits do most of the work. The first is tagging @Branch in a prompt, which hands the agent the full diff of the current branch and supports questions like "what changed here that does not match the existing patterns". The second is insisting on small, semantically separate commits rather than one commit of nine hundred lines. Commit housekeeping is tedious by hand and agents are good at it, so the cost of asking is low.

Neither habit is a substitute for reading the diff. They make reading the diff possible.

There is a third habit that costs nothing and catches a specific class of mistake: asking the agent, in a read-only mode, what questions a reviewer would have about the change. The answers tend to surface the assumptions the agent made silently, which is exactly the material that never appears in a diff. An unstated assumption about which timezone a date is in, or which of two similar helper functions is the canonical one, reads as ordinary code until somebody asks.

What this costs

Prices are published per seat and are quoted exclusive of tax. The pricing page lists a free Hobby tier with limited agent requests, an Individual plan at $20 per month, and a Teams plan at $40 per user per month that adds centralized billing, shared context for cloud agents, and SSO. Every plan includes a set amount of model usage, with on-demand usage billed afterwards once that allowance is consumed.

The relevant point for supervision is not the monthly figure. It is that usage is metered, which means a long unattended run has a cost as well as a risk, and the two are worth watching on the same dashboard.

The part that happens outside the editor

Everything above concerns one workspace. The work rarely stays there.

A typical afternoon involves an agent running in a project folder, a reference document in a notes app, an export landing in Downloads, and a terminal in a fourth place to check what the export actually contains. The agent has no view of that arrangement. It sees the directory it was pointed at, which is exactly what makes the surrounding layout a human problem.

This is where a file manager with a built-in terminal changes the tempo rather than the capability. When the folder view and the shell are the same window, checking what an agent just wrote is one glance instead of a context switch, and the terminal is already in the right directory. Nothing about the agent changes. The overhead around it drops. What a tool like this covers is set out under features, and the cases where a dedicated editor remains the better answer are laid out honestly in the comparison.

The other half of the problem is time. An agent run that takes twenty minutes does not need supervision for twenty minutes, but it does need somebody to answer when it stops and asks a question. Reaching the Mac at home from an iPhone or iPad turns that from a blocked hour into a thirty-second reply.

What to change first

Put credentials and client data into .cursorignore before turning autonomy up, and read the mode names as descriptions rather than reassurances. Then fix the surrounding layout, because the folder view and the shell being in separate windows is what makes checking an agent's work feel expensive. Atriens exists for that second half.