What the agent does
The agent starts in its own cloud sandbox with your repository cloned and your PostHog project reachable through the PostHog connection, which reads error tracking alongside analytics and feature flags. It lists the error-tracking issues from the last 7 days, sorts them by occurrences and takes the first one. From that issue it keeps the exception type, the message, the first and last time it was seen, the browsers it hit and the stack frames, so the pull request can name exactly what it fixes.
Then it maps the frames to source. In a Vue 3 app like the RealWorld example, it reads package.json and finds Vue ^3.5.0, Pinia ^3.0.0, vue-router ^5.1.0, Vite ^8.0.16 and a bun.lock, so it installs with Bun. Article state lives in src/store/article.js, a Pinia store whose fetchArticle, fetchComments, addFavorite and destroyComment actions call ArticlesService, CommentsService and FavoriteService from src/common/api.service.js. src/views/Article.vue loads both in beforeRouteEnter with .catch(() => null) on each call, so a failed request leaves the store holding the default article, and the template then hands article.body to parseMarkdown, which runs marked.parse and DOMPurify.sanitize. A frame that points into minified Vite output is checked against vite.config.js, which sets no build.sourcemap; when the frames cannot be matched to a line, the agent says so rather than guessing.
Before it changes anything, the agent reproduces the exception. The repository's only test runner is Playwright (playwright test, against bun run serve on port 8080, with the shared RealWorld specs under realworld/specs/e2e), which is slow for a single store action. So it adds Vitest as a dev dependency and writes a test that drives the failing path directly: the store action with the API response PostHog's issue implies, or the view's markdown step with the value that broke it. It runs npx vitest run and keeps the failing output, which is the proof that the test reproduces the reported error and not a different one.
Then it fixes the cause in the store or the view, reruns npx vitest run until the new test passes, and runs bun run lint (ESLint on src) and vite build so the change does not break the bundle. It also runs the Playwright suite when the browsers install in the sandbox, because the article page is what those specs cover. It does not silence the exception with a broader catch; when the right fix is to show an error state instead of rendering an empty article, it does that and says why in the pull request.
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. Map its stack frames to the source in src/store/article.js, src/views/Article.vue and the components they render. Add Vitest as a dev dependency, reproduce the exception with a test, then fix the cause until `npx vitest run` passes. Run `bun run lint` and `bun run build`, and the Playwright suite if its browsers install. Open a pull request that names the PostHog issue, its occurrence count and first-seen time, quotes the failing test output from before the fix, and explains the cause. Do not hide the error with a broader catch.",
"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 on a branch the agent created. It changes the store or view where the exception starts, adds the Vitest test that reproduces it, and adds vitest to devDependencies with the updated bun.lock. The description names the PostHog issue with its occurrence count and first-seen time, quotes the test failing before the fix and passing after, and explains in a few sentences why the code threw, such as a store action that leaves article.body as undefined after a failed request.
Your repository's own checks run on the pull request as they do for any branch. The session also keeps the full record of the run: every command the agent ran in the sandbox with its output, the PostHog queries it made and the files it read, so a reviewer can trace each claim in the description back to the step that produced it.
Before merging, a reviewer checks that the test reproduces the same exception PostHog reported, not a nearby one, that the fix handles the cause rather than catching the error further up, and that the page still behaves sensibly when the API fails, for example by showing an error instead of an empty article. If the reviewer wants a different approach, a follow-up message to the same session asks for it, and the agent continues on the same branch.
Run it on every new PostHog error-tracking issue
PostHog can call a webhook when error tracking opens a new issue or an issue crosses a threshold. Point it at a small handler on your server that sends this request with the issue's id in the prompt, so each new exception gets its own run and its own pull request instead of waiting in a list.
Set a webhook URL on the API key and Rush POSTs run.completed when the turn finishes, with the session_url. Your handler can read the session, take the pull request from it and post the link back to the PostHog issue or to your team's channel, so whoever triages errors starts from a proposed fix.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
Fixing a production exception on a laptop means pulling the error data by hand, guessing which build the stack frames came from, adding a test runner the project does not have and keeping all of that out of whatever else is on the branch. In a Rush sandbox the agent reads PostHog through your connection, installs with Bun, adds Vitest and runs the tests on its own disk, and nothing on your machine changes.
The pull request carries its own proof: the test that failed before the fix, the same test passing after, and the transcript of every command. Several exceptions can be worked at once, one run each, up to the key's concurrent run limit, so the top few issues from the week do not have to wait for one person to get through them in order.
Frequently asked questions
How does the agent read my PostHog data?
Connect PostHog once with POST /me/connections as an MCP server; it signs in with OAuth. Then name it in the run's connections field, or save an agent that names it. A run gets only the connections it or its saved agent names, so the agent never sees PostHog unless you ask.
My project has no unit tests. Will it still add one?
Yes. The RealWorld app only has Playwright end-to-end specs, so the agent adds Vitest as a dev dependency and writes one focused test for the exception. If you would rather keep a single runner, say so in the prompt and it writes a Playwright spec instead.
What if PostHog's stack frames point into minified code?
The agent checks whether the build produces source maps, which vite.config.js in the RealWorld app does not configure. It maps what it can from function names and the error message, and says in the pull request which frames it could not place. Turning on build.sourcemap and uploading the maps to PostHog makes the next run more precise.
Will it change code unrelated to the exception?
The prompt limits it to the store, the view and the components they render, plus the new test and the devDependencies entry. The pull request's diff shows every file it touched, and anything outside that scope is a reason to ask for a revision before merging.