What the agent does
The agent clones the app into its own cloud sandbox and reads what it is working with before it changes anything. In a project like lujakob/nestjs-realworld-example-app, package.json pins NestJS 7, TypeORM 0.2, TypeScript 3.8 and Jest 25, and the lockfile is a v1 package-lock.json, so the agent knows the install is old enough to carry advisories. It installs the dependencies, runs npm audit to get the starting list, and runs the test suite (jest --config=jest.json, which the test script names) once so a later failure can be told apart from one that was already there.
Then it works the advisories one at a time, smallest safe upgrade first. For a direct dependency it bumps to the lowest version that clears the advisory without crossing a major boundary it cannot justify; for a transitive one reached only through another package it reaches for an overrides entry rather than forcing an unrelated direct bump. It records for each advisory which package moved, from which version to which, and whether the fix was a direct upgrade or an override.
After each change it runs the suite again. The RealWorld app's one spec is src/tag/tag.controller.spec.ts, which boots a TypeORM module, so the agent sets the sandbox up to let that run or notes where a bump needs a code change to keep compiling, since TypeScript 3.8 and TypeORM 0.2 are sensitive to version moves. An upgrade that breaks the build or the test is backed out and reported as one that needs a person, rather than left half-applied.
When the advisories are worked through it runs npm audit again to capture the ending state, commits the changed package.json and lockfile, and opens a pull request. The description carries both audit outputs, before and after, and the per-advisory list of what moved, so a reviewer sees what was cleared and what, if anything, could not be without a larger change.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Run npm audit. For each advisory, apply the smallest upgrade that fixes it, preferring a direct bump and using overrides only for a transitive dependency with no direct upgrade. Run the test suite after each change; back out any upgrade that breaks the build or the tests and note it as needing a person. Run npm audit again, then open a pull request whose description carries both audit outputs and a list of each package that moved, from which version to which.",
"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 against the repository. Its diff is the changed package.json and lockfile, and its description carries the two npm audit outputs, before and after, next to a list of each package that moved with its old and new version and whether it was a direct upgrade or an override. A reviewer reads the two audit outputs to see exactly which advisories cleared.
The session transcript keeps every command: the install, the first audit, the test run after each bump, and the final audit. An upgrade the agent backed out because it broke the build or a test is listed as needing a person, with what broke, so the pull request does not silently skip a hard case or hide a failure behind a green summary.
Before merging, the reviewer checks that the test suite the agent ran covers the code the bumps touched, that no override masks a problem that really needs a direct upgrade, and that any advisory left open is one they accept for now. Because the sandbox still has the installed project, a follow-up message to the same session can ask the agent to attempt a harder upgrade with the code changes it needs.
Run it on every Monday morning
Run it on a schedule so advisories do not pile up. An automation with a weekly schedule trigger sends this request every Monday, and each run starts from a fresh clone of the default branch, so the audit reflects the lockfile as it is that week.
Set a webhook URL on the API key and Rush POSTs run.completed when the turn finishes, with the session_url and the pull request. Your server can route the pull request to the right reviewer or, when the run found nothing to fix, drop it, so a human looks only when there is something to merge.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
Clearing audit advisories by hand means bumping a package, reinstalling, running the suite, and backing the bump out when it breaks, over and over, on a machine you then have to put back. In a Rush sandbox the agent does every install and every test run on its own disk, tries as many upgrades as the advisories need, and your checkout and global toolchain are never touched.
A dependency pull request is only safe to merge if you can see the before and after. Because both npm audit outputs and every test run are in the transcript and the description, the reviewer sees which advisories cleared and that the suite still passes, rather than trusting a one-line summary. Several repositories can be swept at once, one run each, up to the key's concurrent-run limit.
Frequently asked questions
Will it make a major version jump to clear an advisory?
It prefers the smallest upgrade that fixes each advisory and avoids crossing a major boundary it cannot justify. When only a major bump clears an advisory and that breaks the build or tests, it backs out and lists the advisory as needing a person rather than forcing it.
How does it handle a transitive dependency?
For an advisory in a package reached only through another, it reaches for an overrides entry in package.json rather than forcing an unrelated direct bump, so the fix is scoped to the vulnerable transitive package.
Does it run the tests?
Yes. It runs the suite once at the start for a baseline and again after each change, using the project's own test script. An upgrade that breaks the build or a test is backed out and reported, so the pull request it opens keeps the suite passing.
Can it work on a private repository?
Yes. Install the Rush GitHub App on the repository and keep the resource as {"url": "https://github.com/your-org/your-app"}. The agent clones through that installation, works in its sandbox, and opens the pull request through the same App.