OpenBridge: a macOS local agent chat app that sandboxes file edits before they reach your disk

The problem OpenBridge targets: agent edits that land on your disk before you read them

Most coding agents write to the working directory as they go. You see the diff after the fact, in git, and undo is a manual operation. OpenBridge takes the opposite position. The README states that agent file edits happen in a sandbox first, that you can inspect every proposed change, accept only what you want, or discard the run without modifying your host filesystem. That is the product's central claim, and everything else in the repository exists to support it.

The audience is narrow and specific: macOS developers who want to run coding and productivity agents locally rather than through a hosted backend. The README describes the app as intentionally local-first, with provider credentials stored under the app's Application Support data and agent state kept on the machine. If you are comfortable sending your repository to a vendor's servers, the sandbox step buys you less. If you are not, it is the reason to look at this project at all.

SwiftUI shell, embedded React chat, vendored kwwk, and a Go sandbox VM

The architecture diagram in the README shows four layers. The macOS SwiftUI/AppKit shell owns agent sessions, settings, skills, memory and schedules, plus the AI provider registry and credential resolver. A WebKit bridge connects that shell to embedded React surfaces, which render the chat and preview views. Below that sits `kwwk`, described as a vendored agent SDK and coding-agent runtime. Underneath everything is `sandbox-vm`, a Go local VM runtime framework that drives Virtualization.framework Linux VMs.

The division of labour matters. OpenBridge does not implement the coding-agent loop itself. The README says the Swift layer owns product state and UI events while `kwwk` handles the coding-agent loop, and that OpenBridge supplies the system prompt, tool set, provider auth resolver and model selection. So the interesting engineering is in the boundary: what the host app hands to the runtime, and what the runtime is allowed to do with it.

The sandbox design is the part with the most detail. The README describes one shared VM host with separate sandbox environments per OpenBridge session, file edits in overlay-backed environments, and a workspace diff that surfaces in the chat as reviewable changes. You can accept selected files, accept all, or discard. That is a different model from running the agent in a container and mounting your project read-write. Here the host filesystem is the last step, not the first.

Building OpenBridge from a fresh worktree

There is no documented download of a signed app. The README's quickstart starts from a fresh worktree and builds everything locally, and the prerequisites list macOS with Apple Virtualization.framework support, Xcode and command line tools, Go 1.24+, Node.js with Corepack/Yarn, `make`, and `protoc` when changing VM RPC protobufs.

The first step initializes submodules, since `kwwk` is vendored rather than a normal dependency:

git submodule update --init --recursive

Next, build the embedded web assets. The `--immutable` flag makes the install fail rather than rewrite the lockfile:

cd web
yarn install --immutable
yarn build:embedded

Then build the sandbox VM framework, which is the Go side:

cd ../sandbox-vm
make framework

Finally, build the macOS app in an unsigned debug configuration and launch it. The README uses `pkill` first so an already-running instance does not block the new one:

cd ../macos
BUILD_CONFIGURATION=UnsignedDebug bash DevKit/Scripts/workspace_build_debug.sh
pkill -f '/OpenBridge.app/Contents/MacOS/OpenBridge' || true
open -na "$(pwd)/.build/DerivedData/Build/Products/UnsignedDebug/OpenBridge.app"

After launching, the first real use is connecting a provider. The README says provider settings live in the app and support OAuth or API-key credentials, that model selection is filtered to enabled providers, and that credentials are resolved at agent runtime before requests are forwarded to the real provider. So the sequence is: open settings, add a provider, complete OAuth or paste a key, then start a conversation. The README does not describe what the settings screen shows when a provider fails to authenticate, which is a gap you will hit if a key is wrong.

The repository also exposes a Makefile with aggregate targets. `make bootstrap` runs the submodule update and the web install; `make check` runs web lint, typecheck, test and build, then the sandbox Go tests. That is the faster path if you only want to know whether the tree is sound before opening Xcode.

Skills are files, not a plugin registry

The README calls skills local capability packages with a `SKILL.md` entry point. OpenBridge scans system, custom, imported and synced skills, advertises active skills to the agent, and expects the agent to read matching `SKILL.md` files only when a task needs them. The `What It Does` list gives the concrete location: skills load from `~/.openbridge/skills`, alongside bundled system skills, synced folders, imports and user-created skills.

This is a deliberate contrast with plugin systems that load everything at startup. Advertising skill names and deferring the file read keeps the initial context small, but it puts the burden on the model to decide when to open a file. If a skill's description is vague, the agent may never read it. The README does not document a way to force-load a skill, so skill authoring quality is effectively part of the runtime behaviour.

Computer Use, the notch task UI, and what the README leaves unspecified

Two features sit outside the coding loop. Computer Use lets an agent inspect and operate local macOS apps after explicit approval, and the README says the session automatically exits when the run completes or is cancelled. The notch task UI keeps multiple agent runs visible at once with live status for active, waiting and completed work.

The honest reading is that both are described in one paragraph each, with screenshots and no configuration detail. The README does not say which macOS apps Computer Use can drive, what the approval prompt contains, or how the automatic exit behaves if the app being driven is mid-operation. For a feature that hands an agent control of your desktop, that is thin. Treat Computer Use as the least specified part of the product and the one to test manually before relying on it.

The provider list is the opposite: long and explicit. It covers OpenAI, Anthropic, Google Gemini, Amazon Bedrock, Azure OpenAI, GitHub Copilot, DeepSeek, OpenRouter, xAI, Groq, Cerebras, Fireworks, Hugging Face, Mistral AI, Cloudflare AI Gateway, Cloudflare Workers AI, Vercel AI Gateway, Kimi, Moonshot AI, MiniMax, OpenCode, Xiaomi, Z.ai, and custom OpenAI-compatible endpoints. The README also states that OpenBridge can connect to third-party coding-agent subscriptions such as Codex and Claude Code. That breadth is a real advantage over tools that lock you to one vendor, though each route is only as reliable as the credential flow behind it.

Where OpenBridge is the wrong tool

The sandbox is a Linux VM managed through Apple Virtualization.framework. That makes macOS a hard requirement, not a preference. If your team develops on Linux or Windows, none of this transfers, and the repository offers no server component or remote mode to compensate.

The build story is the second constraint. The quickstart produces an `UnsignedDebug` app, and the README documents no signed or notarized distribution. An unsigned app that wants to operate other apps through Computer Use will run into macOS security prompts, and the README does not walk through granting those permissions. If you need something you can hand to a colleague who will not install Xcode, this is not it yet.

The third constraint is maintenance cadence. The last push was on 2026-06-10, and the most recent release, v0.1.7, was published on 2026-05-22. The repository is not archived, but roughly three months separate the last commit from today, and the version number is still 0.1.x. The README also notes that `make vm` is needed only when rebuilding local VM resources such as `kernel.bin`, which tells you the VM image is a build artifact you may need to regenerate rather than something fetched and pinned. Plan for the possibility that you are the one debugging the build.

How OpenBridge differs from Claude Code and Codex used directly

The closest comparison is running Claude Code or Codex on their own. Those tools are the agent runtime and the interface in one package, installed through their own channels, and they write to your working directory as part of normal operation. OpenBridge does not replace them so much as wrap them: the README says it can connect to third-party coding-agent subscriptions such as Codex and Claude Code, so your existing subscription can drive an OpenBridge session.

The difference in approach is the review boundary. With the vendor CLIs, the safety mechanism is git and your own discipline. With OpenBridge, the mechanism is the sandbox VM: overlay-backed environments per session, a diff surfaced in chat, and an accept or discard decision before the host filesystem changes. You give up the vendor's own UI and update cadence, and you take on a build toolchain, in exchange for that checkpoint.

That trade only makes sense if the checkpoint is what you actually want. If you are comfortable reviewing diffs in git after the fact, adding a VM layer and a Go build step is overhead with no matching benefit.

Editorial conclusion

Adopt OpenBridge if you develop on macOS, already pay for a coding-agent subscription or API key, and want the file-edit review step before anything touches your host filesystem. Skip it if you need a signed, stable build, if your team works on Linux or Windows, or if you want a hosted service that manages credentials for you. Before committing, verify that your Mac supports Apple Virtualization.framework, that your provider is in the supported list, and that you can complete the four-step build from a fresh worktree, since the README documents no release download path.

Frequently asked questions

Official sources

1. AFK-surf/OpenBridge on GitHub
2. License: MIT
3. Project website
4. README
5. Releases