What the agent does
A workflow_run.failure event on the default branch starts the run. The agent reads the workflow name, head commit and failing check runs from the event, clones that commit into its sandbox, and pulls the failed job's log with gh run view --log-failed. In a Rust repository the job name matters more than usual, because a format check, a clippy lint, an old-toolchain build and a cross-compiled test are separate jobs that fail for unrelated reasons.
In a crate like sharkdp/fd, .github/workflows/CICD.yml has ensure_cargo_fmt (cargo fmt -- --check), lint_check (cargo clippy --all-targets --all-features -- -Dwarnings on stable), min_version, which reads rust-version = "1.90.0" from Cargo.toml and runs clippy and cargo test --locked on that exact toolchain, and a build matrix of 14 targets from aarch64-unknown-linux-musl to aarch64-pc-windows-msvc, most built with cross. The crate is edition 2024, and its integration tests live in tests/tests.rs with a TestEnv helper in tests/testenv/mod.rs that builds a temporary directory tree for each case.
The agent installs the toolchain the failing job used with rustup: stable with rustfmt and clippy for the lint jobs, 1.90.0 for the MSRV job. It runs the job's exact command, keeping --locked so Cargo.lock is not silently updated. A clippy failure under -Dwarnings is often a lint added in a new stable release, so the agent reads which lint fired and fixes the code rather than adding an #[allow]. An MSRV failure usually means a dependency or a standard-library API newer than 1.90, which it fixes by changing the call or pinning the dependency.
For a test failure it runs the one case by name, cargo test --locked --test tests <name>, reads the TestEnv fixture it builds, and fixes the search logic in src/ or the expectation the commit broke. Before opening the pull request it runs cargo fmt -- --check, clippy with -Dwarnings and the full cargo test --locked.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "The GitHub Actions run on the default branch failed; the event follows this prompt. Read the failed job's log and name the job, the toolchain and the failing step. Install that toolchain, reproduce the failure with the job's exact cargo command, keeping --locked, and fix the cause. Then run cargo fmt --check, cargo clippy with -Dwarnings and cargo test. Open a pull request that quotes the failing log lines and explains the fix. Do not skip, mark flaky or delete a failing test, and do not silence a lint with #[allow] unless the pull request says why.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is a pull request whose description names the job (lint_check, min_version or one build target), quotes the compiler or test error with its file and line, and shows the same cargo command failing before the change and passing after it. A change to Cargo.lock, rust-version or a workflow file is called out on its own, since each one changes what every contributor builds.
GitHub runs the whole workflow on the pull request, including the Windows, macOS and ARM targets the sandbox does not have, so those checks are the proof for platforms the agent could not run. A reviewer checks that the failing job is green, that no #[allow(clippy::...)] or #[ignore] arrived with the fix, and that a lowered MSRV or a pinned dependency is something they accept.
When a failure only shows on a target the sandbox cannot run, such as a Windows-only path test, the run reports what the log says, what it checked on Linux and the likely cause, and opens no pull request it cannot back.
Run it on every failed CI run on master
Add an automation to the Project for this repository with the prompt above and a github trigger on workflow_run.failure. Set its branch patterns to your default branch (master in fd) so pull request runs from contributors do not start one. Each failed run on that branch then starts one agent run, with the workflow name, commit and failing checks under the prompt as data.
A redelivery of the same GitHub event starts nothing new, and the automation's runs-per-hour limit keeps a toolchain release that breaks clippy across several repositories from starting more runs than you allow.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
Rust CI failures are expensive to reproduce by hand: the right toolchain, a cold target/ directory and a full build before the one failing test runs. A Rush run pays that cost in its own sandbox, keeps every command and its output, and leaves your laptop's toolchains and build cache alone.
A new stable Rust release can fail -Dwarnings clippy jobs in many crates the same morning. Each failure gets its own run on its own branch at the same time, and each ends in a pull request whose checks show the fix on every target, or a report that says what could not be reproduced.
Frequently asked questions
Will it just add #[allow] to make clippy pass?
Not by default. The prompt tells it to fix the code a lint points at and to explain any #[allow] it adds, and the diff shows every attribute change, so a reviewer sees a silenced lint immediately.
Can it fix a minimum supported Rust version failure?
Yes. It installs the toolchain named in rust-version, reruns the MSRV job's command, and changes the call or pins the dependency that needs a newer compiler. Raising rust-version is offered only as an explicit choice in the pull request, never as a quiet fix.
Does it update Cargo.lock?
Only when the fix needs it. It runs with --locked like the workflow does, so an unintended lockfile change fails instead of slipping in, and a deliberate one is listed separately in the description.
What about cross-compiled targets?
The sandbox runs Linux x86-64, so a failure on another target is reproduced where the cause is portable and otherwise reasoned from the log. The pull request's own checks then run every target in the matrix.