What the agent does
The agent starts from the error you hand it and from the code that threw it. In a Worker built from Cloudflare's d1-template, the whole request path is src/index.ts: one fetch handler that runs env.DB.prepare("SELECT * FROM comments LIMIT 3"), calls .all() and passes the rows to renderHtml in src/renderHtml.ts. There is no try/catch around the query, so a missing table, a renamed column or an unbound DB surfaces as an uncaught exception and a 500 for every visitor. The agent reads the stack trace you paste, matches its frame to the line in src/index.ts, and writes down which of those failures it points at before touching anything.
Next it checks the deployed side against the repository. wrangler.json binds DB to d1-template-database with compatibility_date 2025-10-08 and observability.enabled: true. Through the Cloudflare connection, the agent lists the account's Workers and D1 databases and reads the deployed Worker's bindings, so it can tell a code bug from a configuration drift: a binding named DB in the file but something else in production, or a database whose schema never got migrations/0001_create_comments_table.sql. The template's predeploy script applies migrations with wrangler d1 migrations apply DB --remote, so a deploy that skipped that script is one of the first things it rules in or out.
Then it reproduces the failure locally in its sandbox. The dev script is pnpm seedLocalD1 && wrangler dev, while the template ships a package-lock.json and no pnpm-lock.yaml, so the agent installs with npm ci, runs npx wrangler d1 migrations apply DB --local itself, starts wrangler dev (wrangler 4.136.1 from devDependencies) and sends the failing request with curl until it sees the same error the logs showed. A fix that cannot be reproduced first is reported as a guess, not shipped as a fix.
The template has no tests, so the agent adds the setup Cloudflare uses in its sibling d1-starter-sessions-api-template: vitest with @cloudflare/vitest-pool-workers and a vitest.config.mts that points cloudflareTest at the Wrangler config. The new test sends the same request through the Workers runtime and asserts the status and body. It fixes the handler, runs npx vitest run and npm run check (tsc && wrangler deploy --dry-run), and only then pushes. It never runs wrangler deploy.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "The Worker deployed from d1-template in this repository is returning 500s. The error and stack trace from its Workers logs are pasted below. Use the Cloudflare connection to read the deployed Worker's bindings and its D1 database, and compare them with wrangler.json and migrations/. Install with the lockfile in the repository, apply the migrations locally, start wrangler dev and reproduce the failing request with curl. Fix the handler so the request succeeds, or fails with a clear status instead of an uncaught exception. Add Vitest with @cloudflare/vitest-pool-workers and a test that sends the same request, run the tests and npm run check, and open a pull request that quotes the error it fixes and says whether the cause was code or configuration. Do not run wrangler deploy or change anything in the Cloudflare account.\n\nError:\n<paste the error and stack trace here>",
"resources": [
{
"url": "https://github.com/your-org/your-worker"
}
]
}- 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 Worker's repository. In a repository shaped like d1-template it changes src/index.ts (the handler, and error handling around the D1 call where that is the right fix), adds vitest.config.mts and a test file such as test/index.spec.ts, and adds vitest, @cloudflare/vitest-pool-workers and a test script to package.json and package-lock.json. When the cause was a missing migration or a binding that differs from wrangler.json, the description says so plainly and the code change is limited to what the repository can fix; the remote step is listed for a person to run.
The description quotes the error from the logs, shows the curl request that reproduced it under wrangler dev, and names the file and line it fixed. The session's trajectory keeps every command with its output: the local migration, the failing response, the passing test, the wrangler deploy --dry-run that checks the bundle builds. If the repository has CI, its checks run on the pull request as usual.
Before merging, a reviewer checks that the fix addresses the quoted error rather than hiding it behind a blanket catch, that the new test fails without the fix, and that any configuration change in wrangler.json matches the Worker in the account. Deploying stays your step, through whatever pipeline already deploys the Worker.
Run it on every Worker error alert
Point a Cloudflare notification or your alerting tool's webhook at your own server, and on each new error signature have it send this request with the error text in input and the Worker's repository in resources. Each alert gets its own run in its own sandbox and its own pull request, so two unrelated errors do not end up in one branch. Group alerts by error message on your side first, or one noisy exception starts a run per occurrence.
Set a webhook URL on the API key and Rush POSTs run.completed or run.failed when the run's turn finishes, with the session_url, so your server can post the pull request link back to the alert. A key runs at most max_concurrent sessions at once (4 by default) and answers 429 past that, so queue alerts that arrive in a burst.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
Fixing a Worker from production errors on a laptop means tailing logs, matching a minified frame to source, running wrangler dev with a local D1 and juggling an account token that can deploy. On Rush the agent does that in its own sandbox with its own clone: it applies the migrations to a local database there, starts wrangler dev, and reproduces the request before changing a line. Your machine, your local D1 state and your Wrangler login are not involved.
The result shows its work. The pull request carries the quoted error, the reproducing request and a test that runs in the Workers runtime, and the trajectory keeps every command and its output, so a reviewer can see whether the fix was tested against the real failure. Separate errors become separate runs at once, each with a branch a person reviews before anything is deployed.
Frequently asked questions
Can the agent read my Worker's logs through the Cloudflare connection?
The Cloudflare server in Rush's catalog works with Workers and their bindings: KV, R2, D1 and Durable Objects. It does not read Workers logs, so paste the error and stack trace into the request. If you want the agent to pull logs itself, connect a Cloudflare observability MCP server as a custom server and name it in connections.
Will it deploy the fix?
No. The request tells it not to run wrangler deploy, and it only runs wrangler deploy --dry-run to check the bundle. The change reaches production when you merge and deploy it the way you already do.
How does the run get the Cloudflare connection?
Connect Cloudflare once with POST /me/connections, then add its id or name to connections in the request. A key run gets only the connections it names, so a request without it still fixes the code from the pasted error, but cannot check the deployed bindings.
My Worker has no tests. What does the test run on?
It adds Vitest with @cloudflare/vitest-pool-workers, the same setup Cloudflare's own D1 sessions template uses, so the test runs the handler inside the Workers runtime with the D1 binding from your Wrangler config. The new dependencies and the test script are part of the pull request diff.