What the agent does
The agent prepares the application and asks for the demonstration before inventing a fix. In excalidraw/excalidraw, Yarn workspaces separate excalidraw-app from the packages that implement the editor. The root package declares yarn@1.22.22, and yarn start delegates to the app workspace. A browser report may belong to the surrounding application or the reusable React editor, so the agent identifies which one owns the interaction. It ends an initial turn with the running-app setup and asks your team for the route, starting scene, tool selection and exact pointer or keyboard actions.
After the team's follow-up, it repeats the interaction with synthetic scene content and records the visible failure. packages/excalidraw/components/App.tsx implements App as a React class and exposes ownerDocument and ownerWindow. Those details matter for event handling and embedded editors; replacing them with global browser objects can change which document receives an event. The agent traces the actual handler and state transition rather than converting a class component to hooks or rewriting the editor because the report mentions React.
It uses the existing interaction-test vocabulary to capture the failing sequence. selection.test.tsx renders the editor, creates scene elements and uses pointer and keyboard helpers to assert selection. vitest.config.mts runs tests in jsdom with setupTests.ts and source aliases for the workspace packages. The agent extends the closest suitable test, demonstrates the regression before its patch and checks the resulting element or application state. It avoids substituting a screenshot comparison for an assertion about the broken interaction.
The correction stays within the handler, action or state owner identified by the reproduction. The agent runs the focused test without watch mode, yarn test:typecheck and the repository's required checks, including yarn test:update where its contribution instructions require it. Any updated snapshots need review rather than automatic acceptance. It then repeats the original browser sequence, including modifier keys, zoom or selection state that made it fail. The final turn supplies screenshots, test output and the pull request; reviewers can send a further adjustment after that turn finishes.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Prepare this React application in its sandbox using the declared workspace/package-manager setup. A teammate will show the bug; finish the initial turn asking for the starting scene, route, browser/viewport, tool, zoom and exact pointer/keyboard sequence, then wait for their follow-up. Reproduce it yourself before editing. Identify whether the app shell or editor package owns the failure, add a regression test that fails on the original behavior, and make the smallest fix without unrelated component rewrites. Respect ownerDocument/ownerWindow conventions for browser APIs. Run the focused non-watch test, typecheck and repository-required checks, explaining snapshot changes. Repeat the original interaction in the browser with synthetic content and capture before/after evidence. Open a PR on the connected repository and list any verification that remains blocked.",
"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
The pull request contains a narrowly scoped interaction fix and the regression test that explains it. Its reproduction section preserves the initial scene, selected tool, modifier keys and observed result, so reviewers can repeat more than a vague instruction to drag something. Browser images show the relevant states, while the test asserts the underlying selection or element behavior.
Before merging, the reviewer checks that the test fails without the correction, that document ownership remains correct and that nearby gestures still behave as intended. Snapshot changes are explained individually if the repository's update command produces them. The session transcript keeps commands, outputs and the follow-up description, making the source of the fix visible without claiming that this example represents a completed debugging run.
Run it on every React interaction bug
Wire your bug-report webhook to send one session request with the connected repository and reproduction context. Keep the execution identifier with the report, then send the team's demonstration details after the initial turn ends. Use the session's live events or completion webhook to know when there is a result to review. A later message resumes the retained sandbox for another verification pass rather than creating a fresh, unrelated investigation.
The use case this job follows, with its automation and trigger: Steer a run as a team.
Why run it on Rush?
Canvas interactions are difficult to debug from a sentence because selection, pointer position and modifier state change the behavior. Rush gives the agent a separate app checkout and browser environment to repeat the sequence without disturbing an engineer's current drawing or working tree. Its transcript preserves the test and browser work that supports the proposed correction.
The same retained sandbox can carry a report from setup through a demonstration follow-up and a review correction. Different interaction reports can run independently within your concurrency allowance, each with its own scene and patch. The useful result is a reproducible failure tied to a test and focused diff, not an unsupported assurance that the interface now works.
Frequently asked questions
Do screenshots alone prove a canvas bug is fixed?
No, screenshots can show the visible outcome but miss the selected element or event sequence. The request also requires a regression test at the responsible interaction layer.
Will it modernize class components while fixing the bug?
No, the prompt excludes unrelated rewrites. The example editor's class component is existing architecture to understand, not a reason to expand a focused fix.
What details should the team include in the demonstration?
Include the starting scene, selected tool, zoom, pointer path and modifier keys. Also state what should happen, because a screenshot of the final selection may not reveal the intended behavior.
Can we ask for a second browser verification?
Yes, send a follow-up after the agent's turn has finished. Name the exact sequence to repeat and any changed conditions so the new evidence is comparable.