What the agent does
The agent starts with the log, not the code. From the workflow_run event it runs gh run view <run id> --log-failed, names the failing job and step, and quotes the first real error, because a Next.js build log buries it under a page of route output. In an App Router app like vercel/commerce the checks a workflow can run are the ones package.json defines: pnpm build (next build), pnpm prettier:check, and pnpm test, which in this repository is an alias for the Prettier check. The repository ships no workflow file of its own, so the agent reads yours to see which of those steps ran, on which Node, and with which environment variables.
Then it matches the toolchain. The app pins next 15.6.0-canary.60 with React 19.0.0, TypeScript 5.8.2 and Prettier 3.5.3 with prettier-plugin-tailwindcss, installed with pnpm from pnpm-lock.yaml. tsconfig.json sets strict and noUncheckedIndexedAccess, so an array index or a record lookup that a contributor did not guard fails type checking in next build rather than at runtime. next.config.ts turns on experimental.ppr, inlineCss and useCache, which change what the build type-checks for cached functions. And the build fetches from Shopify: lib/shopify/index.ts reads SHOPIFY_STORE_DOMAIN and SHOPIFY_STOREFRONT_ACCESS_TOKEN from the environment inside shopifyFetch, so a job without those secrets fails on data fetching with an error that looks nothing like the commit's change. The agent tells those cases apart from the log before it edits anything.
With the failure reproduced in its sandbox with the same command, it reads the code the error names. The cart is the code most pull requests touch: components/cart/actions.ts holds the server actions addItem, removeItem, updateItemQuantity, redirectToCheckout and createCartAndSetCookie, each reading the cartId cookie through cookies(), calling addToCart, removeFromCart, updateCart or getCart from lib/shopify, and invalidating with updateTag(TAGS.cart) from next/cache; components/cart/cart-context.tsx keeps the optimistic cart with useOptimistic and a reducer over UPDATE_ITEM and ADD_ITEM. A type error here is usually a Cart or CartItem field from lib/shopify/types.ts that the change assumed present, and the agent fixes it against the GraphQL fragment in lib/shopify/fragments/cart.ts rather than with a cast.
It fixes the cause, reruns the failing command, then runs the other scripts the workflow runs, pnpm prettier:check and pnpm build, so the fix for one step does not turn the next one red. Formatting is applied with pnpm prettier on the changed files only. If the job failed for a missing secret, the agent changes no code: it says so in its answer, names the variable from .env.example, and opens nothing.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "The GitHub Actions workflow on this branch failed; the workflow_run event is at the end of this prompt. Read the failed job's log with gh run view <run id> --log-failed, name the job and step that failed, and quote the first real error (a TypeScript error from next build, a Prettier diff, or a fetch failure from lib/shopify). Read the workflow file to see which package.json scripts it runs and on which Node. Install with pnpm from the lockfile, set the SHOPIFY_* variables from .env.example to placeholder values if the step needs them to start, and reproduce the failure with the same script. Fix the cause in the code (fix a type error against lib/shopify/types.ts and the fragments rather than with a cast; change a test or config only if it is wrong, and say so), then run pnpm prettier:check and pnpm build until both pass, and open a pull request against the failing branch that quotes the error it fixed. If the failure is a missing secret or a Shopify outage rather than code, say so and open no pull request.\n\nEvent: <workflow_run payload>",
"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
A pull request against the failing branch, with the fix in the component, action or lib/shopify module the error named and the job, step and quoted error in the description. It shows the command failing and then passing in the sandbox, lists pnpm prettier:check and pnpm build with their results, and the session's trajectory keeps every command with its full output. The workflow runs again on the pull request.
When the log shows a fetch error from shopifyFetch rather than a compile error, the answer says which variable the job lacked and opens no pull request, because the fix is in the repository's secrets, not its code. When the failure is a Prettier diff, the pull request is the formatted files and nothing else.
A reviewer checks that a type fix narrows the data at the fragment or type definition rather than casting at the use site, that next.config.ts and tsconfig.json are untouched, and that the change still invalidates the cart tag after each mutation.
Run it on every failed Next.js build
Add an automation to the Project with this prompt and a github trigger on workflow_run.failure; each failed run of your build workflow starts one run with the event under the prompt, and only work by owners, members and collaborators fires it. Or send GitHub's workflow_run webhook to your own server and send this request with https://github.com/<owner>/<repo>/tree/<head_branch> as the resource.
Exclude the agent's own branches so a failed fix does not trigger itself, keep each workflow_run.id with the execution_id to drop redeliveries, and use the run.completed webhook from Rush to post the pull request link on the contributor's pull request.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
A red next build is often not what it looks like: a strict-mode type error two files away from the change, a Prettier plugin reordering classes, or a Shopify fetch that only fails where the secret is missing. The agent reads the log for the first real error and reproduces it in its own sandbox with the same pnpm command, without touching your checkout or your .env.
What comes back is checkable: the quoted error, the trajectory with every pnpm run and its output, and the workflow rerunning on the pull request. Several failing branches each get their own run at once, and nothing merges without a reviewer.
Frequently asked questions
The repository has no test runner. What does it run?
The scripts your workflow runs. In vercel/commerce that is pnpm build and pnpm prettier:check, since pnpm test is an alias for the latter. If your fork added Vitest or Playwright, the agent runs those scripts too, because it reads the workflow file rather than assuming.
Does it need my Shopify credentials to build?
To finish next build on pages that fetch at build time, yes, and it does not have them. It sets placeholder values only to get the step to start, reports a fetch failure as a secrets problem rather than a code problem, and never writes a credential into the repository.
Will it suppress a type error with a cast or a ts-ignore?
No. The prompt asks for the fix at the type or the fragment, and a // @ts-ignore or an as any would show in the diff. Where the data really is optional, it adds the guard where the value is read.
Can it fix a failure on a canary Next.js version?
It installs exactly the version in pnpm-lock.yaml, canary included, so it sees the same compiler behavior the runner saw. If the failure comes from the canary itself rather than the change, it says so and does not pin a different version on its own.