Skip to main content
Experimental version.This is the latest in-development version of AI-Implement. Features may change without notice and behavior is not guaranteed. Switch to the latest stable version here.
Comprehensive reference for the error codes, statuses, and failure messages AI-Implement surfaces. For step-by-step fixes to the most common problems, see Troubleshooting.

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 an error 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 single error 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.
Some sections below cover several related endpoints that return the same errors.
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}/steps returns a job’s step history
  • GET /api/issues lists tracked issues
  • GET /api/blockers lists issues currently blocked from dispatch
Responses shown as (underlying error message) return the raw error text with a 500 or 502 status, not a stable code. Treat them as diagnostic detail — the wording can change between releases.

POST /api/mappings

Create or update a project mapping.
Every field validation returns 400 with a message naming the problem.
Required fields Claude provider Execution and resources Other settings

Mapping changes

  • PATCH /api/mappings/{teamKey} updates a mapping’s concurrency cap or paused state
  • DELETE /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-jql validates a JQL clause
  • GET /api/jira/fields lists Jira fields
  • GET /api/jira/field-options lists 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/sessions lists active sessions
  • DELETE /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}/secrets lists, sets, and deletes per-team secrets
  • /api/global-secrets lists, 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 — but no-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.
For step-by-step help when an issue is not picked up, see Troubleshooting.

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.
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.
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.
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.
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.
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.
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 a credentials.yml.enc.
  • Private keys and certificates.pem and .key files, or an SSH key like id_rsa.
  • Cloud credentials — an AWS credentials file, a GCP service-account JSON, or a .tfstate.
  • Database credentials — a .pgpass file or a database.yml.
  • Tokens and auth files.npmrc, .netrc, or a kubeconfig.
To resolve it, remove the file from the change, or add it to .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.
Each stage shows up as a Linear label or a Jira status: