# AI auto-fix

> https://docs.errora.org/en/products/ai-autofix

Auto-fix reads the stack trace, pulls the relevant source out of your repository, asks an AI
provider for a patch, and opens a **merge request** with it. You review it like any other MR.

## What you need first

1. A **source-control integration** connected and a **repository linked to the project** —
   see [Integrations](/en/products/integrations). Without it there is no source to read and
   nowhere to open an MR.
2. An **AI configuration** for the organization (or for one project).

## Configure a provider

**Settings → AI**, or over the API:

```bash
curl -X POST "$ERRORA/api/v1/organizations/$ORG_ID/ai-configs" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Default fixer",
        "provider": "claude",
        "model": "claude-opus-4-8",
        "api_key": "sk-…",
        "base_url": "",
        "project": null,
        "auto_trigger": false,
        "enabled": true
      }'
```

| Field | Notes |
| --- | --- |
| `provider` | `openai` (any OpenAI-compatible endpoint), `claude` (Claude Agent SDK), `cursor` (Cursor Agents SDK) |
| `model` | Provider-specific model id |
| `api_key` | Stored encrypted; the API never returns it in full |
| `base_url` | For OpenAI-compatible gateways and custom endpoints |
| `project` | `null` = applies to the whole organization; set it to scope a config to one project |
| `auto_trigger` | Start a run automatically when a new issue is created |
| `enabled` | Turn a config off without deleting it |

A project-scoped config wins over the organization-wide one.

## Trigger a run

From the **issue page**, press **AI auto-fix**. Or:

```bash
curl -X POST "$ERRORA/api/v1/projects/$PROJECT_ID/issues/$ISSUE_ID/autofix" \
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

Triggering requires the **`ai:trigger`** capability (owner, admin, member by default).

## What happens

1. Errora gathers **context**: the exception, the stack frames, and the source files those
   frames point at, fetched from the linked repository.
2. The provider is asked for a **patch plus an explanation**.
3. Errora creates a branch (`errora/autofix-<issue>-<timestamp>`), commits the diff and opens
   a **merge request**.
4. The run is recorded with its status, diff, explanation, MR URL, model and token usage.

A run takes as long as the model does, and your events keep flowing meanwhile. Follow
progress live on the issue page, or in **AI fixes**, which lists every run in the
organization.

Each stage fires an alert event you can route to a channel: `autofix.started`,
`autofix.mr_created`, `autofix.failed` — see [Alerts](/en/products/alerts).

## Cost

Each run is metered as the **AI Fix** service (20,000 Toman per run by default) on top of
whatever your AI provider charges. See [Wallet](/en/billing/wallet).

## Reviewing the patch

Treat it as a draft from a colleague who has read the stack trace and nothing else:

- It sees the frames and the files they point at — not your tests, your product decisions or
  the ticket.
- Run the tests. Read the diff. The MR is a starting point, not an authority.

## Troubleshooting

| Symptom | Cause / fix |
| --- | --- |
| Button disabled / `403` | Your role lacks `ai:trigger` |
| "No repository linked" | Link a repo to the project in [Integrations](/en/products/integrations) |
| Run fails immediately | Wrong API key or model id, or a `base_url` Errora cannot reach |
| MR not created | The integration token lacks write scope on the repository |
| Patch looks unrelated | The stack frames pointed at vendor code — link the right repo, and make sure source maps/releases resolve frames to your own files |