A local desktop meta-harness for Claude Code, Codex, OpenCode, and other coding agents — one workspace for projects, dev services, ports, terminals, diffs, review, and an orchestrator agent that delegates to sub-agents.
Install · Why Warpforge? · Agents · Orchestrator · Projects & runtime · Build from source
Warpforge is the operating layer around your coding agents. Agent conversations, project runtime, isolated worktrees, live services, and human review live in one place — so running several agents does not turn into managing several terminals.
It does not replace Claude Code, Codex, or OpenCode; those tools still do the coding. Warpforge gives them shared project context, parallel execution, runtime visibility, and a reviewable path from prompt to commit. Everything runs on your machine: there is no separate Warpforge account or API key, and your existing agent authentication stays with the underlying CLI.
- Open the latest Warpforge release.
- Download
Warpforge_<version>_aarch64.dmg. - Open the DMG and drag Warpforge into Applications.
- Launch it and select the coding agents you want enabled.
The build is signed with a Developer ID certificate and notarized by Apple, so it opens without Gatekeeper workarounds. It needs macOS 11 or newer on an Apple Silicon Mac and ships its own daemon — no Rust toolchain or source checkout required.
Updates are built in and signed. Warpforge checks the release feed shortly after its daemon comes up, and on demand from the app. Downloading and installing are always explicit actions — nothing installs in the background. An update carries both the desktop UI and its matching daemon, verifies an exact version and protocol handshake, and is refused with a clear list of blockers while agent tasks or runtime transitions are still active rather than interrupting work.
Note
macOS on Apple Silicon is the validated desktop target. Windows and Linux packaging exists as an opt-in release preview, but those platforms have not been tested on real machines and are not claimed as publicly supported.
Warpforge adds no model account or API-key layer. It looks for supported agent binaries on your PATH, speaks the Agent Client Protocol (ACP) to them over stdio, and stores your enabled-agent selection locally. If Claude Code, Codex, or OpenCode is already installed and authenticated, that setup is reused as-is — the CLI keeps owning authentication, model access, and the coding itself.
AI-assisted development becomes a coordination problem long before it becomes a model problem:
- one agent is editing while another waits for permission;
- a third needs the app server and its real URL;
- logs are hidden in terminal tabs;
- two projects both assume port
3000; - completed work is scattered across chats, worktrees, and diffs.
Warpforge turns that sprawl into one visible workflow:
- Mission Control for active work. Running, blocked, interrupted, and review-ready sessions across every project, with live conversation previews — no hunting through terminals.
- The environment travels with the task. Agents receive live service URLs, resolved ports, files, and project context instead of guessing how to run the app.
- Parallel work without checkout collisions. A task can run in its own git worktree while staying attached to the same project.
- Human control at the moments that matter. Permission requests, commands, tool calls, changed files, and diffs stay visible before work moves forward.
- From agent output to a reviewed branch. Unified or split diffs, hunk-level accept/reject, inline edits, commit, update, push, and pull request from the same workspace.
- A lead agent when the task outgrows one session. An orchestrator delegates bounded work to sub-agents, and every child task stays visible.
That combination is what makes Warpforge a hybrid meta-harness: part agent orchestrator, part project runtime, part review surface.
Warpforge detects agents as globally installed binaries and spawns them directly — no npx at session start, so the first prompt is never blocked on a package download.
| Agent | Binary | Default ACP command | Install integration |
|---|---|---|---|
| Claude Code | claude-agent-acp |
claude-agent-acp --acp |
npm install -g @agentclientprotocol/claude-agent-acp |
| Codex | codex-acp |
codex-acp |
npm install -g @agentclientprotocol/codex-acp |
| OpenCode | opencode |
opencode acp |
npm install -g opencode-ai |
| Qwen Code | qwen |
qwen --acp |
npm install -g @qwen-code/qwen-code |
| Goose | goose |
goose acp |
brew install block-goose-cli |
Claude Code and Codex reach ACP through small adapter binaries. Warpforge shows whether each agent is present, which version is installed, and whether a newer one exists — and installs or updates it in one click from the agent panel. Any other ACP-compatible agent can be added with a custom command, globally or per project through agentTemplates.
Agent capabilities vary. Image input, session resume, slash commands, model selection, and permission semantics are negotiated with each ACP implementation.
A regular Warpforge task is one conversation with one coding agent. Enable Orchestrator and that agent becomes a lead with three Warpforge tools:
spawn_agent— dispatch a bounded task to Claude Code, Codex, OpenCode, or any configured harness, and return immediately;message_agent— send a follow-up into an existing sub-agent's session, in context;read_inbox— drain finished results and decide what happens next.
Orchestration stays inside a real conversation you can keep steering while child agents work. Sub-agents appear as normal Warpforge tasks linked to their parent, so you can see which harness is running, what it changed, and where human attention is needed instead of sending work into a black box. The daemon also contains an experimental planner → worker → reviewer pipeline; both paths are under active development.
Register a project once. In Projects → Add Project, pick a folder. Warpforge keeps a local registry and reads or creates .warpforge.yaml — optionally prefilled from a package.json dev script or a Docker Compose file, or generated interactively by an agent in the bootstrap wizard. Removing a project only unregisters it; the directory and its config stay untouched.
Bring the real runtime online. Services start in dependency order with captured logs, interpolated environment variables, and readiness detection. Kubernetes port-forwards run alongside local processes and are watched and retried with backoff when they drop. Each project also has interactive terminals inside the app, so a quick git log or one-off script does not need another window.
Work survives the window. A local Rust daemon owns projects, services, sessions, and task state behind a WebSocket API; the Tauri app is a thin client. Close or restart it and long-running work continues. Task history and agent configuration persist in ~/.warpforge/warpforge.db, the project registry in ~/.warpforge/projects.json.
Review, commit, ship. Browse changed files, read unified or split diffs, accept or reject individual hunks, edit files inline, draft a commit message, commit or amend, update the branch, push with --force-with-lease, and open a pull request through the GitHub CLI.
Every registered project gets a predictable 100-port range beginning at 4000. That is not a registry detail — it is what makes parallel work practical: multiple projects, and multiple agent-built previews inside them, stay online together without fighting over 3000, 5173, or other common defaults.
For services with a configured port, Warpforge selects an available value in the project's range, sets PORT, and expands references such as ${app.port} in environment variables. The resolved URLs become part of the live context handed to new agent sessions. You can switch projects and come back without stopping unrelated services, rewriting configuration, or chasing address already in use.
Project runtime lives in .warpforge.yaml. The alternative .wf.yaml and .workspace.yaml names are also supported.
name: my-app
services:
db:
command: docker compose up postgres
port: 5432
readyPattern: "database system is ready to accept connections"
app:
command: npm run dev
port: 3000
dependsOn: [db]
env:
DATABASE_URL: postgres://localhost:${db.port}/myapp
portforwards:
- name: staging-db
namespace: postgres
pod: postgres-cluster-pooler
localPort: 5432
remotePort: 5432
agentTemplates:
custom:
command: my-acp-agent
description: Custom project agentOnly needed to develop Warpforge itself or to run it where no build is published. The installer is the recommended path.
- Rust and Cargo
- Bun 1.3 or newer
- Git
- Tauri 2 system prerequisites
- At least one supported coding-agent CLI, installed and authenticated
- Optional: Docker Compose,
kubectl, andghfor pull requests
git clone https://github.com/ephor/warpforge.git
cd warpforge/desktop
bun install
bun run tauri devThe Tauri shell builds and starts the matching Rust daemon as a sidecar. bun install also wires up the pre-commit hook that runs the fast CI checks against staged files.
cargo test --locked
cd desktop
bun run test
bun run typecheck
bun run lintcd desktop
bun run tauri buildOfficial releases additionally use protected updater signing keys, Developer ID signing, Apple notarization, immutable release tags, and draft-asset verification in GitHub Actions — see docs/RELEASING.md.
The Rust binary also manages projects directly and can run the daemon by hand:
warpforge add <path> # register a project
warpforge remove <name> # unregister it
warpforge list # list projects and port ranges
warpforge init [path] # create .warpforge.yaml (--add also registers it)
warpforge bootstrap [path] # generate a config interactively with an agent
warpforge daemon # run the local daemon explicitly
warpforge ui # terminal UI companioninstall.sh installs this CLI as wf from published archives; it does not install the desktop app, and the current release publishes a macOS Apple Silicon archive only. The Ratatui terminal UI is kept as a companion — the desktop app is where development happens.
- Desktop: Tauri 2, React, TypeScript, Vite, Tailwind CSS, CodeMirror, xterm.js
- Core and daemon: Rust, Tokio, SQLite, local WebSocket protocol, daemon bundled as a sidecar in packaged builds
- Agents: ACP over stdio, persisted sessions, capability negotiation, permission flow, orchestrator MCP tools
- Runtime: process-group service management, log capture, port isolation, readiness detection, Kubernetes port-forwards, interactive PTYs
- Git workflow: optional worktrees, file browser/editor, structured diffs, hunk resolution, commit/update/push, pull requests via
gh - Release: Developer ID signing, Apple notarization, signed updater artifacts, checksummed assets
Warpforge is young software, shipped and built in the open:
- macOS Apple Silicon is validated; Windows and Linux remain unvalidated previews;
- automatic config detection covers a
package.jsondevscript and basic Docker Compose services, with the bootstrap wizard for anything richer; - runtime state is local to one machine, and running processes do not survive a machine restart;
- interrupted task recovery depends on the underlying agent's session-load support;
- worktrees and multi-agent orchestration are powerful but still evolving — review branches before merging or pushing.
Bug reports, design feedback, and focused pull requests are welcome. If you use Warpforge on a real multi-agent workflow, sharing what felt smooth — and what still sent you back to terminal juggling — is especially useful. Release notes live in CHANGELOG.md.