What can AI coding agents access on your machine?

The short answer

An AI coding agent such as Claude Code, OpenAI Codex or Cursor runs on your machine as your user account. Anything that account can read, run or reach over the network is, in principle, within the agent’s reach. What actually stops it is a combination of approval prompts, an optional or default sandbox, and the settings you or your repository have chosen.

Those controls are real and improving quickly, but they differ between tools, several of them are off or loosened by default, and every vendor describes them as guardrails rather than a hard boundary. It is worth knowing what is on the other side of them.

What is within reach

On a typical developer laptop, a process running as you can usually get to:

• Credentials on disk. SSH keys in ~/.ssh, cloud credentials such as ~/.aws/credentials, registry tokens in ~/.npmrc, CLI login state for GitHub, cloud providers and databases, and .env files in every project you have checked out.
• Other projects. Source code, notes and configuration outside the repository the agent was started in.
• The network. Any domain your machine can reach, which includes paste sites, file sharing services and arbitrary webhooks.
• Tools with side effects. git push, package managers, cloud CLIs, database clients and kubectl, often already logged in.
• Places that persist. Shell profiles, login items, git hooks, and the agent’s own configuration and instruction files, which shape what the next session is allowed to do.

None of this requires a malicious agent. The usual paths are mundane: a command that does more than intended, a dependency install that runs a script, or instructions hidden in a web page, an issue or a README that the agent reads and follows (prompt injection). All three vendors warn about prompt injection in their own security documentation.

How Claude Code, Codex and Cursor limit it

This table summarises what each tool’s documentation said on November 10, 2026. Defaults change between releases, so check your own version and settings.

Two details surprise people. First, sandboxes mostly restrict writes and network, not reads: in Claude Code’s sandbox and in Cursor’s default setting, a command can still read files such as ~/.ssh unless you deny that explicitly. Second, the safest-sounding default is not always the one you are running, because a teammate, a shell alias or a CI script may start the agent with approvals turned off.

Where the limits stop

• Approved commands run with your full rights. Claude Code’s security page notes that a Bash command you approve can still write anywhere your user account can. Approving npm install approves every install script it pulls in.
• Automatic reviewers are models too. Auto modes reduce prompt fatigue, but a classifier can be wrong, and vendors call these modes best-effort.
• Hooks are not a security boundary. Claude Code and Cursor document that hooks fail open on timeouts or errors by default, and Claude Code recommends the permission system, not hooks, for hard allow or deny rules.
• Repositories carry configuration. Project settings, MCP server definitions, hooks and instruction files arrive with a git clone. Tools increasingly wait for you to trust a folder before applying them, but not every setting is gated the same way. The permissions guide goes through what a repository can change.
• Nobody is looking afterwards. Prompts protect the moment of approval. Without a record of what the session actually did, a credential read followed by an upload looks like any other busy afternoon.

How to reduce what an agent can reach

1. Turn the sandbox on where it is optional, and deny reads of credential paths (Claude Code supports filesystem.denyRead and blocking reads outside the working directory; Cursor has a workspace-only read setting).
2. Keep network access closed by default and allow only the domains a task needs.
3. Use skip-everything modes only in a disposable container or VM with no personal credentials mounted, as the vendors themselves recommend.
4. Use short-lived, narrowly scoped credentials on development machines, so a leaked token is worth less.
5. Review agent configuration like code. Settings files, MCP servers and instruction files in a pull request deserve the same attention as a new dependency.
6. Keep a record of sessions, so you can answer “what did the agent touch?” after the fact. The monitoring guide compares the options.

Where vetkit fits

vetkit looks at this from two sides. The repository audit’s AI code risks checks flag committed agent configuration that widens access: approvals turned off, settings that pre-approve arbitrary shell or network commands, hooks that download and run scripts, unpinned or remotely fetched MCP servers, credentials in MCP configuration and hidden text in agent instruction files.

Agent Watch, a desktop app for team machines, records what AI coding agents actually do during a session: credential reads, new network destinations, destructive commands, writes outside the project and changes to their own settings. It observes and reports; it does not block actions, and it uploads alerts and session summaries rather than file contents or prompts. See the Agent Watch documentation for availability and the privacy model.

Sources

We read the statements about each tool from its own documentation on November 10, 2026. Treat each vendor’s pages as the final word:

• Claude Code: security, permissions and sandboxing
• OpenAI Codex: agent approvals and security
• Cursor: agent security and run modes

Product names are trademarks of their respective owners. vetkit is not affiliated with, endorsed by or sponsored by them. Spotted something out of date? Email contact@vetkit.dev and we will correct it.