What the agent does
The agent starts in Sentry through the connection named in the request. It finds the latest release and lists the issues that are new in it or grew after it, and for each one reads the stack trace, whether it came from the browser, the Node.js server or the Edge runtime, the route, and the tags. Which runtime an error came from matters in Next.js: a server component, a route handler, middleware and a client component each run in a different place and fail in different ways.
Then it clones the repository into its own cloud sandbox and reads how the app reports to Sentry. In a project like nextjs/saas-starter, as published, package.json has no @sentry/nextjs, so a real app built on it would add one, along with instrumentation.ts, the Sentry client config and withSentryConfig around next.config.ts. The agent reads those to learn how the release is named and whether source maps are uploaded, because without them a browser stack trace points at minified chunks instead of your files. It notes the stack: next 15.6.0-canary.59 with experimental.ppr and clientSegmentCache turned on in next.config.ts, React 19.1, Drizzle on postgres, jose for sessions and stripe 18, all on pnpm.
Next it diffs the two releases with git log and git diff between their tags or the SHAs Sentry recorded, and maps each issue to the changed files on its path. In this app the likely paths are few and readable: middleware.ts re-signs the session cookie on every GET and deletes it if verifyToken throws, lib/db/queries.ts getUser reads that cookie and queries users, app/api/stripe/webhook/route.ts verifies the signature and calls handleSubscriptionChange, and the server actions in app/(login)/actions.ts handle sign-in and team changes. A changed cookie field, a renamed column in lib/db/schema.ts without its migration, or a new Stripe event shape each leave a trace in both Sentry and the diff.
When it helps, the agent runs pnpm install and pnpm build in the sandbox on both releases, since a build-time type error or a changed route segment config shows up there. It writes a report naming the most likely change, the evidence from Sentry and the diff, and the fix, and does not change code, push or open a pull request.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Errors rose after the latest release. Through the Sentry connection, find the issues that are new or grew in that release, diff the release's commits against the previous release in this repository, and write a report naming the most likely change, the evidence for it and the fix. Do not change code.",
"connections": [
"sentry"
],
"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 Markdown report attached to the session as an artifact. It starts with the two releases compared and the issues that are new or grew, each with its Sentry link, its runtime (browser, server or edge), the route and its counts. The core of the report names the most likely commit and quotes the changed lines next to the stack frame that hits them. If a stack trace was minified because source maps were missing, the report says so, explains how the agent mapped it anyway (chunk names, route, error text), and recommends uploading source maps.
A fix section describes the change and shows a short diff where one fits, with the build or test step that would have caught it. Every Sentry query, git command and build run is in the session's transcript.
A reviewer opens the Sentry issue, confirms the frame matches the quoted lines, and decides whether to roll back the deployment or ship a forward fix. A follow-up to the same session can ask the agent to open the fix as a pull request.
Run it on every new Sentry issue in a release
Sentry alert rules can fire a webhook when an issue first appears in the latest release. Point that at a handler on your server, or have your deploy pipeline wait a few minutes after a production release and send this request when Sentry reports new issues, so each bad release gets its own investigation.
With a webhook URL on the API key, Rush POSTs run.completed when the report is ready, and your handler links it from the deployment or the pull request that shipped the release.
The use case this job follows, with its automation and trigger: Investigate an incident.
Why run it on Rush?
A Next.js error spike can come from the browser, the server or the edge, and the stack trace is only as good as the source maps behind it. The agent works across Sentry, the git history and the code in its own sandbox, with Node and pnpm to build either release, so the investigation never touches your local checkout or a shared preview.
The report cites its evidence (Sentry issue links, commit SHAs, file and line, build output) and the session's transcript keeps every step. Releases that go out several times a day can each get their own run, up to the key's concurrent run limit.
Frequently asked questions
Our stack traces are minified. Can it still find the cause?
Often, from the route, the error message and the chunk names, but with less certainty, and the report says how confident it is. Uploading source maps with withSentryConfig gives Sentry, and so the agent, the real file and line.
Does it handle errors from middleware and the Edge runtime?
Yes. It reads which runtime each Sentry event came from and looks at the matching code, such as middleware.ts or a route with export const runtime = 'edge', which has a different set of APIs from Node.js.
Does it need our production environment variables?
No. It reads the code and Sentry, and if it builds the app in the sandbox it uses placeholder values and says so in the report. Your secrets stay where they are.
We deploy on Vercel. How does it know which commit a release is?
From the release name Sentry recorded, which is usually the commit SHA when the Sentry plugin is configured, or from the deploy time and the repository's tags. The report names the method it used.