worker-bridge

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.

Category
Visit Server

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 worktree on 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.md for 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 on 127.0.0.1:9394). Install/run the extension first; without it the worker fails closed cleanly. See vscode-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_copy opt-in, and copy sources containing symlinks/junctions are refused outright.
  • Copy budgets + disk reserve — copy isolation 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 clean failed/timed_out state, and a swept partial tree — never an unfindable half-copied giant.
  • Prune — worker-bridge workspaces prune (dry-run by default; --apply to delete, --include-paused to widen) and the worker_prune MCP 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

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.

Official
Featured
TypeScript
Magic Component Platform (MCP)

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.

Official
Featured
Local
TypeScript
Audiense Insights MCP Server

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.

Official
Featured
Local
TypeScript
VeyraX MCP

VeyraX MCP

Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.

Official
Featured
Local
graphlit-mcp-server

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.

Official
Featured
TypeScript
Kagi MCP Server

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.

Official
Featured
Python
E2B

E2B

Using MCP to run code via e2b.

Official
Featured
Neon Database

Neon Database

MCP server for interacting with Neon Management API and databases

Official
Featured
Exa Search

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.

Official
Featured
Qdrant Server

Qdrant Server

This repository is an example of how to create a MCP server for Qdrant, a vector search engine.

Official
Featured