AI Autofixer: From an Error Group to a Pull Request

Temps v0.1.0 ships a built-in AI Autofixer: 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 opens a pull request on GitHub. 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 Temps v0.1.0 — you click "Fix with AI" on the error group, an agent reads the stack trace and your repo, makes a fix, opens a pull request, and you review it after coffee.

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 Temps v0.1.0 ties AI agents to error groups. Click Fix with AI, the agent reads the stack trace, checks out your repo in a sandboxed run, makes a fix, opens a PR via GitHub. Two-phase flow (analyze → fix), real-time SSE streaming of the agent's output, and a split UI showing the error on one side and the conversation on the other. It's young, it's a flagship feature, 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. The UI's workflow timeline updates.
2. The agent reads the error context. Stack trace, error message, breadcrumbs, the request that triggered it, the trace_id (if OTel was instrumented).
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 split UI shows the error on the left, the AI conversation on the right. You approve or redirect.
6. It implements the fix. Edits files, runs tests if your repo has them, commits the result.
7. A pull request is opened. Branch is auto-created and pushed; PR is opened against your default branch via the GitHub API.
8. You review the PR. Same workflow as any human contributor's PR.

The agent run history page lets you replay every run with full stdout/stderr, exit code, 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

The difference is integration depth: the Autofixer reads the actual error event, breadcrumbs, and OTel trace_id from your Temps error tracking store. You don't summarize the problem — the agent sees the same data you see.

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 v0.1.0 — the new temps-agents crate.

The framework supports two modes:

• Autonomous agents. Configured per-project with a system prompt, max turns, and an AI provider. Run on cron schedules via the CronScheduler service. Use case: nightly dependency upgrades, weekly code-quality scans, scheduled refactor passes.
• 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, exit code, timestamps.
• agent_run_logs table with streamed stdout/stderr.
• YAML sync — .temps/agents/*.yaml is the source of truth, synced during deployment.
• Skills — .claude/skills/ in the repo, auto-discovered by the Claude CLI.
• Provider abstraction — claude_cli, codex_cli, or opencode (configure per-agent via ai_provider:).
• GitHub integration — push_files_and_create_pr and create_pull_request for PR creation.

Citation Capsule: The temps-agents crate in Temps v0.1.0 supports two agent modes: autonomous agents that run on cron schedules with configurable system: prompts and max_turns (default: 25), and interactive agents that drive the Autofixer through a two-phase analyze-then-fix flow. Both modes share the agent_runs table, real-time SSE log streaming, and built-in GitHub PR creation via push_files_and_create_pr. Three providers are supported: claude_cli, codex_cli, and opencode — verified in crates/temps-agents/src/ai_cli/.

Three quotable verified Temps claims

1. Phase-aware agent_runs table with six tracked states. The Autofixer transitions through analyzing → analyzed → fixing → fix_ready (or no_fix / failed). The push_files_and_create_pr call only happens when phase = "fix_ready". — verified in crates/temps-agents/src/services/autofixer.rs

2. max_turns defaults to 25, configurable per-agent in YAML. The AgentYamlConfig struct in temps-core/src/repo_config.rs sets default_max_turns() to 25. Autonomous agents set it via max_turns: in .temps/agents/*.yaml. The CronScheduler polls scheduled agents and fires agent runs against the project_agents table. — verified in crates/temps-core/src/repo_config.rs lines 186–187 and crates/temps-agents/src/services/cron_scheduler.rs

3. Three AI providers ship out of the box: claude_cli, codex_cli, opencode. Each has its own module under crates/temps-agents/src/ai_cli/. All three emit the same agent_run_logs shape so provider can be swapped per-agent with no backend changes. — verified via ls crates/temps-agents/src/ai_cli/

The split UI

The Autofixer UI is a two-pane layout:

• Left pane: error detail. Stack trace, breadcrumbs, occurrences, affected users, full event payload.
• Right pane: AI conversation. The agent's analysis, your responses, the streamed output of the fix phase.

A workflow timeline at the top shows the current phase. SSE streams the agent's output in real time, with auto-scroll and a "working" indicator when the agent is mid-thought.

The AutofixButton on the error group detail page is status-aware. Before the first run: "Fix with AI." During a run: "Run in progress" with a link to the conversation. After a successful PR: "PR #123 opened."

Streaming the agent's chain-of-thought live is the single most valuable part of the UI. Watching the agent narrate what it's looking at makes it dramatically easier to catch wrong reasoning before the fix phase starts — an important safeguard given that fixing the wrong problem wastes everyone's time.

Real-time streaming, line by line

The agent's stdout is parsed as Claude CLI's stream-json format. Each line is a JSON event with a type (content, tool_use, tool_result, error, etc.). The Rust backend parses line by line via BufReader, normalizes events, and pushes them onto an SSE channel.

The frontend subscribes via EventSource and renders events into the conversation pane. Auto-scroll keeps the latest output visible. A working indicator appears when the agent is mid-message.

This is harder than it sounds, because Claude CLI's output is line-buffered but not strictly line-delimited — partial lines arrive when the network flushes mid-message. The line-by-line BufReader approach handles partial reads correctly and avoids the "frozen UI for 30 seconds, then 200 lines at once" pattern.

What it's good at

• Null-check / undefined-property bugs. Stack trace points at a clear line, the fix is usually a guard clause.
• Type mismatches. TypeScript errors, Rust borrow-checker complaints, Python TypeErrors.
• Off-by-one and boundary errors. When the test case is implicit in the stack trace.
• Dependency / import fixes. Missing imports, deprecated API calls, breaking changes in a recent upgrade.
• Configuration mistakes. Missing env vars, misconfigured CORS, wrong port numbers — when the error message names them.

What it's not good at

Honest list:

• Logic bugs that span multiple files without a clear failure point in the stack trace.
• Race conditions and concurrency issues. The agent can read code, but it can't easily simulate timing-dependent failures.
• Bugs that require domain knowledge. "This SQL query returns wrong revenue numbers" needs a human who understands the business definition of revenue.
• Performance problems. "Slow database query" is a profiling task, not a code-edit task.
• Anything that needs a real environment to reproduce. The sandbox runs the agent, not your full stack.

You should treat AI-generated PRs the way you'd treat a junior contributor's PR: read carefully, run the tests, think about edge cases. The point isn't autopilot — it's getting a working first draft faster than starting from scratch.

The autonomous path

Same framework, different trigger. Autonomous agents run on cron schedules. Configure once with a system prompt:

# .temps/agents/dependency-upgrades.yaml
name: dependency-upgrades
ai_provider: claude_cli
max_turns: 20
on:
  schedule:
    cron: "0 9 * * 1"  # Mondays at 9am
system: |
  You are a dependency upgrade assistant. Each week, check for available
  minor and patch upgrades to dependencies in this repo. For any safe upgrade,
  run the test suite locally, then open a PR with the changes.

The CronScheduler 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-4.1 / o-series). 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 v0.1.0

• 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.
• Cost tracking. Token usage isn't surfaced per run yet. AI Gateway analytics catch it at the request level, but the per-agent rollup is on the roadmap.
• 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 live in v0.1.0. To use it:

1. Have an error tracking integration set up. The Sentry-compatible ingest works out of the box.
2. Connect a GitHub repo to your project — the Autofixer needs write access to push branches and open PRs.
3. Configure an AI provider in project settings — paste a Claude or OpenAI API key.
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.

The full agent framework is documented in .temps/agents/README.md in your project. Temps is Apache 2.0 — free to self-host. Temps Cloud is ~$6/mo (Hetzner cost + 30%, no per-seat fees).

FAQ

Does the agent have access to my entire codebase?

The agent runs in a sandbox with a clean checkout of your repo. It has read access to source files and can edit files within the sandbox. It doesn't have access to your production environment, your databases, or your secrets — only what's in the repo.

What about secrets in env vars?

The sandbox doesn't have access to your project's runtime env vars. If your repo includes a .env.example with placeholder values, the agent can read that, but real secrets stay in Temps's encrypted store.

Can the agent run my tests?

Yes, if your repo has a standard test runner (bun test, npm test, cargo test, pytest). The agent will detect and run tests as part of the fix phase.

How much does it cost to run?

You bring your own AI API key, so cost depends on your provider and usage. A typical Autofixer run consumes 10k–50k tokens — at current Claude and OpenAI pricing, well under $1 per run.

Is the AI Autofixer GA or beta?

It's a flagship feature with production-ready UI across 8 surfaces and tests for 19/19 core services. We're shipping it as v0.1.0 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, complete with stack trace, breadcrumbs, and OTel trace context. 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 Apache 2.0. The temps-agents crate, autofixer service, and all related code are in the public repo. Temps Cloud (~$6/mo) is available if you don't want to manage the infrastructure.

Related: Read the full v0.1.0 release notes