HTTP API error codes
Error responses from the orchestrator’s HTTP endpoints.
Ticket comments
Status and progress comments AI-Implement posts on your issue.
Blocker reasons
Why an eligible issue was not dispatched.
Job status values
The states a dispatch moves through, end to end.
Run failure messages
Common planning and implementation failures, and how to fix them.
Issue lifecycle
The state diagram of triggers and transitions.
HTTP API error codes
The orchestrator’s HTTP endpoints return anerror field on any failed request. The tables below list the errors each endpoint can return, grouped by who calls it: integration and callback endpoints used by runners and automation, and the admin API behind the admin UI.
Response body shapes
A failed request returns a JSON body with a singleerror field:
string
The error identifier that varies by endpoint.
- For
/runner/*and/trigger/gap-fill, a stable slug code (for example,missing_bearer). - For
/api/*and the webhook, a human-readable message (for example,Invalid JSON body).
Some responses add fields alongside
error, noted per endpoint below.Integration and callback API
These endpoints are called by runners (GitHub Actions jobs, Fly Machine sessions, or local Docker containers) and by external automation, not from the admin UI. They do not use the admin session — each authenticates with a token or nonce tied to the run or trigger.POST /runner/result
A runner reports the final outcome of a dispatch: success with a PR, or failure with error context.
POST /runner/progress
A runner streams step-by-step progress during a run.
GET /runner/planning-context
A runner fetches the planning context for its run.
POST /trigger/gap-fill
External automation triggers a gap-fill run on an existing pull request.
POST /api/token
A session requests a short-lived GitHub token, issued against a one-time nonce.
POST /api/status
A session posts a lifecycle status event, which becomes a comment on the issue.
POST /api/step-report
A runner reports the status of a single pipeline step.
POST /api/github/webhook
GitHub notifies the orchestrator of pull-request events.
Events that don’t match a merged pull request return
200 and are ignored.Admin API
These endpoints support the admin UI. See Admin UI for what each panel does.Every admin endpoint below requires a valid admin session except
POST /api/auth.Requests without one return 401 with Unauthorized.POST /api/auth
Exchange the admin access code for a session token.
Job steps and issue lists
GET /api/jobs/{jobId}/stepsreturns a job’s step historyGET /api/issueslists tracked issuesGET /api/blockerslists issues currently blocked from dispatch
POST /api/mappings
Create or update a project mapping.
Every field validation returns
400 with a message naming the problem.
Claude provider
Execution and resources
Other settings
Mapping changes
PATCH /api/mappings/{teamKey}updates a mapping’s concurrency cap or paused stateDELETE /api/mappings/{teamKey}removes a mapping
DELETE returns 404 with { "deleted": false } (no error field) when the mapping does not exist.POST /api/mappings/{teamKey}/sync-workflows
Re-sync workflow templates into the mapping’s repository.
Jira configuration
POST /api/jira/validate-jqlvalidates a JQL clauseGET /api/jira/fieldslists Jira fieldsGET /api/jira/field-optionslists the options for a Jira field
/api/jira/field-options returns an empty list, not an error, when the field has no selectable options.POST /api/runner-mode
Override the global runner execution mode.
Sessions
GET /api/sessionslists active sessionsDELETE /api/sessions/{machineId}destroys a session
GET /api/sessions returns an empty list, not an error, when Fly sessions are not configured.Secrets
/api/mappings/{teamKey}/secretslists, sets, and deletes per-team secrets/api/global-secretslists, sets, and deletes global secrets
Ticket comments
AI-Implement comments on the issue it is working so you can follow a run from your issue tracker, without watching the admin UI or the GitHub Actions logs. There are two kinds: progress comments posted at each stage of a session run, and outcome comments posted when a run opens a PR or fails.Progress comments
When a run executes in a session (Fly Machines or local Docker), AI-Implement posts a comment at each stage:Each comment also includes a timestamp, and a link to the machine logs when one is available.
Outcome comments
These report how a run finished:- A pull-request link, posted when the run opens a PR.
- A failure notice when a run errors out:
⚠️ Planning failed: {reason}or⚠️ Implementation failed: {reason}. - A log excerpt, posted on a terminal failure or timeout and labeled with the context below.
{reason} is the underlying failure message from the run.See Run failure messages for what these messages contain and how to resolve them.Blocker reasons
The orchestrator checks for eligible issues on a schedule. When it skips one, the Blockers view in the admin UI shows why. Most reasons clear on their own once the condition changes — a slot frees up, or the dedup window passes — butno-mapping needs you to add a project mapping.
An issue is also skipped if it has open blocking issues linked to it. That is a separate eligibility check, not one of the reasons above.
Job status values
Each dispatch moves through these statuses, shown in the dispatch log and the issue list. Non-terminal statuses describe a run still in flight; terminal statuses are the final outcome and do not change afterward.
A
timed_out status carries one of these reasons:
For how completion statuses appear in Slack or Teams, see Notifications.
Run failure messages
When a planning or implementation run fails, AI-Implement posts the reason on the issue as⚠️ Planning failed: {reason} or ⚠️ Implementation failed: {reason}. The {reason} pairs a short note about which step failed with the underlying error from the tool involved (Claude, git, or the package manager).
The most common failures are listed below.
Reached max turns
The run stopped at the per-run turn limit before finishing
Reached max turns
The run stopped at the per-run turn limit before finishing
Example:
Implementation failed: LLM invocation failed with exit code 1 … Reached max turns (50)Claude stopped because it reached the maximum number of turns allowed for a single run — the work was too large to finish in the limit, or the run got stuck repeating steps.See Troubleshooting for information on how to raise the limit.The Claude run failed
Claude ended with an error before finishing
The Claude run failed
Claude ended with an error before finishing
Example:
Implementation failed: LLM invocation failed with exit code 1: …Claude’s run ended with an error rather than completing — for example an API error or a loss of context. The exit code and the end of the message point to the underlying cause.No changes were produced
Claude finished without editing any files
No changes were produced
Claude finished without editing any files
Example:
Implementation failed: Nothing to commit: Claude left no file changes in the working treeClaude finished without changing any files, so there was nothing to open a pull request with. The issue may already be addressed, or may need more detail before a re-run.Pushing the branch or opening the PR failed
The push or pull-request creation was rejected
Pushing the branch or opening the PR failed
The push or pull-request creation was rejected
Example:
Implementation failed: PR creation failed with HTTP 422: …AI-Implement could not push the branch or open the pull request — commonly branch protection rules, missing repository permissions, or a pull request already open for the branch.Cloning the repository failed
The target repository could not be checked out
Cloning the repository failed
The target repository could not be checked out
Example:
Implementation failed: git clone failed (exit 128): …The runner could not clone or check out the target repository — commonly repository access or permissions, or a missing branch.Blocked by a security guardrail
A staged change looked like a secret, so the push was blocked
Blocked by a security guardrail
A staged change looked like a secret, so the push was blocked
Before pushing, AI-Implement scans the staged files for anything that looks like a secret. If a staged file matches a sensitive pattern, it blocks the push and marks the implementation failed rather than risk committing a credential.On the issue you’ll see a comment that starts with
🔒 Blocked by security guardrail, followed by Push blocked: N sensitive file(s) would be committed: and then each offending file with the reason it was flagged.A file is flagged when it falls into one of these categories, with a few examples of each:- Environment and config files —
.env,secrets.yml, or acredentials.yml.enc. - Private keys and certificates —
.pemand.keyfiles, or an SSH key likeid_rsa. - Cloud credentials — an AWS
credentialsfile, a GCP service-account JSON, or a.tfstate. - Database credentials — a
.pgpassfile or adatabase.yml. - Tokens and auth files —
.npmrc,.netrc, or akubeconfig.
.gitignore so it’s never staged, then re-run the issue.Issue lifecycle
AI-Implement moves each issue through a fixed set of stages. The diagram shows the stages and what moves an issue between them.See Triggers and status indicators for how each stage maps to a Linear label or Jira status, and how to re-run after a failure.