Guide

Claude Code security: why your agent does not belong on your laptop

Claude Code is a powerful tool: it reads your code, runs commands and builds features largely on its own. That is exactly what makes it risky when it runs on your own laptop. This guide shows what an agent can reach there, which safeguards Claude Code comes with and how to isolate your agent properly.

What your agent sees on your laptop

Claude Code runs with your user permissions. Anything you can do in a terminal, the agent can in principle do as well, as soon as you allow it or turn off the permission prompts. That includes:

  • your SSH directory ~/.ssh with private keys for servers and Git,
  • .env files with API keys and database passwords,
  • cloud credentials such as ~/.aws or ~/.config/gcloud,
  • browser profiles, downloads and documents,
  • the folders of all your other projects and clients.

An agent has no bad intentions. The risk comes from accidents: a misunderstood instruction, a delete command in the wrong directory or a crafted file in someone else’s repository that tricks the agent into doing something (prompt injection). The more an agent is allowed to do on its own, the greater the potential damage.

Built-in safeguards in Claude Code

By default, Claude Code asks before it changes files or runs commands. Permission modes and allow lists let you decide what is allowed without asking.

The /sandbox command also turns on a sandbox. The agent’s commands may then write only to approved directories and reach only approved network destinations. The sandbox is available on macOS, Linux and WSL2, but not on native Windows.

For long tasks it is tempting to turn off all prompts with --dangerously-skip-permissions. The name is meant seriously: on your work machine, it gives the agent free rein over everything you can reach. Only use this flag in an environment where there is nothing to lose.

Three ways to isolate your agent

1. Keep permissions tight. Work in the default mode, allow only the commands you really need and use the sandbox. This costs nothing but means a lot of prompts. And the agent only works while your laptop is running.

2. A local VM or container. You run the agent in a separate environment on your computer, for example in a dev container or with OrbStack on the Mac:

orb create --isolated ubuntu agent

This Linux machine has no access to your Mac files. The downside: your laptop has to stay on, and the agent shares CPU and memory with you.

3. A separate Linux machine on a server. The agent runs on a server that holds only what it needs for its task. There you can give it more freedom, because in the worst case you reset the machine. It also keeps working when you close your laptop. The guide Keep Claude Code running with your laptop closed shows how.

Checklist for every agent environment

  • Separate user: the agent does not run under your main account.
  • No production keys: no access to live databases, payment providers or client servers.
  • Only the repository it needs: clone the project into the environment instead of sharing your entire projects folder.
  • Git as a safety net: let the agent work on its own branch and review its changes in a pull request.
  • Snapshots or backups: after a mistake, you are back to a clean state within minutes.
  • Credentials with minimal permissions: a deploy key for exactly one repository instead of your personal SSH key, API tokens with a narrow scope.

Summary

An agent is only as secure as the environment it runs in. On your laptop, keep it on a short leash. Give it more freedom only on an isolated machine that you can reset at any time. That is exactly what we built the euhost Box for. The principle works with any Linux machine, though.