What the agent does
The agent clones the module into its sandbox. On a repository like pocketbase/pocketbase it finds go.mod declaring module github.com/pocketbase/pocketbase with go 1.27, a go.sum of about 150 lines, and direct requirements such as modernc.org/sqlite v1.60.1, github.com/dop251/goja, github.com/golang-jwt/jwt/v5 v5.3.1, github.com/spf13/cobra v1.10.2, github.com/ganigeorgiev/fexpr v0.6.0, and golang.org/x/crypto. The tree also lists indirects (github.com/google/uuid, modernc.org helpers, and others). The project itself is MIT (LICENSE.md).
In the sandbox it runs go mod download (and a license inventory tool such as go-licenses or an equivalent that reads module zip LICENSE files) so every module in the graph is present. For each module it records path, version, license SPDX or LICENSE file text classification, whether it appears in the top-level require block without // indirect (direct) or only as transitive, and a path from a direct require to that module using go mod graph.
PocketBase's SQLite stack via modernc.org/sqlite brings a cluster of modernc.org/* modules; the agent expands that subgraph so a license on a transitive modernc package is not hidden under the direct sqlite require. Similarly, goja and goja_nodejs are listed with their own license rows because the JS hooks runtime is a distinct dependency from the HTTP API surface in apis/ and core/.
It writes licenses.csv with those columns and licenses.md calling out GPL, AGPL, LGPL, SSPL and unknown licenses. For each flagged module the Markdown names the direct import that pulls it in (for example a modernc.org/sqlite transitive or a cobra dependency) so replacing or isolating that direct require is actionable. Modules whose LICENSE is only a notice file without a clear SPDX id are listed as unknown rather than guessed.
No Go source is edited, no replace directives are added, and nothing is pushed. The CSV and Markdown are the only deliverables.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Clone https://github.com/pocketbase/pocketbase, resolve its full dependency tree from the lockfile, and write licenses.csv (package, version, license, direct or transitive, path from the root) plus licenses.md summarizing any GPL, AGPL, LGPL, SSPL or unknown license and which top-level dependency brings it in."
}- 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 licenses.csv and licenses.md as artifacts on the session. The CSV covers the module graph from go.mod / go.sum; the Markdown lists flagged licenses with the direct require that introduces each one.
Before a release, a reviewer sorts the CSV by license, checks each flagged path with go mod why, and decides whether a replace or a different library is needed. The transcript retains the download and license-scan commands.
Run it on every go.mod or go.sum change on main
A GitHub push webhook on those files starts this request against the new commit. Each run rebuilds the inventory from the updated graph so a transitive copyleft dependency cannot land unnoticed.
On run.completed, post the licenses.md summary to the PR or a compliance channel when the flagged section is non-empty.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
A Go license pass on a laptop means installing module sources into the local cache and running a scanner that shares that cache with other work. Rush runs the same graph resolve in a disposable sandbox and returns files you can archive with the release.
Several modules can be audited in parallel without cross-contaminating GOPATH or the module cache on your machine. Proof is the transcript plus the CSV, not a screenshot of a terminal.
Binary-distribution products like PocketBase need a clear answer about every module linked into the release artifact. The CSV is that answer for one commit of go.mod / go.sum, reproducible from the session transcript.
Frequently asked questions
Does it follow replace and exclude directives?
Yes. It uses the same go.mod the build uses, so replace and exclude lines shape the graph it inventories. The CSV versions match what go list -m all would show for that module.
Are test-only dependencies included?
Modules that appear only in tests still show up in the module graph when they are required. If you want main-package dependencies only, say so in the prompt and the agent filters with go list build constraints.
Will it modify go.mod?
No. It downloads modules and writes report files. go.mod and go.sum in your repository are not changed.
What about cgo or system libraries?
Only Go modules in the graph are listed. System libraries linked through cgo are out of scope unless you extend the prompt; the report says so when it detects cgo files.
Does it scan the JavaScript UI assets in the repo?
No. This job covers the Go module graph. Frontend package licenses would be a separate prompt against any npm lockfile the repository carries.