Hanzo
OpenapiAgents

Start one autonomous coding run against a repo in the caller's org

Runs a coding task on a repository: clones it into a sandbox, lets a model read and edit the code, run the tests, and push the work to a branch.

POST /v1/agents/coding

Addresshttps://api.hanzo.ai/v1/agents/coding
MethodPOST
Operationpost_agents_coding
AuthAuthorization: Bearer $HANZO_API_KEY

Runs a coding task on a repository: clones it into a sandbox, lets a model read and edit the code, run the tests, and push the work to a branch. Say the thing you want done — "fix the failing auth test in hanzoai/cloud" — and the run infers the repo, the branch and the plan. No prefix, no ceremony.

It answers 202 with the run's handle the moment the run is ADMITTED — not when it finishes. A coding run takes minutes; holding a request open for one would tie a connection to a model loop and give the caller nothing it cannot get better from the session stream.

The handle is a session id, and that is deliberate: the session is already the run's durable record and its live stream (/v1/agents/sessions/{id}/stream), so this door does not grow a progress endpoint, a status endpoint or a cancel endpoint of its own. One way to watch a run, whoever started it.

It is also how work CONTINUES. Pass an earlier run's session as after and this one starts from where that one stopped, so "now add tests for it" builds on the branch already pushed instead of a fresh clone. The follow-up still gets its own branch and its own session — one run, one branch, always reviewable on its own.

Request

12 fields, body application/json (required).

FieldInTypeRequiredDescription
afterbodystringAfter names a previous run's session, and starts this one from where that one stopped instead of from the repository's default.
agentRefbodystringAgentRef names a configured agent to run as, which is how an org pins a harness, a model and a prompt to a name.
basebodystringBase is the branch to start from.
desktopbodybooleanDesktop asks for a run with a SCREEN — an image carrying an X server — for a task that has to drive a browser or another windowed program.
projectbodystringProject scopes the run to one board's work when the org keeps more than one.
promptbodystringPrompt is the task, in the words you would use with a colleague who has the checkout open.
replyChannelbodystringReplyChannel / ReplyThread are WHERE THE RUN NARRATES ITSELF, when the door that started it has somewhere for it to talk.
replyThreadbodystringReplyThread narrows that address to one THREAD inside the channel: on Slack it is the parent message's ts, the same value a reply carries as thread_ts.
repobodystringRepo is what to work on, as owner/name in the caller's own org.
targetIdbodystringTargetID routes the run to a registered machine the org has claimed instead of to a sandbox in our cluster.
timeoutSecondsbodyintegerTimeoutSeconds bounds the whole run.
toolbodystringTool is which harness runs the prompt — dev | claude | codex | python | node — and Desktop is whether the run needs a screen.

Response

StatusBodyMeaning
202CodingStartedaccepted

202 body — 5 fields.

FieldInTypeAlwaysDescription
branchbodystringBranch is the ref the run will push its work to, and the ONLY ref it is permitted to write.
repobodystringRepo is the repository the run was admitted against, echoed back as the engine resolved it.
routedbodybooleanRouted says the run went to one of the org's own registered machines rather than to a sandbox in our cluster.
sessionIdbodystringSessionID is the run's handle: its durable record, and the id its live progress streams under at /v1/agents/sessions/{sessionId}/stream.
targetIdbodystringTargetID names that machine when Routed is true, and is empty otherwise.

Failure carries the platform error shape — see Errors.

Examples

hanzo has no subcommand for this operation — the CLI serves only what cloud's live route table confirms. Use HTTP or an SDK.


Agents API · All Hanzo APIs · Interactive reference

How is this guide?

On this page