See each agent's pull request land, live in Rex

When several coding agents work in Rex terminals and push to Nerudo, the person who supervises them needs to know which pull request waits for them, which one runs CI and which one closed. Until now that state reached only the agent's own context. Rex showed nothing, so the person had to read each agent's transcript.

Now the push itself opens a status pane beside the agent. The pane follows the pull request through Nerudo's queue and reports it with Rex's Program Status Protocol: one record for the pull request and one for each CI job that runs. Rex shows those records in the pane, on the tab and in the session picker. The implementation landed in PR #405 and PR #409; the Rex guide has the details.

The figures and the video come from a real Rex app and nerudo.dev, except where a figure says that it is a scripted fixture. Terminal-export figures arrange Rex's own HTML export of a pane for reading; they are not screenshots of the Rex app. The video and one still are window captures of the Rex app.

The push opens a status pane beside the agent

Run a coding agent with the Nerudo plugin hooks in a Rex terminal, in a Nerudo checkout. After a git push that opens or updates a pull request, the plugin's nerudo hook after-push opens a pane below the agent's pane without taking focus. The pane runs nd rex watch for that pull request. Since PR #409 the watch also sets the terminal's title to the pane's label, which Rex shows in the pane header, and the agent's context gets one more line that names the pane.

A real Claude Code agent with the Nerudo plugin hooks pushed PR #409 from a Rex terminal; the hook opened a pane below it without taking focus, the pane header read PR #409 r1 nerudo/nerudo, and the agent's context got one added line that named the pane.

The video is a narrated window capture of the Rex app during the push of PR #409 and its landing; waits are cut, never sped up. The narration is a natural neural voice (Deepgram Aura-2, voice luna, through Cloudflare Workers AI). The figure is Rex's export of the first push, PR #406, made before PR #409: its label row comes from Rex's block list, while Rex's header then still showed the shell's title. Both pushes were real Claude Code sessions with the plugin hooks; their prompts asked the agent to run one exact push command.

A newer revision keeps the pull request's pane

A pull request has one pane. When an agent pushes a newer revision while the pane's watch runs, the hook leaves the pane alone, and the watch follows the revision that replaces the old one. If the watch has already ended, a new pane takes the old one's place. Another pull request gets its own pane, beside the newest pull request pane.

The pane that watched PR #405 from revision 1 printed replaced by revision 2 and then reported revision 2 until it landed as 39954e1b4570, with no error state for revision 1; the pushes of PR #406 and PR #409 each got their own pane.

The revision change was recorded on T-323's own pull request. Keeping a running pane and replacing a finished one in place come from the scripted hook fixture in the outside-Rex section below.

Outside Rex, nothing changes

The hook acts only in a Rex terminal. It never starts a Rex server, it gives up on Rex after at most 6 seconds, and it always exits normally, so Rex cannot hold up a push for longer than that.

Outside Rex the hook exited 0 in 0.26 s with the receipt text and no Rex line; in a Rex terminal whose rex command could not reach a server it exited 0 in 0.55 s and added one line: no Rex status pane for PR #406: rex server is not running.

Each CI job has its own record

While a pull request's batch runs the jobs of [ci], the receipt now names the batch's running jobs, and the Pipelines rows give each job's declared number of steps. The watch reports one record per started job, titled with the job's name, with progress from its finished steps.

While the batch of PR #407 ran, Rex held one record per started job, with ci/qa, ci/runner and ci/security done and ci/rust working at 25 percent, and the root record read CI 3 of 6 jobs passed; running: rust at 40 percent; web and sbom had no record before they started.

A wait for a person says what it waits for

A pull request that needs a human seal is blocked with kind permission. Its message names the rules from the receipt's seal reasons. The watch reports only: it never approves, seals or opens an approval page.

PR #406, which edits cf/plugin/README.md, reported a blocked record of kind permission with the message waiting for human approval: governance: cf/plugin/README.md, and the watch neither approved it nor opened an approval page; its return to working after a seal was not observed, because PR #406 had not been sealed when this was written.

The still is a window capture of the Rex app with PR #406 waiting for its seal and PR #407 running CI. It predates PR #409, so its pane headers show the shell's title, not the pull request.

A stalled landing loop says why and when it tries again

Scripted: for a queued receipt whose stall was ci_unavailable after 5 tries, the watch's message read landing retries: CI is unavailable (5 tries failed), then the cleaned detail and next try in 1 s (13:53:20 UTC); no real stall happened during this work.

A closed pull request says why; a landing says where

PR #402 ended with landed on main as 461fda3b784f (landing 393) and Rex kept its done record after the watch exited, and PR #409 ended with landed on main as 77930d3b8c1e (landing 397); CI failure, timeout and other close reasons were checked with scripted receipts.

Receipt text cannot control the terminal

Seal reasons, job and step names and stall details come from the receipt, so the watch treats them as untrusted text. Before any of it reaches a status record or the pane, it removes control characters and invisible text-direction characters and keeps the protocol's length limits.

Scripted: escape sequences, text-direction overrides, zero-width characters and text over the length limits in a fixture receipt reached the pane only as plain text, and every record read back from real Rex with program_status during this work matched a report that the watch had sent.

Limits

A private repository's Pipelines rows need its share link, so there the pane names the CI jobs without their progress. A sequencer without the new receipt field shows its landing loop's status line instead of job records. Opening the approval page for the blocked person is separate follow-up work. The architecture explanation, a visual review and the release signature remain with the owner.