Solo or co-op.Same walls.

An agent per project, all working at once.

Start an agent in each project folder. Each one runs in its own sandbox, with that project's policy, its own log and its own staged changes, so no agent sees another project's files.

fenzi ps lists every sandbox on the machine. fenzi connect takes you back into any of them, and fenzi diff in a folder shows that project's changes.

Sandboxes Several runs

Your MCP servers, keys and rules outlive the agent you picked.

Servers you use everywhere go in one file on the machine. Keys and tokens are stored once, outside every sandbox. The project's rules live in fenzi.yaml, committed, so everyone on the project runs with them.

Switch from one agent to another and all of it comes along. Nothing is configured twice.

Claude's account connectors go to Claude Code only. A local server's secret reaches Claude Code and Codex today; OpenCode and Grok refuse it until it is tested.

For every project, or one Model keys

Give it room to work. Know exactly how much.

The project copy is writable and the package indexes in the default policy are open, so edits, installs and test runs go through without you. Everything else stays shut until a line in fenzi.yaml opens it.

Claude Code starts in its manual mode and asks before each command. In auto mode it stops asking, and the policy still holds.

Default access Decision log

Let it rewrite the module. You decide what lands.

The agent works on a copy of the project. Your folder changes only when you apply, and apply refuses a file you edited in the meantime, so your own work is never overwritten.

The sandbox stays up after the agent exits. fenzi connect picks the session up where it stopped.

Workspace and changes

Requests, approvals and the log in one window.

Approve and add to fenzi.yaml shows the change and its policy check before it writes the host into the project's file.

On a machine signed in to a team, it forwards decisions and sends requests to the console. Every screen runs a fenzi command and shows the line it ran, so install the CLI first.

The Mac app

A new teammate is set up after one sign-in.

fenzi login signs the machine in, and the next fenzi run uses the team's policy, MCP servers included, with any agent the policy covers. Nobody copies a config by hand, and every laptop starts from the same revision.

Each developer stores their own model key on their own machine. It never reaches our cloud.

Enroll machines Many machines

Which laptops reached that host?

When an advisory names a host, URL or package path, paste it into Exposure. It shows which machines, sandboxes and programs reached it in the last 90 days, allowed or denied, and whether the policy in force still lists it. Nothing you paste is stored.

If the policy lists it, an admin drafts the policy without it, checks it with the prover and publishes. Running sandboxes drop the host at their next pass.

Exposure search

One fence around every policy.

An admin saves a team boundary, written like a policy file: the most any policy of the team may allow. A publish outside it is refused with the prover's example. An approval for a host and port it does not hold is refused too, in the console and on the machine.

Team boundary

A laptop drifts. Team writes it down.

A developer owns their laptop. For sandboxes Fenzi started, Team records one started without the team policy, a gateway that approves on its own, an approval made on the machine with no console review, and a machine that stopped reporting.

A record, not a lock.

Enforcement the laptop's owner cannot change is the License plan, on your cluster. It is planned and not built yet.

Drift