How to Build a Local, Safe Framework for Vibe Coding

What 'local' actually has to mean before you build anything

Claude Code and Codex both run their shell commands and file edits on your machine. That part is genuinely local. The model call, the part that actually writes the code, is not: every request travels to Anthropic's or OpenAI's API over the network, every time, with no offline mode for the model itself.

If a search for claude offline or claude private brought you here, this is the honest answer. Claude Code stores your API keys in the macOS Keychain and keeps your session data under Anthropic's stated retention limits, which is a privacy posture, not an offline one. For a setup that makes no network call at all, the model itself has to be something you run yourself, such as one of Mistral's open-weight model families, Ministral and Mistral Small, released under an Apache 2.0 license, through a runtime like Ollama.

Decide which one you actually need before you build. A private, vendor-hosted agent is a different project from a fully local, open-weight one, and the two need different pieces under them.

• Claude Code and Codex: local shell and files, but every model call leaves your machine.
• Fully offline: the model has to be one you run yourself, not a hosted API.
• Mistral's Ministral and Mistral Small families are open weight, under an Apache 2.0 license, and runnable locally.

Step one: pick an agent with its own approval gate, and know what it skips

Start with an agent that asks before it does something destructive. Claude Code and GitHub Copilot CLI both prompt for approval by default before using a tool that could modify or execute files, with an option to approve a tool for the rest of the session or reject it. Codex CLI gives you an explicit choice between read-only, workspace-write, and full-access modes instead of one blanket setting.

Know what the approval gate does not cover. In Claude Code, the Bash sandbox that confines shell commands to the project folder is off by default and has to be turned on with /sandbox. Without it, an approved command still has your full filesystem access. Read the actual scope of your agent's own protections before assuming they cover everything.

• Claude Code and Copilot CLI: approval prompts on by default, with a flag to bypass all of them if you choose to.
• Codex CLI: explicit read-only, workspace-write, or full-access modes.
• Turning an agent's own sandbox on is a separate step from accepting its approval prompts.

Step two: wrap the agent in a real OS boundary, with a worked example

The approval gate is a request the agent can still be wrong about. A real boundary is enforced by the operating system. On a Mac, sandbox-exec, the command line tool for applying a Seatbelt profile, lets you confine any process, including one with no sandbox of its own.

A minimal profile looks like this: deny everything by default, allow reads of your toolchain and system paths, allow writes only inside the project folder, and allow network access only to the hosts you actually need. You launch the agent through it with a command such as sandbox-exec -f my-profile.sb claude, and every process the agent starts inherits the same limits.

One thing worth knowing: Apple's own sandbox-exec man page marks the tool as deprecated, a label it has carried for years. It still works on current macOS releases, and it is what Claude Code's and Codex's own sandboxes are built on, but it is not a tool Apple promises to keep forever. Check man sandbox-exec on your own machine before building on it long term.

If you would rather not hand-write a profile, a container or VM is the other real boundary, and it is covered in detail in our guide to sandboxing coding agents on macOS, so it is not repeated here.

• sandbox-exec: deny by default, allow the project folder for writes, allow only the hosts you need for network.
• The man page marks sandbox-exec deprecated. It still works on current macOS, with no promise it always will.
• A container or VM is the alternative boundary when you would rather not write a profile yourself.

Step three: take the keys out of the loop

Whatever boundary you picked in step two, do not put a real API key inside it. A .env file in the project folder is readable by anything that boundary allows to read the project, so the boundary protects everything except the thing you actually cared about.

On a Mac, the free option is the Keychain itself, read from the command line with the security tool. Forkbench's Vault does the same job with less setup: it keeps keys in the Keychain and lets a command use one by name, so the value never reaches the prompt or the transcript.

Either way, the habit is the same. The key lives outside the sandboxed folder, and a command gets it only at the moment that command runs.

• Free option: the macOS Keychain, read with the security command line tool.
• Less setup: Forkbench's Vault, which hands a named secret to a command without showing the value.
• Never put a real key inside the folder your sandbox allows the agent to read.

Step four: give the agent its own branch, not your main one

A git worktree gives an agent its own working copy on its own branch, checked out from the same repository, so a bad change does not sit on the branch you are actually shipping from. This matters more for a local setup than a cloud one, because there is no separate review environment catching the mistake for you first.

Run each agent in its own worktree, review the diff before merging, and you get most of the safety of a full review process without needing to build one.

• One worktree per agent, on its own branch.
• Review the diff before it reaches your main branch, every time.

Where this changes if your work touches a cloud platform

If part of the job is an agent working against Salesforce, or any other cloud platform, that piece is not local no matter how the rest of your setup is built. Scope that platform's credential the same way you would scope a GitHub token: narrowly, to the smallest role the task needs, and kept out of the project folder like every other key.

If you are documenting this setup for a team rather than just yourself, write the four steps down as the team's standard, not as one person's habit. A framework that only lives in one person's head is not a framework yet.

• A cloud platform credential, Salesforce or otherwise, needs the same narrow scoping as any other key.
• Write the steps down once you are setting this up for more than yourself.

How Forkbench fits into a build like this, and where it still falls short

Forkbench covers two of the four pieces above on a Mac. It locks a Thread to its folders with the macOS kernel sandbox, and its Vault keeps keys in the Keychain and hands them to a command by name. It works with any agent you run in its terminals, including Pi or another agent with no sandbox of its own.

It does not replace the other two pieces. You still pick an agent with its own approval gate, and you still manage your own git worktrees and branches. The folder lock is also opt-in and does not restrict the network, so a locked agent can still send out whatever it was allowed to read, and an unpinned Vault key is still readable by the program it was run with. Windows and Linux support is in development, with no date.

• Forkbench covers the OS boundary and the vault, not the approval gate or your git workflow.
• Folder lock: opt-in, and it does not restrict the network.
• Mac only today. Windows and Linux are in development, with no date.

A build order that holds up

Build in this order, not all at once, and test each piece before adding the next one.

• Pick an agent with its own approval gate and understand what it actually covers.
• Wrap it in a Seatbelt profile, a container, or a folder lock, and test the boundary by trying to write outside it.
• Move every real key into the Keychain or a vault, and delete the plaintext copies.
• Give the agent its own git worktree and branch, and review every diff before merging.
• Scope any cloud platform credential, such as a Salesforce token, as narrowly as the task allows.
• Write the steps down if more than one person will run this setup.