What the agent does
The agent starts from the data, not a guess. Through your PostHog connection it lists the project's error-tracking issues from the last 7 days, sorts them by occurrences, and takes the top one. For that issue it reads the exception type and message, a few sample events with their stack frames, the browser and URL each one came from, and when the issue first appeared. A TypeError that started the day of a release and only happens on /article/... URLs is a different investigation from one spread evenly across every page.
Then it maps the frames to source in a clone of your repository in its own cloud sandbox. In the Angular RealWorld app (realworld-apps/angular-realworld-example-app, Angular 21.2) the article flow is features/article/pages/article/article.component.ts, which combines ArticlesService.get(slug), CommentsService.getAll(slug) and UserService.currentUser and then reads article.author.username to decide canModify. Auth lives in core/auth/services/: JwtService keeps the token in window.localStorage['jwtToken'], and UserService moves between loading, authenticated, unauthenticated and unavailable, retrying GET /user with backoff on a 5xx. core/interceptors/error.interceptor.ts calls purgeAuth() on any 401 except /user and rethrows every error as { ...body, status }. A frame inside one of these, or a message such as Cannot read properties of undefined (reading 'username'), points the agent at the line.
Production builds use outputHashing: "all" and set no sourceMap, so unless your deploy uploads source maps to PostHog the frames name hashed main-*.js chunks. In that case the agent builds the app itself with bun run build, matches function names and the message to the source, and says in the pull request how confident the mapping is.
It reproduces the exception with a unit test before fixing it. The repository uses Vitest, not Karma: vitest.config.ts loads @analogjs/vite-plugin-angular, runs in jsdom and includes src/**/*.spec.ts, and the existing specs such as articles.service.spec.ts and user.service.spec.ts use TestBed with HttpTestingController. The agent adds a spec that feeds the payload or auth state from the PostHog events into the service or component and expects the throw, fixes the code, runs bunx vitest run until everything passes, and opens a pull request naming 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": "claude",
"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, URLs and first-seen time. Map the frames to the source in the article and auth code (src/app/features/article/, src/app/core/auth/services/, src/app/core/interceptors/); if the frames are minified, build with bun run build and match by function name and message, and say how sure you are. Reproduce it with a Vitest spec in the existing TestBed and HttpTestingController style, fix the code, and run bunx vitest run until it passes. 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 whose title names the exception. In the RealWorld app it typically changes one file in features/article/ or core/auth/services/ (a guard for an article with no author, a state UserService did not expect, an error shape the interceptor passed through) and adds a case to the matching *.spec.ts. The description has the PostHog issue, its occurrence count over the 7 days, when it was first seen, one sample stack trace, and the line in the source it maps to.
The repository's workflows on the pull request run Prettier's format:check, the Playwright end-to-end suite and the security tests, but none of them runs the Vitest specs, so the agent's bunx vitest run in the session transcript is the proof the unit test passes. The transcript keeps that run, the build and every query to PostHog.
Before merging, a reviewer checks that the fix handles the bad state rather than hiding the exception (a try that swallows it would also make the PostHog count drop), that the new spec fails on main, and that the occurrence count was large enough to be worth the change. After the deploy, the same PostHog issue should stop receiving events.
Run it on every Monday morning
Run it on a schedule: a job on your server sends the request every Monday, so the agent works on whatever exception was most frequent over the week. Each run takes the top issue at that moment, and a fixed one drops off the list once the release ships, so the next run picks the next.
Name your PostHog connection in connections on each request. Set a webhook URL on the API key and Rush POSTs run.completed or run.failed with the session_url when the turn finishes; if the agent found the cause outside the repository, the result explains it and there is no pull request to review.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
Turning an exception count into a fix means querying PostHog, reading a stack, installing the app, building it and running its specs, all in one loop. In a Rush sandbox the agent does that with Bun, the Angular CLI and the PostHog connection on its own machine, without anyone's local node_modules or browser session involved, and the mapping from a minified frame to source is something it can rebuild and check.
What you get back is a pull request you can check rather than a hunch: the PostHog numbers it chose by, the stack trace, the spec that fails before the fix, and the passing Vitest run in the transcript. Several projects or several top issues can run at once, each in its own sandbox.
Frequently asked questions
The project uses Vitest. Will it add Karma or Jasmine?
No. The RealWorld app runs its specs with Vitest through @analogjs/vite-plugin-angular, and the agent writes its spec the same way. If your app uses Karma, it uses that instead; it follows what angular.json and package.json already configure.
Do I need to upload source maps to PostHog?
It makes the mapping exact. Without them the production build's frames point at hashed chunks, and the agent maps them by building the app and matching function names and the message, then says in the pull request how sure it is.
What if the top exception comes from a browser extension or the API?
The prompt tells the agent to open no pull request when the cause is outside the repository. The session result says what it found, such as frames from an extension script or a 5xx from the API that the interceptor rethrew, so you can filter the issue in PostHog or fix the server.
Why is the PostHog connection not in the request on this page?
The request shows the task and the repository. A key run gets only the connections it names, so add "connections": ["posthog"] (or the connection's id) after you connect PostHog once with POST /me/connections.