External worker runtimes

An external runtime executes work outside CodeBook while CodeBook tracks the run and routes its result. Runtime kinds include generic MCP pull, signed webhook, GitHub Actions and Devin, plus dedicated adapters for GitLab CI/CD, CircleCI, Buildkite, Cursor, Jules and GitHub Copilot, each written against the vendor's own API.

Connect and assign

Add the runtime in the factory’s runtime settings, supply the credentials and configuration required by its kind, then assign it to a station or eligible routing candidate. Factory and station permissions must allow external execution.

The remote worker receives a brief and reports progress or completion using the supported runtime contract. CodeBook tracks external references and deadlines. Follow the run trail when a provider is slow, rejects a request or never reports a result.

Return evidence

Report pass, fail or blocked with an explanation and the artifacts the station requires. A successful HTTP dispatch is not a completed task. Do not retry blindly after a timeout: first determine whether the remote worker created a branch, changed a file or performed another external action.

MCP and SDKs

The workflow MCP server is an existing integration path for clients that can use its tools. Agents whose vendors document no API that starts a run with an API key — OpenAI Codex cloud, Amp and Factory droids today — connect this way, like Claude Code and Kiro. Generic compatibility does not imply a dedicated adapter for every named agent product.

First-party TypeScript and Python worker SDKs are available from the app repository. They support exclusive claims, execution progress, scoped context, artifacts, token usage and human handoff through the workflow MCP server. .NET and Java clients remain follow-on work. These are languages for writing an external worker client, not restrictions on the languages an agent may edit in your repository.