Autofix hands an issue to an AI agent. The agent reads the captured error, explores your GitHub repository, works out the root cause, and — when the bug can be fixed in your code — opens a draft pull request with the change. You review it and merge it like any other PR.

The agent can only read and edit files in the linked repository. It can't run your code, your tests, or shell commands, and it never pushes to an existing branch: every fix lands on a new branch, as a draft PR.

Requirements

• The organization's plan includes AI agents.
• An AI provider is connected in Organization → Integrations — Claude (Anthropic) or OpenAI. Agents run on the organization's own API key; Buglapse doesn't bill for model usage.
• GitHub is connected in Organization → Integrations, and a repository is linked to the project in Settings → Repository. The agent reads the code from it and opens the pull request there.

Integrations, repositories, and agents are set up by the organization owner. Once an agent exists, any member can assign issues to it.

Create an agent

Open the project's Settings → Agents and click New agent. An agent is a configuration, not a person — it has no account and doesn't show up among members.

Field	What it does
Name	How the agent appears in the assignee list and on its runs. Unique per project.
Provider	Claude or OpenAI — the connected integration whose API key the agent uses.
Model	The model to run on, from the provider's list (e.g. Claude Opus 5, Claude Sonnet 5, or the GPT / o-series models your OpenAI key can access).
Instructions	Optional notes added to the agent's instructions, up to 5000 characters — e.g. "Only change files in src/, match the style of neighbouring files."
Max steps	How many model calls a run may make before it stops (5–200, default 40).
Timeout (minutes)	How long a run may take in total (1–120, default 30).

An agent can be disabled with its toggle: a disabled agent isn't offered as an assignee. Removing an agent cancels its active run; finished runs stay, and issues assigned to it become unassigned.

Start a run

Assign an issue to the agent — from the issue page or the issues list, the same way you assign it to a member. The run starts right away, and the issue's Autofix card shows its progress.

An issue is assigned to either a member or an agent, never both:

• Reassigning the issue to a member, or unassigning it, cancels the active run.
• Assigning it to a different agent cancels the current run and starts a new one.
• Assigning it to the agent that's already working on it changes nothing.

If a run can't start — the agent is disabled, the provider or repository isn't connected, another run is already active, or the issue has used all its attempts — the assignment is rejected with the reason, and the issue keeps its previous assignee.

Each issue gets at most 3 runs, whatever their outcome, so a stubborn issue can't keep spending your API budget.

How a run works

The agent works from a snapshot of the issue taken when the run starts: the issue's name and message, the latest exception's stack trace (already resolved to original source when the release has source maps), its last 30 breadcrumbs, tags and contexts (end-user details are left out), and the release it came from. New occurrences captured later don't change a run that's already going.

A run goes through three stages, in order. Each stage is a fresh conversation with the model that ends when it submits a structured result, which is handed to the next stage:

1. Root cause — the agent reads the code the stack trace points at, follows the calls, and explains what actually goes wrong and why, with the files involved and a confidence level. It also decides whether a code change in this repository can fix it. If it can't — the error comes from a third-party library, the environment, or code that isn't in the repository — the run ends as No fix.
2. Plan — the smallest change that fixes the root cause: which files to touch and what changes in each, plus the risks to check.
3. Changes — the agent edits files to implement the plan, then summarizes what it changed and why. A run may change up to 20 files, each up to 200 KB.

After the last stage Buglapse itself — not the model — commits the edits on a new branch buglapse/autofix-{issue-key}-{run-id} and opens a draft pull request against your default branch. The PR description includes the summary, the root cause, the plan, and links back to the issue and the run.

While exploring, the agent can list files, read them, and use GitHub code search. When the exception's release has a ref (a commit sha — see Describe the release from CI), it can also read files as they were in the release the error came from, not only as they are on the default branch now. Edits are pinned to the default branch's commit at the moment the Changes stage starts, so pushes made meanwhile don't skew the diff.

Follow and review runs

The project's Autofixes page lists every run. Open one to see:

• the status, the current stage, token usage, and who started it;
• the root cause, the plan, and the list of changed files;
• the full log of the agent's steps — every model reply and tool call;
• the diff of the pull request, loaded from GitHub.

A run ends in one of these statuses:

Status	Meaning
Succeeded	The draft pull request was opened.
No fix	The agent decided the issue can't be fixed in this repository, or finished without changing any file. The reason is shown on the run.
Failed	The run hit its step or time limit, the provider kept failing or refused, the API key or the GitHub connection stopped working, or the model stopped without submitting a result.
Cancelled	Someone cancelled it, the issue was reassigned, or the agent was removed.

Any member can Cancel an active run (a model call already in progress finishes, the next one never starts) or Retry a failed, cancelled, or no-fix run — retrying assigns the issue back to the same agent and starts a new attempt, which counts toward the limit of 3.

Security

• The error report is treated as untrusted. Exception messages, breadcrumbs, and contexts come from your app and could contain text crafted to look like instructions. The agent is told never to follow instructions found in them — only its system instructions and the agent's Instructions field are trusted.
• Nothing is merged for you. Every change goes through a draft PR you review. Tests are not run by Buglapse, so run your CI and review the diff before merging.
• Access is limited to the linked repository. The agent can't reach other repositories, and paths that would escape the repository are rejected. If the linked repository changes while a run is working, the run fails rather than pushing to a different one.
• No mentions from the model. @ mentions and #123 references in the PR title and body are neutralized, so a generated description can't ping people or link unrelated issues.

Tips

• Upload source maps and send the release's ref from CI: the agent then sees original file names and lines, and can read the code exactly as it was deployed.
• Use the agent's Instructions for project conventions: where the code lives, what not to touch, the style to follow.
• A larger model finds harder root causes but costs more per run; raise Max steps for large repositories where the agent needs more reading before it can conclude.

Troubleshooting

"Your plan does not include AI agents." Upgrade the organization's plan.

"Connect Claude / OpenAI in Organization → Integrations first." The agent's provider isn't connected. Members see "The organization owner hasn't connected … yet."

"Link a repository in Settings → Repository first." The project has no linked repository.

"An agent is already working on this issue." Wait for the active run to finish or cancel it.

"This issue has used all 3 agent attempts." The per-issue limit is reached; fix it by hand.

Run failed: "Stopped at the agent's limit of N steps" / "time limit of N minutes". Raise Max steps or Timeout on the agent, add hints to its Instructions, and retry.

Run failed: "The … API key is missing or unreadable". Reconnect the provider in Organization → Integrations.

Run failed: "GitHub connection lost". Reconnect GitHub in Organization → Integrations and check that the GitHub App still has access to the repository.