What Happens to Your Keys Inside a Coding Agent Sandbox

A sandbox and a key solve two different problems

A coding agent sandbox is an operating system boundary. It decides which folders a process can write to, which paths it can read, and sometimes which hosts it can reach on the network.

None of that is about secrets. A key is just a string. If that string sits inside the sandbox, in an environment variable or a file, the sandboxed process can read it and use it exactly as if there were no sandbox at all. The boundary was never built to look at the content of what it lets a process read.

This is why sandboxing an agent and protecting its keys are two separate claims. The first stops the agent writing outside your project folder. The second needs you to think about where the key lives, not just where the agent runs.

• A sandbox restricts files, processes and sometimes the network.
• A sandbox does not know or care that one of the files it allows a process to read happens to be a secret.
• Protecting a key and confining an agent are two separate jobs, and most tools only do one of them.

What each sandbox type actually does to a key already inside it

Claude Code and Codex both ship a sandbox built on macOS Seatbelt. Turn it on and shell commands are confined to the project folder and a temp directory, with network access going through an allowed list. A key sitting in that project folder's .env file is still fully readable by every command that runs inside the boundary, because the boundary was drawn around files and hosts, not around the key itself.

A virtual machine or container, such as Apple's own container tool or Docker Desktop, moves the agent to its own filesystem. If you mount your project folder into it, whatever secrets are in that folder cross the mount and are just as readable inside as outside. The isolation protects your host from the container, not the key from the agent.

A tool that locks an agent to chosen folders, which is what Forkbench's folder lock does on a Mac, keeps the agent out of folders you never granted it, such as other repositories or your SSH directory. A key you put inside the locked folder is still readable by anything running inside it, for the same reason as the other two.

• Seatbelt-based sandboxes in Claude Code and Codex confine files and network, and leave an in-folder key fully readable.
• VMs and containers move the boundary, but a mounted secret crosses the mount.
• A folder lock keeps an agent out of folders it was never granted, not out of secrets inside the ones it has.

The part that actually protects a key: where it lives, not where the agent runs

The fix is the same across every sandbox type above. Stop putting the key in a file the sandboxed process can open, and hand it to the one command that needs it at the moment that command runs. The macOS Keychain, a secrets manager, or Forkbench's Vault all do this by releasing a value to a process just once instead of leaving it sitting in a file.

This is also where a search like sandbox ai coding agent vault is pointing. There is no single product that is both a sandbox and a vault. You pair one of the sandbox options above with a separate tool that keeps the secret itself out of the sandbox's own files, because the two jobs do not overlap.

If your team has outgrown a single developer's keychain, the next step up is a shared secrets platform. HashiCorp Vault is the name people usually reach for, and it is worth knowing before you build on it that Vault has shipped under the Business Source License rather than an open source license since version 1.15. Its open source fork, OpenBao, is the alternative if that license matters to you.

• Keep the key out of any file the sandboxed process can open.
• Release it to one command at the moment that command runs.
• A sandbox and a vault are two different tools working together, never one product.

GitHub tokens inside a sandbox: scope them to match the boundary

A coding agent sandbox that needs to push code or open a pull request needs a GitHub credential, and the sandbox around it does nothing to limit what that credential can do once the agent has it. Scope it instead. GitHub's fine-grained personal access tokens can be scoped to one or a few repositories, and as of 2026 their expiration field accepts anywhere from 1 day up to 366 days, or no expiration at all.

Treat that 366-day figure as a ceiling, not a target. A token that lives inside a sandbox rebuilt every session only needs to survive one session. A token inside a persistent sandbox you reuse every day deserves a real calendar reminder to rotate it, because nothing else expires it for you if you pick no expiration.

This holds whether the sandbox is a Seatbelt profile, a container, or a folder lock. The sandbox decides whether the agent can wander into other repositories on disk. The token decides what the agent can do to GitHub once it is running. A sandbox setup needs both answered, not just one.

• Fine-grained personal access tokens scope to specific repositories, unlike a classic token that reaches everything you own.
• Expiration today runs 1 to 366 days, or none. Picking none moves the whole job of rotation onto you.
• Match the token's lifetime to the sandbox's lifetime: short for a sandbox rebuilt per session, scheduled for one you keep around.

Where Pi and other sandbox-free agents change the picture

Pi, the open source coding agent from earendil-works, makes the gap explicit instead of hiding it. Its own documentation states that Pi ships with no built-in permission system for filesystem, process, network or credential access, and that by default it runs with the full permissions of whoever launched it. Pi's own recommendation is to add a boundary yourself, through its Gondolin extension, plain Docker, or OpenShell.

Running Pi with no added sandbox means a key in your shell environment is available to it exactly as it would be to you. That is not necessarily wrong for a short, trusted task. It is the wrong setup for a key you would not want exposed to a bug in Pi's own tool calling.

If part of what brought you here is Pi on Windows: Forkbench does not run there today. It is in development, with no date set. Windows itself has its own built-in credential store, separate from a plain environment variable, which our dedicated Windows guide covers in detail.

• Pi has no sandbox and no permission system out of the box, by its own documentation.
• Add one yourself, through Gondolin, Docker, or OpenShell, before trusting it with a real key.
• Forkbench is Mac only today. Windows and Linux are in development, with no date.

How Forkbench handles keys inside its own sandbox

Forkbench locks a Thread to its folders using the macOS kernel sandbox, and its Vault keeps keys in your Keychain so a command can use one by name without the value ever reaching the prompt, the command line, or the transcript.

State the limits plainly, because they matter. The folder lock is opt-in and does not restrict the network, so a locked agent that can read an allowed file can still send what it read somewhere else. An unpinned Vault key is still readable by the program that was run with it, which is why pinning a key to the one command that needs it matters more than just putting it in the Vault. Without the lock at all, an agent has the same filesystem access you do.

That makes Forkbench one half of the setup described above: the sandbox and the vault in the same app, on one Mac, for agents you run in its terminals. It does not replace scoping your GitHub token or deciding what a cloud sandbox is allowed to mount.

• Folder lock: opt-in, enforced by the macOS kernel sandbox, and it does not restrict the network.
• Vault: keys stay in the Keychain, used by name, never shown to the agent.
• An unpinned key is still readable by the program it was run with. Pin it.

A key review you can run today

This is the practical version of reviewing your sandbox's keys, something worth doing on a schedule rather than once.

• List every key your current sandbox setup can reach, including ones in a .env file you forgot about.
• Move each one out of a plain file and into the Keychain, a vault, or a secrets manager.
• Scope any GitHub token to the repositories it actually needs, not your whole account.
• Set an expiration on every token that supports one, and put a rotation date on your calendar for the ones that do not.
• Match a token's lifetime to how long the sandbox around it actually lives.
• Pin a Vault key to the command that needs it instead of leaving it generally available.