# Give your coding agent its own machine

> What a coding agent can reach on your main computer, what Claude Code and Codex permission modes and sandboxes cover, and why a separate VM is cleaner.

*2026-10-12 · agents, security, claude-code, codex*

When you let a coding agent run commands, it runs them as you. Every file your user account can open, its commands can open too. That includes the repository you asked it to work on, and also every other repository on the disk, your SSH keys, your cloud credentials and the tokens in your shell environment.

Most of the time this is fine, because the agent does what you asked. This post is about the rest of the time, the options Claude Code and Codex give you on your own computer, and why we think the cleanest answer is a machine of its own.

## What an agent can reach on your laptop

Look at your home folder the way a shell command sees it:

- **Files:** client code, side projects, documents, downloads. Nothing marks one repository as the only one the agent should touch.
- **Keys:** `~/.ssh` holds the keys that open your servers and push to your Git host.
- **Credentials:** files such as `~/.aws/credentials`, plus any API tokens exported in your shell profile.
- **Signed-in tools:** if `gh` or a cloud CLI is logged in, every command the agent runs can use that login.

None of this needs a bug to go wrong. A mistyped path in an `rm`, a `git push --force` to the wrong remote, or a cleanup script run one folder too high is enough.

## Prompt injection

The other risk comes from what the agent reads. [Claude Code's security guide](https://code.claude.com/docs/en/security) describes prompt injection as text written to override or manipulate an assistant's instructions. For a coding agent, that text can arrive in a README, an issue comment, a web page it fetches for documentation, a package's install notes or the output of a tool.

Picture a comment in a dependency that tells any AI agent reading it to post the contents of `.env` to some URL. A careful agent ignores it. Still, the instruction now sits in the same context as your request, and the agent can run `curl`. Anthropic's advice for untrusted content includes reviewing commands before you approve them and running scripts and tool calls in virtual machines, especially when they talk to outside services.

## What permission modes do

Both agents can ask before they act.

Claude Code has several [permission modes](https://code.claude.com/docs/en/permission-modes). Manual asks before edits and most commands. `acceptEdits` approves file edits and common file commands inside your working directory. In auto mode, which recent versions use as the starting mode for interactive sessions, a separate classifier model reviews each action before it runs; the docs say plainly that this cuts prompts without guaranteeing safety. `bypassPermissions`, also started with `--dangerously-skip-permissions`, skips the prompts entirely. The docs reserve it for isolated containers and VMs, and note that it offers no protection against prompt injection.

Codex pairs a [sandbox mode with an approval policy](https://learn.chatgpt.com/docs/sandboxing). `read-only` lets it look but not change anything without asking. `workspace-write`, its low-friction mode for local work, lets it edit files and run routine commands inside the workspace. `danger-full-access` removes the sandbox. The [Codex CLI reference](https://learn.chatgpt.com/docs/developer-commands?surface=cli) says to use `--yolo`, which skips both approvals and the sandbox, only inside an environment hardened from the outside.

Prompts protect you while you read them. Long tasks produce a lot of them, and each one stops the agent until you answer.

## What the built-in sandboxes do

Claude Code's [sandbox](https://code.claude.com/docs/en/sandboxing) wraps shell commands in a boundary the operating system enforces: Seatbelt on macOS, bubblewrap on Linux and WSL2. Turn it on with `/sandbox`. By default, sandboxed commands can write only to the working directory, a temp folder and directories you add, and they reach the network only through a proxy whose allowlist starts empty. Codex uses the same mechanisms on macOS and Linux for its own sandbox.

Read the defaults closely, though. The Claude Code sandbox covers shell commands, not its file tools, MCP servers or hooks. Reads are allowed across most of the machine by default, including `~/.ssh` and `~/.aws/credentials`, and commands inherit Claude Code's environment variables, secrets included. You can deny those reads in settings. The catch is that you have to, on the computer that holds everything you care about, and get it right every time.

## Why a separate machine is the cleanest boundary

Claude Code's [guide to sandbox environments](https://code.claude.com/docs/en/sandbox-environments) compares the options, from the per-command sandbox to containers to full virtual machines. It calls a dedicated VM the strongest separation, since it has its own kernel, and suggests one for working on a repository you don't trust.

The reason is easy to see. A fresh VM has nothing of yours on it: no other repositories, no SSH keys, no browser profile, no signed-in tools. The agent can reach what you copy there and nothing else. You can even give it sudo, because the worst case is a machine you delete and start again.

A VM has limits too. If it can reach the internet, anything the agent can read on it can leave, and the same guide says so about every approach that allows network access. Isolation also doesn't change what goes to the model: files the agent reads are still sent to the model provider. So:

- Put only what the task needs on the machine.
- Give it credentials scoped to that one job, and revoke them when it's done.
- Keep your personal tokens and keys off it.

## How shedix sets this up

Each shedix machine is its own VM on Google Cloud in Iowa: Ubuntu 24.04, a user called `dev` with passwordless sudo, Docker, and Claude Code and Codex installed. Machines sit on an isolated network, so they can't reach each other. SSH comes in from anywhere, with keys only. Outbound internet is open, so packages install and APIs work, and the caveat about data leaving applies.

You sign in to Claude Code in the machine's own terminal, through Claude Code's own flow. On Linux, Claude Code keeps that login in `~/.claude/.credentials.json`, on the machine rather than your laptop. shedix never sees or stores it.

Agents that drive shedix from your laptop use a token. A token can do anything you can do with your machines, stops working a year after its last use, has every call logged on your profile, and can be revoked at any time.

Running Claude Code with fewer prompts on a machine like this puts that machine at risk, not your laptop. Claude Code refuses `bypassPermissions` when it runs as root outside a sandbox it recognizes, and `dev` isn't root. Its docs also suggest no internet access for that mode, so weigh the open outbound connection before you skip every prompt. Auto mode is the middle ground.

Our [security page](/security) lists what shedix isolates and what it doesn't. [Off your laptop](/use-cases/off-your-laptop) shows the setup for everyday work, and [Real Ubuntu](/use-cases/real-ubuntu) is the version for experiments you'd rather keep away from your own computer.