What the agent does
The run starts when Vercel reports a failed deployment: the deployment event arrives after the prompt, and the agent uses the Vercel connection to read that deployment's build log. It takes the failing line from the log rather than from the last line of output, because a Next.js build often prints the cause above a generic "Build failed" message. Then it clones the repository at the commit the deployment built into its own cloud sandbox.
In a Next.js app like vercel/commerce, the agent reads package.json and finds next build as the build script, Next.js 15.6 canary with React 19, and a pnpm-lock.yaml, so it installs with pnpm rather than npm to get the dependency tree Vercel built. next.config.ts turns on the experimental ppr, inlineCss and useCache flags, and the app router under app/ prerenders pages that fetch from Shopify through lib/shopify/index.ts.
Reproducing the build needs the same environment variables Vercel has. .env.example lists SHOPIFY_STORE_DOMAIN, SHOPIFY_STOREFRONT_ACCESS_TOKEN, SHOPIFY_REVALIDATION_SECRET, COMPANY_NAME and SITE_NAME, and lib/shopify/index.ts reads the token with a non-null assertion, so a build without them fails for a reason unrelated to the deployment. Those values come from Project secrets, which reach every session in the Project as environment variables. With them set, the agent runs the build, confirms it fails on the same line as the Vercel log, and only then edits code.
It fixes the cause in the file the log names: a type error in a server action, an import of a server-only module into a client component, a page that calls a dynamic API during prerender. Then it runs the build again until it passes, and runs pnpm test, which in this repository is prettier --check, so the fix is formatted the way the project requires.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Vercel deployment of this Next.js app failed; the deployment event follows this prompt. Use the Vercel connection to read that deployment's build log and quote the failing line. Install with the lockfile the repository uses, reproduce the failure with the build script in the sandbox using the Project's environment variables, fix the cause, confirm the build passes and the test script passes, and open a pull request that quotes the failing log line and explains the fix.",
"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 on its own branch. The description quotes the line from the Vercel build log, names the file and the cause, and shows the passing build from the sandbox. The diff is the fix and nothing else; a change to next.config.ts or a dependency version is called out separately because it affects every page.
Vercel builds a preview deployment for the pull request, so the check a reviewer looks at first is the one that failed. They confirm the preview is green, read the fix to see that it removes the cause rather than silencing it, and check that no // @ts-ignore or disabled lint rule was added to get there.
When the build cannot be reproduced, for example because the failure came from a missing environment variable on Vercel and not from code, the run does not invent a fix. It says what it tried and what differs between the sandbox and the deployment, and the session keeps every command and its output for whoever picks it up.
Run it on every failed Vercel deployment
In the console, add an automation to the Project with this prompt and a webhook trigger; Rush shows the trigger's URL and signing secret once. In the Vercel project's settings, add a webhook for failed deployments pointing at that URL. Each failed deployment then starts one run with the event after the prompt, as data rather than instructions.
Duplicate deliveries of the same event are deduplicated, so a retried Vercel webhook does not open two pull requests. If you would rather route the event through your own server, it can call POST /o/{org}/sessions with the event in input, and a webhook on the API key tells it when the run finishes.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
A red deployment usually means someone stops what they are doing, opens the log, checks out the commit and runs the build locally with the right environment. A Rush run does that in its own sandbox: the clone at the failed commit, pnpm with the lockfile, the Project's secrets as environment variables, and next build with its full output kept in the session.
The proof is a passing build and a green preview, not a claim. Several failed deployments across branches each get their own run on their own branch, and when a run cannot reproduce a failure it ends with what it found instead of a false done.
Frequently asked questions
How does the run reach my Vercel account?
Through the Vercel MCP server, connected once with POST /me/connections using "auth": {"mode": "oauth"} and a sign-in in the browser. Name it on the run in connections, or on the saved agent the automation runs, and the agent reads build logs and deployments through it.
Does it work with pnpm?
Yes. The prompt tells the agent to install with the lockfile the repository has, and vercel/commerce ships pnpm-lock.yaml, so it runs pnpm install and the build script the same way Vercel does.
My build needs secrets. Where do they come from?
From Project secrets, saved with POST /o/{org}/secrets. They reach every session in the Project as environment variables, so SHOPIFY_STOREFRONT_ACCESS_TOKEN and the others are set when the agent runs the build, and they never appear in the pull request.
What if the failure is in Vercel's settings, not my code?
Then the build passes in the sandbox and the run says so. It names the difference it found, such as a variable Vercel is missing or a different Node version, and opens no pull request for a problem code cannot fix.