Canary

Canary is an independent testing service for code produced by coding agents. It runs an application, studies a proposed change, tries to break the affected behavior, and reports failures that could otherwise reach production. The focus is not on helping an agent write more code. It is on checking that work from Claude Code, Codex, Cursor, Copilot, or another coding agent before a reviewer accepts it. That separation matters when the same agent that implemented a feature also wrote the tests and declared the task complete. The reviewer can keep attention on the intent and shape of the diff while Canary takes responsibility for exercising the running behavior around it.

The product starts by reading both the diff and the surrounding codebase. It maps the user flows and application paths the change can reach, then queues tests against those areas. This is broader than checking whether the edited file compiles or whether an existing unit suite stays green. A small backend change can affect authentication, a settings page, an administrative path, or a proxy boundary, and Canary is designed to follow that blast radius. Its site shows this approach on real pull requests, including cross-organization data exposure, duplicate record creation, server-side request forgery, and destructive deletion behavior. Those are failures where the changed line can look reasonable in isolation even though the application-level outcome is unsafe.

There are two main ways to run the same verification loop. A developer can invoke Canary from a coding agent before the agent calls a task finished, or a team can run it on every pull request. For local work, Canary snapshots the uncommitted tree, starts the application in a clean sandbox, and tests the snapshot without requiring a commit or pull request. The command line entry point is canary verify. Repository onboarding starts with the npm CLI and a generated skill, so the verification request can live inside the agent workflow instead of requiring a separate testing dashboard. This local trigger gives an agent a chance to repair a failure before it creates more review work for the team.

Each run moves through reading, running, breaking, and verifying. The useful output is evidence, not a generic warning. A failure report can include the test action, the resulting break, a root cause, a suggested correction, and a regression that can run again on later changes. That gives the coding agent something concrete to repair and gives a human reviewer a reproducible case to inspect. Canary can return failures to the agent for a fix loop, while the pull-request path leaves a report where the engineering team already reviews changes. The example reports also assign severity, which helps distinguish an inconvenient edge case from a production issue such as one customer reaching another customer's private file.

The integration surface is aimed at production engineering teams. Canary lists GitHub, Linear, Sentry, Datadog, Notion, and Slack, along with Claude Code and access through pull requests, the CLI, and MCP. Those connections let it use code and operational context that already exists rather than asking teams to describe every system from scratch. The strongest fit is a team whose agents now produce more pull requests than people can deeply review, especially when escaped defects arrive later through customer messages or on-call pages. It is also relevant when developers trust their established tests but want a second system to look specifically for flows those tests never encoded.

What distinguishes Canary is its role as a separate adversarial verifier. Static analysis, unit tests, and conventional review remain valuable, but they often exercise known expectations. Canary is trying to find the unknown behavior connected to a change by actually booting the application and probing it. The reports shown on the site emphasize proof and replay, which makes the result easier to act on than a broad model-generated code review. A regression can remain armed for later pull requests after the first fix, turning a newly discovered failure into a durable check. It also publishes research on verification against production-scale repositories, giving buyers a view into how the team measures the approach.

Getting started is self-serve at the command line. The site tells users to install @runcanary/cli, run canary skills, and follow the onboarding instructions for a repository. It also offers account login and a call for teams that want to discuss adoption. Public plan prices and a clearly stated free tier are not shown, so buyers should confirm commercial terms before rolling it out broadly. The site likewise does not publish a matrix of supported application stacks, which makes a small trial on a representative repository a sensible first evaluation. That missing pricing detail is the main access caveat, while the product workflow itself is described with enough specificity to evaluate on a real change.