What’s new in Aviator

Runbooks picks up three primitives that make longer sessions safer to work in: reverting completed steps, deleting steps outright, and a proper task queue that serializes everything you do in a session.

Revert completed steps

Roll a runbook session back to any previously completed step.

• Hard-resets the working branch to the commit at the end of the target step and marks that step — plus every step after it — as Not Started, so you can replan or re-execute from that point forward.
• Triggered from the three-dot menu on any completed step, with a confirmation modal that previews exactly which steps will be reset.
• Optional "close discarded PRs" toggle cleans up any PRs that were opened by the steps you're reverting, so you don't leave orphaned PRs behind.

Delete steps

Remove steps from a runbook without touching git.

• Available from the step's action menu, and also from inside the chat session so you can trim the plan without leaving the conversation.
• Restricted to **Not Started** and **Failed** steps, so you can't accidentally delete work that's running or already completed.
• Deleting a parent step deletes its child steps in the same action, with a preview of everything that will be removed.

Task queue for every session action

Every action inside a runbook session now flows through a per-session task queue.

• Covers chat messages, step executions, /aviator revise commands, and automatic CI rework — concurrent actions no longer step on each other.
• **FIFO with priorities**: chat messages take priority over step execution, which takes priority over revisions and CI rework, so interactive feedback stays responsive even while the agent is busy.
• **Queue visibility**: a task queue card in the session UI shows the currently running task and any pending ones, with an expandable list when the queue is deep.
• **Deterministic ordering**: if you kick off a step execution and immediately send a chat message, both will run in a predictable order instead of racing.

‍

Runbooks gets a lot more hands-off this month. When CI breaks, the agent fixes it itself. When reviewers leave comments, the agent addresses them. And admins get a proper dashboard plus a kill switch.

Automatic rework on CI failure

Runbooks now watches CI on its own PRs and reruns the agent when checks fail. No more babysitting the build — the agent reads the failure logs, figures out what broke, and pushes a fix. Works with both GitHub Actions and Buildkite.

• Configure the retry budget from the Runbooks PR settings page — "Maximum Retry Attempts" (0–10) controls how many automatic rework cycles the agent is allowed before it stops and hands the PR back to you.
• Set it to 0 to keep the old manual behavior.
• Failure context (logs, failing step, checks summary) is passed back into the agent so the fix is grounded in the actual error, not a guess.

Address code review comments with /aviator revise

Runbook-generated PRs now close the review loop automatically. Leave review comments the way you normally would, then drop /aviator revise as a PR comment — the agent reads every unresolved review comment on the PR, applies the requested changes, and pushes an update. No need to restate the feedback or stitch comments together manually.

• **Works with standard GitHub review comments** — inline, file-level, and top-level review comments are all picked up.
• **Optional steering instructions**: /aviator revise also make sure we don't break the existing snapshot tests lets you add extra guidance alongside the review comments when you want to nudge the agent.
• Revision commits no longer include Claude attribution lines, so PR history stays clean.

Admin dashboard and admin-only mode

Two additions for workspace admins who want visibility and control:

• **Admin dashboard** at /runbooks/admin-dashboard with date-filtered usage stats: total runbooks created, step executions, top users and repos, and daily activity trends. Useful for tracking adoption and spotting heavy users.
• **Restrict to Admins** toggle in PR settings — when enabled, only workspace administrators can access Runbooks. Non-admins see an "Admin Access Required" screen. A straightforward way to gate the product during pilots or for compliance reviews.

Security

• **NextJS CVE-2025-66478** — patched the same day it was disclosed and deployed to both cloud and onprem.

‍

Three big additions on the Runbooks side — bring-your-own SSH sandboxes, allow/deny lists for Claude Code tools, and MCP server support — plus a handful of MergeQueue and Releases improvements.

‍

Bring your own sandbox with SSH

Runbooks can now execute steps inside any environment you can reach over SSH, instead of the Aviator-managed cloud sandbox. Point Runbooks at a host, drop in an SSH private key, and your agents will run on infrastructure you own.

• **Pick your sandbox type** from the Runbooks settings page — Cloud (managed by Aviator) or SSH (your own infrastructure).
• **Resilient connections**: automatic retry on SSH failures, reconnection support for long-running sessions, and process-state persistence across reconnects so an interrupted step picks back up cleanly.
• **Self-hosted GitHub support** is included, so SSH sandboxes work the same whether you're on github.com or GitHub Enterprise Server.

Learn more about SSH sandboxes .

‍

Allow lists and deny lists for Claude Code tools

You can now constrain exactly which Claude Code tools — and which command patterns — are available to Runbooks during planning and execution.

• **Allow list and deny list** uses Claude Code's native pattern syntax: Read , Edit , Bash(npm run build:*) , Edit(/path/to/dir/*) , and so on.
• **Denylists take precedence over allowlists**, so a deny rule is always the final word. This makes it safe to start permissive and tighten down as you discover commands you'd rather the agent not touch.
• Separate controls for the **planning** phase (where the agent generates runbook steps) and the **execution** phase (where steps actually run).

MCP server support

Runbooks now speaks MCP (Model Context Protocol), so you can plug your own tools into the agent without waiting for us to build a first-party integration. Configure MCP servers as JSON from the Runbooks settings page:

‍

• Supports stdio , sse , and http transports.
• Combine MCP with the tool controls above to give Runbooks access to your internal systems on your terms.

‍

Also in November

MergeQueue

• Refreshed the Timeline page with better density and faster loads.
• Better handling of GitHub secondary rate limits under sustained load.
• Alt access tokens can now be used for PR creation and PR comments, so teams can keep bot identities separated from human ones.

Releases

• Scheduled crons now evaluate in UTC, removing timezone ambiguity.
• Non-default-branch deployments now display the branch name, making it easier to tell release candidates and environment-specific builds apart at a glance.

Introducing Runbooks - a multiplayer AI coding platform that enables collaborative spec-driven development. Some key features:

Spec-driven development

Runbooks is purpose-built for complex brownfield projects that involve understanding large codebases. Aviator agents internally run Claude code to analyze the code and prepare multistep plans (called Runbooks).

Share and collaborate

Invite engineers, PMs, and all stakeholders to share and collaborate on these Runbooks. Plan together, get feedback, and reuse existing templates.

Background agents

Aviator manages ephemeral sandboxes that check out the repository and run Claude code in the background. These sandboxes can run custom environments and can scale to hundreds of agents instantaneously for parallel execution.

Institutional knowledge

Agents manage all learnings into editable context files that are used for future execution. Using these auto-generated institutional knowledge graphs, the agents build up business context and get smarter over time.

Templates

The Runbooks can be published and reused. Write once, execute N times to standardize common operations or large replicable migrations. It also comes pre-built with a Runbook Library with tried and tested templates.

Additional Resources

• Read our docs
• Why Runbooks

Interested? Join our beta .

Introducing Aviator Agents - an LLM-based agentic framework to perform large scale code migrations in your repositories.

‍

How it works

These agents emulate human patterns to perform migrations by:

• finding references and documentation
• understanding dependencies
• breaking down large chunks of code, and
• verifying build status.

Aviator Agents plan out steps to perform a task and iterate to improve accuracy.

Unlike most LLM based frameworks, Aviator Agents is an end-to-end framework that connects directly with GitHub. This eliminates the need to set up a custom environment and build process.

Models

It directly integrates with GitHub and supports Open-AI o1, Claude Sonnet 3.5, Deepseek R1, and Llama 3.1 models.

Early access

Aviator Agents is currently in private beta. If you are interested in trying it out please reply back or sign up on: aviator.co/agents

‍