What the agent does
The run starts from a failed Vercel deployment, with the event after the prompt. The agent reads the deployment's build log through the Vercel connection, quotes the first line that explains the failure, and clones the repository at the commit Vercel built into its own cloud sandbox.
In a React app like excalidraw/excalidraw, the build is not one package. The root package.json declares yarn workspaces for excalidraw-app, packages/* and examples/*, packageManager is yarn@1.22.22, and the root build script runs yarn --cwd ./excalidraw-app build. That one runs build:app, a vite build with VITE_APP_GIT_SHA=$VERCEL_GIT_COMMIT_SHA and VITE_APP_ENABLE_TRACKING=true, then build:version. vercel.json sets installCommand to yarn install and outputDirectory to excalidraw-app/build, so the agent follows the same steps and checks the output lands in that directory.
Vite reads excalidraw-app/.env.production during a production build, which sets the backend, library and Plus URLs as VITE_APP_ variables, so the sandbox build sees the same configuration Vercel did. The agent runs yarn install and yarn build, confirms it fails on the line from the log, and only then looks for the cause: often a type or import error in one of the workspace packages under packages/, such as packages/excalidraw or packages/element, that the app imports.
After the fix it runs the build until it passes and excalidraw-app/build is written, then runs what test:all covers: yarn test:typecheck (tsc), yarn test:code (ESLint with --max-warnings=0), yarn test:other (Prettier) and the Vitest suite with yarn test:app --watch=false. A build fix that breaks a test or adds a lint warning is not done.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "A Vercel deployment of this React 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 yarn as vercel.json says, reproduce the failure with yarn build in the sandbox, fix the cause in whichever workspace package it is in, confirm the build writes the output directory vercel.json names, run yarn test:typecheck, yarn test:code and yarn test:app --watch=false, 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 failing line from the Vercel build log, names the workspace package and file where the cause was, and shows the passing yarn build. If the fix touches a published package such as packages/excalidraw, the description says so, because that code ships to other projects as well as the app.
The checks are a Vercel preview for the branch and the repository's workflows, including test.yml and lint.yml. A reviewer checks the preview first, then reads the fix to see that it corrects the type or import rather than loosening tsconfig.json or adding an ESLint disable comment.
If the build passes in the sandbox, the cause is in the Vercel project, not the code, and the run says what differs, such as a Node version below the >=18.0.0 in engines. The session keeps every command and its output for the engineer who changes the setting.
Run it on every failed Vercel deployment
Add an automation to the Project with this prompt and a webhook trigger; Rush shows the trigger URL and signing secret once. In the Vercel project, send the failed deployment webhook to that URL, and every failure starts one run with the deployment event placed after the prompt.
Repeat deliveries of one event start one run. To decide yourself which failures get a run, receive Vercel's webhook on your own server and call POST /o/{org}/sessions only for the branches you care about, with a webhook on the API key to hear when each finishes.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
A monorepo build like this one needs the workspace install, the right yarn, and the production env file before it reproduces anything, and that setup is what slows a person down when a deployment goes red. A Rush run does it in its own sandbox and keeps every command, from yarn install to the final vite build, with its output.
The result is a pull request with a passing build, the repository's own tests and a green preview, not a guess. Each failed deployment gets its own run on its own branch, and one that cannot be fixed in code ends with what was tried.
Frequently asked questions
Does it handle yarn workspaces?
Yes. The agent reads workspaces in the root package.json, installs once at the root with yarn install as vercel.json says, and builds through the root build script, which runs the app's build in excalidraw-app.
Vercel sets VERCEL_GIT_COMMIT_SHA. Does the sandbox build need it?
The build:app script passes it to Vite as VITE_APP_GIT_SHA, which labels the build. An empty value does not fail the build, so the agent can reproduce the failure without it, and the pull request does not change how the variable is used.
Can I use Codex for this?
Yes. The request on this page sends "agent": "codex"; claude works the same way. The repository, the Vercel connection and the pull request it opens do not change.
How does the run get to my Vercel logs?
Through the Vercel MCP server, connected once with POST /me/connections and an OAuth sign-in. Name it in the run's connections, or on the saved agent the automation runs, and the agent reads deployments and build logs with it.