← Projects

Active · developer tool

coding-worker

A shared MCP worker for implementation, exploration, diagnosis, verification and code review.

Technologies
MCP · Pi / OpenCode · Bubblewrap · Git
My contribution
My public project: a shared interface for delegating development tasks and returning evidence.
Sources checked
From task to review evidence
  1. MCP clientBrief and scope
  2. WorkerPi / OpenCode
  3. ResultReview evidence

finished ≠ accepted

The problem

A coding agent is useful for more than implementation. I also want it to explore unfamiliar code, reproduce a bug or independently assess a diff. These tasks need different permissions and acceptance criteria. coding-worker exposes them through one MCP interface while the requesting agent retains control of scope and acceptance.

Architecture and decisions

Implementation, exploration, diagnosis, verification and review have separate operations. Submitting work promptly returns a run identifier. Waiting, retrieving evidence and recording external review are explicit follow-up steps. Investigation reports cite source code rather than returning an unsupported conclusion.

Model-backed operations can use Pi or OpenCode, selected through profiles. Verification runs an explicit check without a model. One run holds the worktree lock at a time to prevent concurrent implementations from overwriting each other. Results can include a paginated diff with untracked files, so the requesting agent does not need to load everything at once.

Isolation and acceptance

Implementation writes code and requires independent review. It does not commit or push. Investigation operations use a read-only filesystem sandbox; check and reproduction commands have private temporary storage without network access. These modes require Linux, Bubblewrap and working user namespaces.

Acceptance is separate from process completion. Recording external review distinguishes a worker finishing its run from a change satisfying the brief.

Status and tradeoffs

The public README describes a local MCP worker. Accepted jobs can continue after client request cancellation, but stopping the MCP server cancels them. This alone is not a service guaranteeing execution across host restarts. Clients need a shared data directory and must reconnect after updates.

Separate operations and sandboxing do not remove the need for a clear brief, permission checks and human approval. Review quality also depends on the selected model and context.

Connections

AgentBox addresses agent execution environments. git-wt simplifies worktree management. I describe how these layers fit together in Agentic Engineering.