What the agent does
The message says a page in the issue-assignment jobs errors after saving, so the agent finds that page in the app rather than searching for a generic form. CodeTriage pins rails to 8.1.3.1 in the Gemfile, and .ruby-version is 4.0.5. The suite is Minitest. CI in .github/workflows/main.yml copies config/database.ci.yml to config/database.yml, loads the schema into Postgres 16 database triage_test, and runs bin/rake test. database.ci.yml uses the postgresql adapter, user postgres, password password. There is no config/database.yml in the repository until that copy.
The page a person can click is the repo screen. app/views/repos/show.html.slim posts to issue_assignments_path with the subscription id, on a link whose label is Send me a new issue, and it is rendered only when @repo_sub is present. IssueAssignmentsController#create loads current_user.repo_subscriptions.find(params[:id]), enqueues SendSingleTriageEmailJob with that id, and redirects to the repo with a notice. The job, in app/jobs/send_single_triage_email_job.rb, loads the subscription, runs IssueAssigner#assign!, then marks an assignment delivered and calls UserMailer.send_triage. IssueAssigner writes issue_assignments rows and selects candidate issues with a bound find_by_sql. The other public action is click_issue_redirect, a GET that records a click and sends the browser to the GitHub issue. Tests already exist: test/functional/issue_assignments_controller_test.rb covers create and the click redirect, and test/unit/issue_assignment_test.rb covers IssueAssigner. The dev server is bin/rails server. The agent signs in the way the functional test does, with the fixture user, opens the repo page, and saves.
It reproduces the error in the sandbox browser and reads the exception against those three files. The fix stays inside the action or the job that raised. The new test is a Minitest in the functional file or the unit file, asserting the redirect or the assignment row the page should have produced. The command the request asks for is bin/rails test. CI's bin/rake test runs the same suite, and the agent runs that too when the first command is not what the workflow calls. Postgres has to be up, with database.yml in place, or the suite cannot boot.
Teammates watching can narrow it: the error is on the click redirect, or only when the subscription has no open issue. The follow-up is applied, the test is adjusted, and the browser steps are repeated. The pull request description is those steps: the repo page, the control that posts, and the error. The agent does not open the pull request until that follow-up has been tried.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "A teammate reported in Slack that a page in the issue-assignment jobs shows an error after saving. The page is the repo screen: app/views/repos/show.html.slim posts to IssueAssignmentsController#create, which enqueues SendSingleTriageEmailJob. Reproduce it in the sandbox browser against bin/rails server. Find the cause in the controller, the job or IssueAssigner. Fix it with a Minitest next to test/functional/issue_assignments_controller_test.rb or test/unit/issue_assignment_test.rb. Run bin/rails test. CI uses bin/rake test against Postgres database triage_test from config/database.ci.yml; run that if it is what the workflow runs. Open a pull request that describes the steps to reproduce. Apply follow-ups before opening it.",
"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 description walks the repo page, the post, and the error, and whose diff is the fix plus a Minitest. The transcript includes bin/rails test and, when the agent followed the workflow, the schema load and bin/rake test against triage_test. The session includes the pull request URL once the agent has opened it.
A reviewer checks the new test against the functional tests that already sign in users(:schneems) and post to create. They check SendSingleTriageEmailJob still returns without mailing when no assignment is produced, and that click_issue_redirect still refuses a user id that does not own the assignment. They check database.yml was not committed.
Corrections from the team are follow-ups. Watch the browser on the session event stream. Send POST /o/{org}/sessions/{id}/messages when the turn is not running. While it is running the response is 409 TURN_ACTIVE, and the console queues the text. The parked sandbox keeps the Postgres data and the branch, and the follow-up wakes it, for 7 idle days.
Run it on every Slack message
Someone messages Rush in Slack with the bug. The run starts in their default Project, the one marked is_default, and the session source kind is slack. The org can read it. The starter or an org admin sends follow-ups and can take the sandbox browser for five minutes, one person at a time.
To start it from a server instead, POST this body: the report is input and the repository is resources. A webhook URL on the key receives run.completed, run.failed or run.cancelled, with session_url, when the turn ends. Name the Slack connection on the run when the agent should read the thread. Inside the sandbox, Slack is the slack CLI signed in as the person who connected it. Above max_concurrent in-progress runs, 4 by default, the create returns 429.
The use case this job follows, with its automation and trigger: Steer a run as a team.
Why run it on Rush?
The failure is a click on a repo page that enqueues a job, which is awkward to reproduce from a Slack screenshot alone. The sandbox runs Rails and Postgres the way CI does, opens the page, and keeps the stack trace in the transcript. The person who reported it does not need a Ruby 4.0.5 checkout.
You merge a pull request that names the steps and adds a test next to the ones the file already has. You can read which follow-up changed the diagnosis. A second report runs in a second sandbox with its own triage_test database.
Frequently asked questions
The public app may not show the error. What does the agent do?
It tries the repo page and the create action, and it writes down what the page actually did. A fork that carries the bug will fail there. If the page redirects with the notice and no exception, the agent says so and waits for a follow-up that names the failing field, rather than inventing a broken line.
bin/rails test or bin/rake test?
The report asks for bin/rails test, which runs this Minitest suite. The workflow file runs bin/rake test after loading triage_test. They execute the same tests. The agent runs the command the workflow runs when that is what proves the branch, and the transcript shows which one it was.
Does it commit database.yml?
No. The repository ships config/database.example.yml and config/database.ci.yml, and CI copies the CI file into place. The password in the CI file is the local Postgres fixture. A committed database.yml with a real password is a mistake the reviewer sends back.
Can someone in the Slack thread steer the fix?
They can if they are the starter or an org admin. They send a follow-up, or the console queues it until the turn ends. Other people in the org can watch. The sandbox is still there for 7 idle days, with the branch and the database.