Claude Plans. OpenCode Builds.

The gap is not intelligence. It is plumbing. Claude can read a repository, reason about a bug and write a plan for fixing it. What it cannot do, on its own, is open the file, run the tests, read the failure and try again. OpenCode can do all of that, but it lives outside Claude's context. The two halves of an agentic workflow have been separated by a surprisingly mundane problem: how does the plan reach the hands?

TaskBridge is a small, opinionated answer. Published on GitHub on Oct. 16 by the developer behind the handle Parithosh-Varma, the project is a Python bridge that lets Claude dispatch coding work to headless OpenCode agents over the Model Context Protocol. Its tagline is blunt: “Claude plans. OpenCode builds.”

It is early: three stars and no open issues at the time of writing. But the design is worth a closer look, because it treats the handoff — not the model — as the hard part.

A queue, not a chat

The first decision is architectural. TaskBridge is not a wrapper around a chat window. When Claude submits a task through one of the 17 MCP tools the bridge exposes, the task is written to a SQLite database. A separate worker polls every 60 seconds, claims a task by priority and age, and runs opencode run inside a per-task git worktree. When the run finishes, the worker writes a structured result back to the queue: a summary, the files touched, the tests run, any open questions, usage metadata and a git-aware diff.

That queue is the point. A chat handoff is ephemeral; a queue is durable. If the worker restarts, the task is still there. If a run fails, it can be retried, optionally on a different model. Tasks can carry dependencies, priorities, timeouts, idempotency keys and tags. submit_batch accepts up to 20 at once, which makes the system feel less like a single assistant and more like a small newsroom of them.

The worktree is the other half of the safety story. Each task gets its own branch and its own checkout, so an agent working on one file cannot quietly change another task's tree. On success the worker commits; on a readonly permission it reverts the writes and reports exactly which files were rolled back. The README is careful to say that no-network and no-shell are prompt-level restrictions, not operating-system sandboxes — an honesty that is rare in agent tooling.

A conversation in both directions

Most orchestrators stop at dispatch. TaskBridge adds a second channel. If the worker needs an answer, it can pause with a question; the task moves to waiting, a macOS notification appears, and Claude can answer through answer_task. The run then resumes with that answer in context. It is a small feature, but it changes the shape of the interaction: the planner is not just firing off jobs, it is supervising them.

The bridge also runs in reverse. A second MCP server, claude_control_mcp.py, gives OpenCode six tools for asking Claude questions or submitting background jobs. If an API key is present it uses the Anthropic API; otherwise it shells out to claude -p. The result is less a one-way pipeline than a narrow two-lane road between two agents.

“Claude stays the interface. OpenCode does the execution. SQLite is the durable handoff.”

TaskBridge README

Operations, not demos

The unglamorous parts are where the project shows its age in a good way. There is a live dispatch board served at /, with task counts, per-task logs and a model picker that writes to worker_config.json. There is a bearer token for HTTP access, an allowlist for tunnel hosts, an OAuth consent flow and a /health endpoint. There is a 15-minute stale-task reaper, a single-instance lock, a heartbeat file and a restart tool that can recover a dead worker through launchd without touching the queue. The installer offers a Cloudflare quick tunnel by default or ngrok if you have an account, and prints the public URL and token box for Claude Desktop.

That is a lot of operational surface for a project this young, and it suggests the author has actually run it. The README's “Verified” section reads like a test log, not a marketing page: submit, claim, complete; MCP tool discovery; launchd end-to-end recovery; pending task byte-identical after a restart.

What it is not

The caveats are equally specific. Scheduling and worker recovery are built around macOS launchd; Linux users need their own timer and lose the restart tool. Token counts are not exposed by the OpenCode CLI, so “usage” reports model, latency, attempts and sandbox status rather than spend. Permission modes are prompt-level. The project is six days old.

None of that undermines the central idea. The agent ecosystem is crowded with planners and executors, and still thin on the layer between them: authentication, state, retries, isolation, observability, a paper trail. TaskBridge is a compact argument that this layer may matter more than another model. It is Apache-2.0, small enough to read, and designed to be forked.

The most interesting thing about it is not that Claude can ask OpenCode to write code. It is that the handoff survives a restart.

Try it

The install is a shell script; it checks dependencies, starts a tunnel and prints the MCP connector details. The repository recommends Python 3.12 and a current OpenCode CLI.

# clone and install
git clone https://github.com/Parithosh-Varma/TaskBridge.git
cd TaskBridge
./install.sh