Rig HQ: a pixel office for your rigs

[dmelo]

Thanks for OpenRig. I've been running four rigs on one box for a week, and the queue and seat model has held up well. I wanted to see them, so I built a small viewer on the daemon's HTTP API:

• Each rig is a room. Seats sit at their desks while working and go to the coffee room when idle.
• Seats that need you walk over and line up at your office door.
• Queue handoffs fly between desks as envelopes.
• It's read-only with no dependencies, and --demo runs it without a rig.

https://github.com/dmelo/rig-hq

Two questions:

1. Is it OK to build on /api/ps, /api/rigs/:id/nodes (the activityState field) and /api/events, or are they likely to change?
2. Would you link it from the README? Your CONTRIBUTING mentions linking to integrations that live in their own repos.

A few things I noticed while building it, in case they're useful:

• /api/events replays the full history on every connect: about 7.5 MB here. A way to start from "now" would help tools like this.
• rig send messages aren't recorded anywhere I could find, so only queue traffic can be shown.
• rig ps reported 0 seats needing attention while several were sitting at approval prompts, which the seats' own agentActivity reported as needs_input.

[mvschwarz]

Thanks, @dmelo, for running four rigs on one box for a week, for building Rig HQ on the live API, and for the three findings with numbers. One answer on the replay now: in 0.6.5, /api/events honours a Last-Event-ID header, so a client that remembers the last event seq it saw resumes from there instead of replaying everything. Without the header it replays the full history. Your other two notes are with the team, and we'll answer your two questions, about building on these endpoints and about a README link, in this thread.

[dmelo]

Thanks again, the source pointers saved me real guessing. Here's my homework:

Done in Rig HQ, thanks to your answers:

• rig send: my mistake, it is recorded. I'd searched the database for stored messages and never looked at outbox_entries. Rig HQ now reads the outbox, and 32 direct messages from the previous few hours showed up.
• Last-Event-ID: reconnects resume now. A full replay is 9.7 MB here; resuming from a recent ID was about 1 KB.
• The README says "tested with OpenRig 0.6.5" and tolerates new fields and unknown states.

The attention count: versions are OpenRig 0.6.5 (5ea35e9), Claude Code 2.1.291 and Codex CLI 0.154.0. A watcher took 5 samples overnight, and in all 5 the rig ps attention count did count the waiting seat. So I couldn't reproduce the zero; please treat my original report as unconfirmed.

The samples did show something else. For a Codex seat at a permission request, the two activity views disagree:

{ "takenAt": "2026-10-06T20:59:06Z", "session": "review-codex@fc-wt2", "rigAttentionCount": 1,
  "agentActivity": { "state": "needs_input", "reason": "permission_request", "evidenceSource": "runtime_hook", "stale": false },
  "activityState": { "activity": "working", "display": "working", "needsInput": { "count": 0, "reason": null }, "decidedBy": "window-sampling" } }

Same picture in the other three Codex samples. In the one Claude sample, everything agreed (needs-input, count 1). From the source, this is by design: Codex's "nothing pending" isn't trusted yet, so seatNeedsAttention falls back to the hook. But Rig HQ followed activityState and showed those seats as working. It now mirrors seatNeedsAttention, guessing trust by runtime.

Two questions:

1. Could /api/rigs/:id/nodes expose the per-seat attention result (or the needs-input trust) so tools don't have to copy that rule?
2. Is multi-human support still planned? The human registry calls itself "single-human", with multi-human management marked as 0.5.7 scope. I'm thinking about letting a coworker use Rig HQ too, and telling his actions apart from mine.

[mvschwarz]

Thanks, @dmelo, for following up on each pointer and coming back with numbers: 9.7 MB for a full replay against about 1 KB for a resume. Thanks too for withdrawing the zero-attention report after five samples. Your read of the Codex sample is right: when the arbitrated view has no authoritative answer, the attention count falls back to the hook's needs_input, which is why a Codex permission request counts while activityState says working. The "multi-human management is 0.5.7 scope" label in the human registry is out of date: it names a release long past and doesn't tell you whether multi-human support is planned. On your two questions, exposing the per-seat attention result on /api/rigs/:id/nodes and multi-human support, we'll check both and reply here.

[mvschwarz]

Following up on your two questions, @dmelo.

1. The per-seat attention result on /api/rigs/:id/nodes: we agree it belongs in OpenRig's API. OpenRig has the evidence that decides whether a seat needs attention, and every client guessing that by runtime is the wrong place for the rule. Today each node's activityState carries activity, display, needsInput, decidedBy, seq and lastSwap; its needsInput is the arbitrated answer alone, without the hook fallback the attention count uses, and nothing says whether the answer rests on evidence or on that fallback. The direction is to expose the attention result and that basis through the existing nodes data, consistent with the attention count in rig ps, with no new endpoint. It's recorded as a requirement next to Codex PermissionRequest hooks mark seats needs_input even when the approval is auto-reviewed #896, the open issue about the same Codex permission-request case behind your sample, with no release named.
2. Multi-human: it's still a direction, with no release promised. Your case, letting a coworker use Rig HQ with their actions told apart from yours, is now recorded as a concrete use case for it. One question that would help: do you need that attribution only inside Rig HQ, or for actions made through OpenRig itself, with your coworker registered as a second person?

[dmelo]

Thanks, that's great news on both. Putting the attention result and its basis into the nodes data is exactly what I hoped for, and I'll switch Rig HQ to read it as soon as it lands.

On your question: through OpenRig itself, with the coworker registered as a second person. I want Rig HQ to stay a viewer and a channel, not something with its own truth. If attribution lived only in Rig HQ, anything he did through the rig CLI, Slack or his own terminal would stay anonymous. With both of us registered in OpenRig, every route records who acted, and Rig HQ just shows it.

[mvschwarz]

Thanks, @dmelo, that's the answer we needed. Attribution through OpenRig itself, with your coworker registered as a second person, keeps Rig HQ a viewer and a channel, and means every route records who acted: the rig CLI, Slack and a terminal as well as Rig HQ. Multi-human is still a direction with no release named, and we'll post here if that changes.