# Fix Nuxt Exceptions From PostHog Error Tracking

Yes. An agent takes your top PostHog exception, traces it to the Nuxt server route or component behind it, fixes it with a Vitest test and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/fix-posthog-exceptions/nuxt/), in a Project that has your repository.

## 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`

```json
{
  "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"
    }
  ]
}
```

1. **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.
2. **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.
3. **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.

## 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`.