Reviews & runs

A run is one unit of agent work: a pull-request review, a whole-project analysis, a scheduled analysis, or an answer to a code question. Ozone records every run — what triggered it, what the agent did, what it found, and what it cost.

What happens during a review#

1. A sandbox starts. Every run gets a fresh, throwaway environment. Nothing is shared between runs or between customers.
2. The code is cloned into it. A pull-request review clones the repository under review, plus sibling repositories from the same project as read-only context where you've turned that on. A whole-project run has no subject repository at all: every connected repository is cloned as an equal peer and the agent works from the root above them, so it can read across all of them.
3. The agent investigates. It reads files, searches, follows call paths, and checks git history — a real investigation of the change, not one pass over the diff. It weighs what it sees against your knowledge library.
4. Findings arrive as the agent confirms them, each tied to a file and line, each explaining how the code fails.
5. The result lands: Ozone updates the PR comment, the findings reach your dashboard, and the sandbox is destroyed.

For a PR review, the sticky comment shows review in progress the moment the run starts — before the sandbox boots — so the PR always shows that Ozone picked the change up.

The run page shows the whole investigation as a live feed: every tool call, every delegation, every finding. Reviews usually take a few minutes, and a run gets 25 minutes of wall clock by default. A configured skill can request more, up to the four-hour host ceiling.

How Ozone handles your code#

The clone lives only inside that run's sandbox, and the sandbox is destroyed when the run ends — your repository is never stored on Ozone's servers. What Ozone keeps is the review itself: the findings and the run transcript, the record of what the agent read and did, which is what powers the activity feed, follow-up questions, and run resumption. Ozone never pushes to your repositories — it writes only pull-request comments, checks, and reactions — and your code is never used to train AI models. Model requests are processed by Microsoft Azure OpenAI; product analytics never include repository content, prompts, or finding text. The privacy policy has the full picture.

How hard Ozone looks#

Ozone sizes the review to the change. A three-file, ten-line diff gets a quick pass; a large one gets the full treatment, with more parallel investigation. Touch anything sensitive and the review jumps to full effort whatever its size: authentication, authorization, security, crypto, permissions, IAM, secrets, migrations, CI workflows, dependency manifests, Dockerfiles, Terraform, and Wrangler config. Lockfiles, vendored code, and generated output don't count toward the size.

Ozone also reads your repository's own instructions. When a pull-request or single-repository review finds an AGENTS.md, CLAUDE.md, GEMINI.md, or CONTRIBUTING.md at the repository root, the agent is pointed at it before it starts, so your conventions shape the review. Whole-project runs work from the root above your repositories and don't pick these up.

The PR comment#

Ozone keeps one comment per pull request and updates it in place on re-reviews, so bot comments never pile up. It appears as the review starts, in a review in progress state linking to the live run page, then fills in with results. When a newer review overtakes an older one, the older run leaves the comment alone rather than writing stale results over fresh ones.

Ozone also puts an Ozone security review check on the pull request. It stays in progress while the agent works, then passes when the review finishes, fails when the agent cannot finish, and reports as cancelled when the PR closes or a new push supersedes the review. Repository admins can make that check required for protected branches. Ozone is a GitHub App rather than a GitHub Action, so it uses none of your CI minutes.

The finished comment carries the summary and each finding with its severity (🔴 High, 🟠 Medium, 🟡 Low, ℹ️ Info), plus Mark resolved and Ignore links and a link to the full finding. Those links are signed for that finding but still need a signed-in Ozone member of the owning organization; clicking one shows a confirmation before anything changes, and Ozone records the change against that member. A link to an already-triaged finding does nothing and says so.

A few messages arrive as their own comment rather than in the sticky one: answers to @ozone questions, and the note Ozone posts when a plan limit stops a review.

Talking to Ozone on the PR#

Anyone with write access to the repository can steer Ozone from a PR comment:

The mention must open the comment and be the whole instruction; @ozone mid-sentence does nothing. Ozone ignores comments from bots, and it runs nothing for people without write access.

Questions need a finished review to build on. Ask one on a pull request Ozone hasn't reviewed and it replies saying so and suggests @ozone review — it won't start a review on its own.

Two things to know about mentioning an app:

• Type the name in full. GitHub's @ autocomplete only suggests people, never apps — ozone missing from the picker is normal, and the mention still works.
• Ozone acknowledges instantly. Within a few seconds of a review request or a question, Ozone reacts with 👀, or 😕 if a plan limit blocks it. Help replies get no reaction, only an answer. If nothing comes back at all, check that the repository is connected to a project.

Triggering runs yourself#

• From the assistant: ask for it — "run a full analysis of checkout focusing on auth." You can target a whole project, one repository, or a pull request and add specific instructions.
• On a schedule: see Schedules.
• From the API or MCP: see API & MCP.

Instructions run to 4,000 characters and lead the review; the agent still reports anything else serious it finds. Leave them empty for the standard review. A run can also drive a real browser when it needs one, so "test the login flow against the running app" works.

Skills#

A skill is a named method the agent can follow. Most are ambient — Ozone picks the right one for the job. One you invoke yourself, by naming it with a slash token in a run's instructions:

/security-analysis focus on the payment routes

/security-analysis runs a first-principles audit of the whole repository rather than a diff review. It maps entry points and trust boundaries, works out where the sensitive assets are, then probes each surface in proportion to its risk and drives every strong suspicion to confirmed or refuted before reporting. It is the run Ozone starts for you during onboarding.

Because it does more work than a normal review, it can run for up to four hours with a $400 cap. Ozone emails you when it finishes. The cap shrinks to fit your balance and spend limit.

Some details worth knowing:

• Only the instructions you write can invoke it. Repository files, PR text, knowledge documents and follow-up comments cannot, so nothing under review can talk a run into a bigger budget.
• It works anywhere instructions do — the assistant, a schedule, or the instructions field over the API. A nightly schedule that opens with /security-analysis buys the four-hour budget every night, so watch what that costs.
• The name counts anywhere in the instructions, not only at the front: "review the payment routes, then /security-analysis" invokes it just the same. It is stripped before the agent reads the rest, so /security-analysis focus on auth arrives as "focus on auth".
• An unrecognised name is plain text. The run proceeds normally.

Reading the result#

Beyond findings, a run can file reports — notes that don't belong in your worklist but are worth reading, such as code the agent couldn't reach. They sit on the run page alongside the activity feed and the Copy fix instructions action.

Run lifecycle#

A run is queued, then running, and ends completed, failed, or cancelled. You can cancel a queued or running run from its page. Ozone cancels runs itself when they stop mattering: closing or merging a PR cancels the review in flight, and new commits supersede reviews of the older commit.

A failed run still bills for the work it did before it failed, and it keeps the rolling-24-hour slot it took. A run that dies before doing anything costs nothing.

Limits#

How many runs you can have at once, and how many you can start in a rolling 24 hours, depend on your plan. Above those ceilings a run waits in a queue rather than failing. When a run truly cannot start — the queue is full, billing has lapsed, your credit is spent, the spend limit is reached — the dashboard and the PR say so rather than failing quietly. Answers to @ozone questions are exempt from the rolling allowance.