What the agent does
Through your PostHog connection the agent lists the project's error-tracking issues from the last 7 days and takes the one with the most occurrences. It reads the exception type and message, sample stack frames, the page URL on each event, and whether the events came from the browser or the server. In a Nuxt app that last detail matters: the same component renders once on the server and again on the client, and an exception thrown during server rendering shows up with Nitro frames rather than Vue ones.
It then maps the frames to source in a clone of your repository in its own cloud sandbox. In the Nuxt UI dashboard template (nuxt-ui-templates/dashboard, Nuxt 4.6 with @nuxt/ui 4.11) the data comes from four server routes under server/api/: customers.ts, mails.ts, members.ts and notifications.ts, each a defineEventHandler that returns an in-file array. Pages fetch them with useFetch: customers.vue from /api/customers, inbox.vue from /api/mails, settings/members.vue from /api/members, and NotificationsSlideover.vue from /api/notifications. The agent reads both ends, because a route that returns a shape the page does not expect throws in the page, not in the route.
The template shows how that happens. app/types/index.d.ts declares Notification.sender as a User, whose email is required, but the second entry in server/api/notifications.ts has a sender with only a name, and NotificationsSlideover.vue binds notification.sender.avatar straight into UAvatar. The arrays are not typed against the interfaces, so pnpm run typecheck does not catch the difference. The agent checks for this class of mismatch first when the top exception is a TypeError reading a property of undefined, and decides whether the route should return the full shape or the component should handle a missing field.
The template has no test runner, so the agent adds Vitest as a dev dependency with pnpm (the packageManager is pnpm@12.11.2), writes a test that calls the route's logic or renders the component with the data from the PostHog events and expects the failure, then fixes the code and runs npx vitest run, pnpm run lint and pnpm run typecheck. It opens a pull request that names the PostHog issue and its occurrence count.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Use the PostHog connection to list this project's error-tracking issues from the last 7 days and take the one with the most occurrences. Read its exception type, message, sample stack frames and page URLs, and note whether the events are server or client side. Map the frames to the source in the server API routes under server/api/ and the pages and components that useFetch them, and check the route's data against the interfaces in app/types/index.d.ts. Add Vitest as a dev dependency with pnpm if the project has no test runner, reproduce the exception with a Vitest test, fix it, and run npx vitest run, pnpm run lint and pnpm run typecheck until all pass. Open a pull request that names the PostHog issue, its occurrence count and first-seen time, and quotes one sample stack trace. If the cause is outside this repository, say so in the session result and open no pull request.",
"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 named after the exception. In the dashboard template it changes a route under server/api/ or the component that reads it (for example NotificationsSlideover.vue), tightens the type in app/types/index.d.ts if the route data and the interface disagreed, and adds a test file. Because the template had no tests, the pull request also adds vitest to devDependencies, a test script in package.json and the matching pnpm-lock.yaml change, and says so in the description so a reviewer can keep or drop the runner on purpose.
The description carries the PostHog issue, the occurrence count over 7 days, the first-seen time, a sample stack trace and the source line it maps to. The template's ci.yml runs pnpm run lint and pnpm run typecheck on Node 24 for the pull request; it does not run tests until someone adds that step, so the agent's npx vitest run in the session transcript is the record that the test passes.
Before merging, a reviewer checks that the fix addresses the shape mismatch at its source (a route that returns incomplete records should be fixed there, not patched with optional chaining in every component), that the new test fails on main, and that the added dev dependency is one the team wants. After the deploy, the PostHog issue should stop receiving events.
Run it on every weekly error review
Send the request from a scheduled job before the team's weekly error review, one per PostHog project, with your PostHog connection named in connections. The agent takes the top issue at that moment, so each week's run works on whatever is now most frequent, and the review starts with a pull request instead of a chart.
With a webhook URL on the API key, Rush POSTs run.completed or run.failed with the session_url when the turn finishes. A key runs at most max_concurrent sessions at once (4 by default) and answers 429 to one more, which matters if one job covers many apps.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
A Nuxt exception can come from server rendering, the client, or the gap between a route and the page that fetches it. Following it means running pnpm install, nuxt prepare, the dev server or a build, and a test, with the PostHog data open beside the code. In a Rush sandbox the agent does that on its own machine, so nobody's local Node or pnpm store changes, and adding a test runner to try a fix touches only the branch.
The pull request is checkable: it names the PostHog issue it chose and why, shows the test that fails before the change, and the transcript has the Vitest, lint and typecheck runs. Several apps or several issues can be handled at once, one sandbox each.
Frequently asked questions
My Nuxt app has no tests. Will it add a framework?
Only the smallest one that proves the fix: Vitest as a dev dependency and a test script, listed in the pull request description. If you would rather not add it, say so in the prompt and the agent reproduces the exception in the sandbox browser instead and describes the steps.
Does it handle server-side exceptions as well as client ones?
Yes. It reads whether each PostHog event came from the server or the browser and follows the frames into server/api/ or the Vue components accordingly. A server-rendering error usually points at the data a route returned, so it reads the route and the page together.
Why did typecheck not catch the bug?
In the template the data arrays in server/api/ are not annotated with the interfaces in app/types/index.d.ts, so a missing field is not a type error. The fix often includes annotating the array, which makes pnpm run typecheck catch the next one.
Why is the PostHog connection not in the request on this page?
The request shows only the task and the repository. A key run gets only the connections it names, so add "connections": ["posthog"] (or the connection's id) once PostHog is connected through POST /me/connections.