AI Autofixer: From an Error Group to a Pull Request

Temps v0.1.0-beta.56 ships a built-in AI Autofixer, labelled Experimental: open an error group in your dashboard, click "Fix with AI", and the platform creates a sandboxed agent run that reads the stack trace, edits your repo in an isolated workspace, and — when you click Create PR — opens a pull request on your git provider (GitHub, GitLab or Gitea). No external AI coding tool, no copy-pasting stack traces into a chat window, no leaving the deployment platform.

You get an error spike at 2am. You squint at the stack trace, half-asleep. You check out the repo, find the offending function, write a fix, push it, wait for CI, merge, deploy. By 3am, you're back in bed, exhausted.

Or — in the Temps v0.1.0 beta line — you click "Fix with AI" on the error group, an agent reads the stack trace and your repo and proposes a fix, and after coffee you review it and open the pull request.

That's the loop. This post explains how it works, why we built it the way we did, and what to expect (including the parts that aren't magic).

TL;DR: The Autofixer in the Temps v0.1.0 beta line ties AI agents to error groups. Click Fix with AI, the agent reads the stack trace, checks out your repo in a sandboxed run and makes a fix; you open the PR (GitHub, GitLab or Gitea) with one click. Two-phase flow (analyze → fix), real-time SSE streaming of the agent's output, and a run page with Conversation, Report, Details and Logs tabs. It's young — Temps labels AI agents Experimental — and it produces PRs you should review like any junior contributor's PR.

How does AI-powered error fixing work in a deployment platform?

Here's what happens when you click Fix with AI on an error group:

1. A sandboxed agent run is created. The agent_runs table gets a new row with phase analyzing.
2. The agent reads the error context. The error type and title, the symbolicated stack frames of the group's latest event, and any notes you add.
3. The agent checks out your repo. A clean clone in an isolated workspace. The agent has read access to source files.
4. It analyzes the issue. First phase: understand what's broken and propose a fix. Output streams to the UI in real time.
5. You review the analysis. The run page shows the conversation, the report and (under Details) the error group. You approve or redirect.
6. It implements the fix. Edits files in the sandbox, and runs tests if you ask it to and the sandbox image has your toolchain.
7. You click Create PR. A branch is created and pushed, and the pull request (a merge request on GitLab) is opened against the project's configured main branch through your git provider.
8. You review the PR. Same workflow as any human contributor's PR.

The agent run history page lets you replay every run with its streamed agent output, system logs and timestamps.

That sandbox is a platform primitive, not an Autofixer-specific one: Temps exposes the same kind of isolated container (and, on a Linux host with KVM, Firecracker microVMs) through its sandbox API, which is what keeps agent code on your own server instead of a hosted execution service like E2B or Modal.

Autofixer vs. manual debugging vs. AI coding assistants

Copilot's coding agent can open pull requests by itself; per GitHub's docs, "some entry points open a pull request automatically" (GitHub docs, checked October 2026). The difference is where the context comes from: the Autofixer reads the error type, title and symbolicated stack trace straight from your Temps error tracking store. You don't summarize the problem — the agent starts from the error itself.

Why two phases?

The interactive Autofixer flow is deliberately two-phase: analyze → review → fix → review → PR. Not one-shot.

The reason is simple: AI agents make mistakes, and the cost of a wrong fix is higher than the cost of a brief pause for human review. By splitting analyze from fix, we catch the worst class of error — the agent misreading what's broken — before it touches your code.

Phase 1 (analyze): the agent reads the error and proposes a diagnosis and approach. No file edits. You read the analysis and either approve or push back ("no, this is actually a database connection pool issue, not a null check problem").

Phase 2 (fix): the agent implements based on the approved analysis. File edits happen here, in the sandbox.

The two-phase flow isn't a UX decoration. It's a cost-aware design choice: reviewing prose is cheap; reviewing a diff for a fix that addresses the wrong problem is expensive. The human gate is placed at the cheaper side of the loop.

The framework underneath

The Autofixer is one application of a general agent framework that landed in the v0.1.0 beta line — the temps-agents crate, covered in full in the Temps AI agents overview.

The framework supports two modes:

• Autonomous agents. Configured per-project in YAML with a system prompt, max turns, an AI provider and a deliverable (pull_request, commit, analysis or log_only). They fire on new or regressed errors, production or preview deploys, downtime or latency alerts, cron schedules, webhooks or a manual click, with daily_budget_cents and cooldown_minutes as guard rails (the budget check sums run cost estimates, which v0.1.0-beta.56 doesn't record yet, so only the cooldown limits runs today). Use case: nightly dependency upgrades, weekly code-quality scans, triage of new errors.
• Interactive agents (Autofixer). Triggered manually from a specific surface (currently error groups). Two-phase flow with human gates. Use case: bug fixes, ad-hoc tasks.

Both modes share infrastructure:

• agent_runs table with phase, analysis, user_context, status, token counts, PR details and timestamps.
• agent_run_logs table with streamed agent output and system logs.
• YAML sync — .temps/agents/*.yaml is the source of truth, synced during deployment.
• Skills and MCP servers — .claude/skills/ in the repo is auto-discovered by the Claude CLI, and agents can also load skills and MCP servers registered in Temps (skills: and mcp_servers: in the YAML).
• Provider abstraction — claude_cli, codex_cli, or opencode (configure per-agent via ai_provider:).
• Git provider integration — push_files_and_create_pr and create_pull_request open PRs on GitHub, GitLab (merge requests) or Gitea; Bitbucket Cloud doesn't support pushing files this way, and repos imported by public URL are read-only.

How it's built

The Autofixer moves each run through analyzing → analyzed → fixing → fix_ready (or no_fix / failed), and only calls push_files_and_create_pr once a run reaches fix_ready (autofixer.rs). Agent YAML is parsed by AgentYamlConfig in repo_config.rs, where max_turns defaults to 25. The three providers each have a module under crates/temps-agents/src/ai_cli/ and write the same agent_run_logs shape, so you can switch provider per agent without backend changes.

The AgentCronScheduler service watches the project_agents table for scheduled agents and fires runs. Output streams to the UI just like Autofixer runs. PRs get opened the same way.

Honest TODO: manual triggers for autonomous agents currently use the same one-shot pipeline as scheduled runs. We'd like manual triggers to use the interactive flow with human gates. Coming in a future release.

Provider choice: Claude CLI, Codex, or OpenCode

The framework ships three AI provider backends:

• claude_cli — Claude CLI, with --continue for multi-turn sessions in the same working directory. Strong at code reading and following structured output formats. Configure model with ai_model: in the YAML.
• codex_cli — OpenAI Codex CLI (GPT-5 Codex models), signed in with ChatGPT or an OPENAI_API_KEY. Different cost profile, different strengths.
• opencode — OpenCode (multi-provider terminal agent). Configure via opencode auth add.

Set ai_provider: in your agent YAML. All three produce the same agent_run_logs shape, so you can swap providers without UI changes.

What's not in the v0.1.0 beta line

• Multi-repo agents. Each agent operates on one repo at a time.
• Memory across runs. Each run starts fresh. The --continue support is per-run for multi-turn within a single conversation, not across runs.
• Human-in-the-loop on autonomous runs. Scheduled runs are one-shot. We're working on it.
• Rollback / revert. If a PR ends up being wrong, you revert via your normal git workflow. There's no "undo this run" button.

Try it

The Autofixer is available in v0.1.0-beta.56 as an Experimental feature. To use it:

1. Have error tracking set up. The Sentry-compatible ingest works with your existing Sentry SDK.
2. Connect your project's repo through a GitHub, GitLab or Gitea connection — the Autofixer needs write access to push branches and open PRs.
3. As an instance admin, configure an AI provider under AI Workflows → AI Providers (a Claude subscription token or Anthropic API key, or an OpenAI sign-in or key), and make sure Docker and the agent image are ready under AI Workflows → Sandbox. The provider credential is instance-wide.
4. Wait for an error group to fire (or seed one with a deliberate bug).
5. Click "Fix with AI" on the error group detail page.

Every agent field is listed in the Temps AI agents overview, and Temps for AI agents covers sandboxes and the rest of the agent tooling. Temps is licensed MIT / Apache 2.0 — free to self-host. Temps Cloud, a hosted control plane for your own servers, is coming soon from $29/month.

FAQ

Does the agent have access to my entire codebase?

The agent runs in a sandbox with a clean checkout of your repo. It can read and edit files within the sandbox. Besides the repo, the sandbox gets the AI provider credential, a git token for the clone and push, and a project API token scoped to the run (TEMPS_API_TOKEN) that is revoked when the run ends — so treat what the agent can reach accordingly.

What about secrets in env vars?

Temps doesn't inject your project's runtime env vars into the sandbox. If your repo includes a .env.example with placeholder values, the agent can read that, but real secrets stay in Temps's encrypted store. Note that the run-scoped TEMPS_API_TOKEN can call the Temps API for the project while the run lasts.

Can the agent run my tests?

It can, if you ask it to in your notes or prompt and the sandbox image has the toolchain: the default image is Node, and presets add Bun, Python, Rust, Go or a full image. Temps doesn't run your tests automatically.

How much does it cost to run?

You bring your own AI API key, so cost depends on your provider, model and how much of the repo the agent reads. Each agent run records its input and output tokens, and Claude and OpenCode runs show a per-turn cost in the conversation view. The run's estimated-cost field isn't filled in yet on v0.1.0-beta.56 (it stays at 0), so daily_budget_cents on autonomous agents doesn't trip today — cap spend with your AI provider's own limits.

Is the AI Autofixer GA or beta?

Experimental: Temps labels AI agents and workflows Experimental, so the interface may change between releases. It ships in v0.1.0-beta.56 because the loop works end to end, but the AI agent space moves fast and we expect to iterate. Treat it like any new tool — run it on a non-critical project first, learn its quirks, then expand.

How does the Autofixer compare to GitHub Copilot Autofix?

GitHub Copilot Autofix works on static analysis (SAST) findings before code ships. The Temps Autofixer works on runtime error groups — production exceptions from your Sentry-compatible error tracking, starting from the error type, title and symbolicated stack trace. They're complementary: Copilot Autofix catches static issues pre-merge; Temps Autofixer handles what slips through to production.

Is Temps open source?

Yes. Temps is licensed MIT / Apache 2.0. The temps-agents crate, autofixer service, and all related code are in the public repo.

Related: Read the full v0.1.0 release notes