worker-bridge
Delegate coding tasks to external AI coding agents in isolated git worktrees with independent verification, enabling any MCP client to orchestrate multi-agent workflows.
README
worker-bridge
Delegate coding tasks to external AI coding agents — in isolated git worktrees, with independent verification — from any agent, over MCP.
worker-bridge lets one AI agent hand a scoped coding job (implement a feature, fix a cross-file bug, run a migration) to an external coding CLI — Codex, Claude Code, OpenCode, or any command-line agent — inside an isolated git worktree, then independently verifies the diff itself before handing it back. It exposes this as an MCP server, so any MCP-capable client (Claude Code, Cursor, Windsurf, Cline, Continue, …) can use it with zero code.
Dispatching agents is commodity. worker-bridge is about dispatching with a provable chain of custody: isolated execution, host-wide concurrency limits, an independent verification gate, and secret-safe event logs.
Why
- Isolation by default — each task runs in its own
git worktreeon a fresh branch. Workers never touch your working tree. - Independent verification — the orchestrator runs your verification commands (
pytest -q,npm test, …) itself, separately from the worker, and records the result. A worker can't mark its own homework. - Cross-process safety — task ownership is an atomic SQLite claim and concurrency is enforced by DB-backed leases, so many independently-launched runners can share one host without double-executing a task or overrunning limits.
- Windows-aware — cancellation kills the whole worker process tree (validated by command line, so a recycled PID is never killed).
- Secret-safe — connection strings, PEM keys, and cloud key IDs are redacted before anything is persisted.
- Multi-worker — run the same task on several workers and compare, or run an implementer + a reviewer.
These guarantees come from an independent production audit of the engine; see
docs/audit.mdfor the findings.
Install
pip install worker-bridge-mcp
You also need at least one worker CLI on your PATH — e.g. Codex, Claude Code, or OpenCode. Run worker-bridge workers list to see what's detected.
Use it as an MCP server
The server runs over stdio. Add it to your MCP client:
Claude Code
claude mcp add worker-bridge -- worker-bridge-mcp
Cursor / Windsurf / Cline / Continue — add to the client's MCP config (mcp.json / settings):
{
"mcpServers": {
"worker-bridge": {
"command": "worker-bridge-mcp"
}
}
}
Optional environment:
{
"mcpServers": {
"worker-bridge": {
"command": "worker-bridge-mcp",
"env": { "WORKER_BRIDGE_HOME": "/path/to/state", "WORKER_BRIDGE_MAX_CONCURRENCY": "4" }
}
}
}
Tools
| Tool | What it does |
|---|---|
worker_delegate |
Start a scoped coding task on a worker in an isolated worktree; returns a task_id. |
worker_status |
Poll a task: status, summary, changed files, verification result, artifact paths. |
list_workers |
Which coding workers are installed and healthy on this machine. |
worker_cancel |
Cancel a task and terminate its worker process tree. |
worker_logs |
Normalized event stream for a task (progress, completion, verification). |
Typical flow, from the host agent's side: call worker_delegate(objective=…, repository=…, verify=["pytest -q"]), then poll worker_status(task_id) until it's succeeded/failed. The changed files land in an isolated worktree plus a diff artifact; nothing is merged into your branch automatically.
Use it as a CLI
worker-bridge workers list
worker-bridge tasks create --objective "Add a --json flag" --repo /abs/path/repo --worker codex --verify "pytest -q"
worker-bridge tasks start <task_id> --wait
worker-bridge tasks show <task_id>
Use it as a Python library
import asyncio
from worker_bridge import WorkerBridge
bridge = WorkerBridge()
task = bridge.create_task({
"objective": "Add a --json flag to the CLI",
"worker": "codex",
"workspace": {"repository": "/abs/path/to/repo", "isolation": "git_worktree"},
"verification": {"commands": ["pytest -q"]},
})
result = asyncio.run(bridge.start_task(task["task_id"]))
print(result["status"], result["result"]["metadata"]["verification"]["ok"])
Workers
Built-in adapters:
- codex, claude-code, opencode — the mainstream coding CLIs.
- zcode-glm — Claude Code pointed at an Anthropic-compatible endpoint (default Z.ai GLM). A template for any alternate endpoint: subclass or construct with a different
base_url/model; the auth token is read from an env var by name (ZCODE_AUTH_TOKEN) so it never lands in a task spec or result. - vscode (experimental) — delegates into a running VS Code window via the companion
vscode-extension/(a loopback HTTP bridge on127.0.0.1:9394). Install/run the extension first; without it the worker fails closed cleanly. Seevscode-extension/README.md. - mock — deterministic, for tests.
Any other non-interactive coding CLI can be linked without code:
worker-bridge workers link my-agent --command-json '["my-agent","run","{prompt}"]'
Accepting work
A task's changes live in an isolated worktree and are never merged automatically. When you're satisfied, worker-bridge tasks accept <task_id> copies the verified changes back into the source repository (under a repository lock, refusing symlink escapes). Only independently-verified successful tasks can be accepted.
Configuration
State lives under WORKER_BRIDGE_HOME (default ~/.worker-bridge/): the SQLite store, worktrees, and artifacts. Tunables via env or ~/.worker-bridge/config.yaml:
| Env | Default | Meaning |
|---|---|---|
WORKER_BRIDGE_HOME |
~/.worker-bridge |
State root |
WORKER_BRIDGE_MAX_CONCURRENCY |
4 |
Global concurrent workers (host-wide) |
WORKER_BRIDGE_REPO_CONCURRENCY |
3 |
Concurrent workers per repository |
WORKER_BRIDGE_STORE |
— | Override the SQLite path |
Storage safety
Workspace allocation is designed so a delegation can never quietly eat the disk:
- Containment — the worker root and the target repository must never contain each other (checked by path math, not names), so a task can never recursively copy earlier tasks' workspaces into itself. Copying a repo at or above the bridge home requires an explicit
allow_profile_copyopt-in, and copy sources containing symlinks/junctions are refused outright. - Copy budgets + disk reserve —
copyisolation measures the source first (honoring cache/VCS exclusions like.git,node_modules,__pycache__) and refuses anything over 2 GiB / 50k files; the copy must also leave at least max(10 GiB, 5% of capacity) free on disk. - Two-phase allocation — the destination is planned and persisted (
allocation_state: "allocating") before any filesystem mutation, and the mutation runs under a timeout. A crash, kill, or hang always leaves a task record naming the directory it was building, a cleanfailed/timed_outstate, and a swept partial tree — never an unfindable half-copied giant. - Prune —
worker-bridge workspaces prune(dry-run by default;--applyto delete,--include-pausedto widen) and theworker_pruneMCP tool reclaim worktrees of terminal tasks plus orphan directories no task record references. Accepted tasks reclaim their worktree automatically.
Security
Custom/read-only permission profiles are checked after execution and are not an OS sandbox — the real filesystem boundary is the worker client's own sandbox (Codex workspace-write, etc.), which the bridge selects per profile. Symlink escapes are detected and fail the task; a raw path-traversal write by a sandbox-less worker cannot be seen post-hoc. Do not point a full_access worker at hostile input without a container. Secrets are redacted from the event log and store.
License
MIT — see LICENSE.
Recommended Servers
playwright-mcp
A Model Context Protocol server that enables LLMs to interact with web pages through structured accessibility snapshots without requiring vision models or screenshots.
Magic Component Platform (MCP)
An AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.
Audiense Insights MCP Server
Enables interaction with Audiense Insights accounts via the Model Context Protocol, facilitating the extraction and analysis of marketing insights and audience data including demographics, behavior, and influencer engagement.
VeyraX MCP
Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.
graphlit-mcp-server
The Model Context Protocol (MCP) Server enables integration between MCP clients and the Graphlit service. Ingest anything from Slack to Gmail to podcast feeds, in addition to web crawling, into a Graphlit project - and then retrieve relevant contents from the MCP client.
Kagi MCP Server
An MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.
E2B
Using MCP to run code via e2b.
Neon Database
MCP server for interacting with Neon Management API and databases
Exa Search
A Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.
Qdrant Server
This repository is an example of how to create a MCP server for Qdrant, a vector search engine.