Inspection before move‑in.

An AI agent sandbox is the boundary around the coding agent: the directories it can write, the hosts it can call, and the keys it cannot see. The rules live outside the model, so a bad prompt cannot move them. The floor plan is on how it works.

No. The limit sits in the operating system, outside the model. A prompt can be rewritten by the next prompt; a sandbox cannot.

The agent will open the wrong file, call the wrong host, and follow a bad instruction if that instruction is in the context window. A prompt does not stop it. The sandbox does, and the log names the process that called the host.

Pick the directories, pick the hosts, and keep the keys outside the sandbox. A person approves any host the policy does not already allow. The agent does not approve itself.

Install Fenzi and run fenzi run claude with an Anthropic API key. You see a deny, approve one host, and take the changes back into your repo. The steps are how to sandbox Claude Code.

Yes: fenzi run codex starts it with an OpenAI API key that stays on your machine. This Codex sandbox is Fenzi starting the agent, not a setting inside Codex.

Claude Code, Codex, OpenCode and Grok run today; Cursor CLI and Muse are next. Each runs with an API key, and signing in with a Claude, ChatGPT or Grok subscription is not supported yet. A desktop IDE that opens its own terminal on the host is not covered, and custom agents are not supported yet.

OpenShell, the open-source sandbox runtime Fenzi runs on. It decides what the agent process can read, write, run and call. We pin a version and keep the default tight.

Then we have a software bug, and we say so, even when the fix belongs upstream in the sandbox runtime. The runtime is open source, so you can read it, and we move our pinned version when a fix ships. The default stays tight: workspace open, secrets shut.

Yes: on a laptop the developer administers, nothing stops them running an agent outside Fenzi, and Team does not see that run. Enforcing against the machine's owner needs a gateway they do not administer: License, on a cluster, which is planned and not built yet. The security model says what a laptop can and cannot enforce.

Yes. An admin or reviewer can approve a request their own agent filed, and the console records who approved every request. There is no separation-of-duties rule yet; who approves where is on requests and approvals.

Your code and your keys never reach our cloud. The model vendor still receives what the agent sends it: the files it read, command output and your instructions, as it does without Fenzi.

On Team, policy revisions, decision records, pending requests and a report from each machine; the Team plan lists every field. Not your source, not your terminal output, not the agent's conversation, not your keys. License, which is planned, runs the control plane in your VPC, so none of it reaches us.

Each team has its own Ed25519 signing key, which our control plane generates, keeps encrypted, and uses to sign each revision you publish. Machines check every revision against the public key they received at sign-in, refuse a bad signature or a lower number, and run the prover before a sandbox starts. Someone who took over our control plane could sign a revision, and the prover on the machine still holds it to the boundary in the same bundle; see publish and revisions.

A host that is not in the policy looks like a failed DNS lookup or a refused connection to the agent, and the log records why. A method or path the policy does not allow on a listed host gets an HTTP 403 that names the rule. A blocked file shows as Permission denied in the agent's terminal and is not in the log.

Hosts change while the agent runs: an approved host opens within seconds, with no restart. Files and processes are set when the sandbox starts, so a change there means a new sandbox. We do not pretend otherwise.

The agent keeps working on the task. It loses paths and hosts you did not grant. If normal work needs a host, put that host on the list.

Linux and Apple Silicon Macs, with no special hardware. On Windows it runs through WSL 2, which upstream marks experimental. Install and platforms lists the container runtimes each one uses.

Install without prompts with curl -fsSL https://fenzi.dev/install.sh | FENZI_NO_SETUP=1 sh, which installs the command and stops. Each machine then signs in once with fenzi login, and a team member approves the code it prints in the browser. There is no unattended sign-in, packaged service or MDM package yet; enroll machines has the steps.

For support, open an issue on github.com/fenzi-inc/fenzi; troubleshooting covers the common failures first. Report a security issue, such as a way out of the sandbox, privately to security@fenzi.dev, and do not post details in public.

Because they are going to run it. The useful move is to bound the process.

No. That is why the rules are not inside it.

You can audit the sandbox and the CLI, which is the code on your machine. The control plane is how a company shares one policy and keeps the log. That is the part we sell.