mvschwarz/openrig

Request Let a --human-intent update queue item be posted into the Slack thread of an earlier item, for example with rig queue create … --human-intent update --reply-to <qitemId>. Why Every rig queue create --destination <human>@external starts a new top-level post. Follow-ups about the same piece of work, such as "the pull request you approved is merged" or "the fix is live", end up as separate posts. The human loses the thread of the conversation, and a busy channel gets hard to follow. --human-detail-file only adds a reply under the new post. Why it is safe for updates only Thread reuse is deliberately scoped per qitem (daemon/dist/domain/gateway/slack/slack-subsystem.js:224-229): two decision qitems sharing one root would make an inbound reply ambiguous and could resume the wrong human gate. Updates never take a reply (makeHumanReplyResolver returns not-applicable for humanIntent === "update"), so posting an update under an earlier root adds no ambiguity. Decisions would keep thei

Summary Every managed runtime: pi seat reports agentActivity.state = "unknown" permanently, whether it is working or idle. The pi runner does post activity hooks to /api/activity/hooks, but its payload never includes the occupant generation field. The daemon's activity store gates freshness on generation (W2a-1). When the node has a live occupant generation and the recorded hook's generation is null, it returns unknown (generation_unverifiable). As a result, idle/working detection, idle-gate watchdogs and "parked" diagnosis are blind for all Pi seats. Environment OpenRig CLI/daemon 0.5.14 (cc75efdd) pi 0.87.1 (~/.local/bin/pi), managed via OpenRig's pi RPC runner Models: deepseek/deepseek-flash, qwen-token-plan-individual/qwen3.8-flash macOS 27.0 (arm64), tmux 3.7c Observed Three Pi seats were added to a running rig with rig add. All three completed real model turns and are running/ready: $ rig ps --nodes --rig kernel --json (pi rows) queue-worker-pi1@kernel running {"state": "unkn

Summary On a machine where only Claude Code is logged in, the kernel boots correctly on the Claude-only variant. But the UI shows the kernel with runtime: codex seats, so it looks as if the running kernel depends on Codex. What happens selectVariant() in daemon/dist/domain/kernel-boot.js picks rig-claude-only.yaml when claudeCode === "ok" and Codex auth fails. The live rig is correct: rig ps --nodes --rig kernel: advisor-lead, operator-agent and queue-worker are all claude-code, and operator-human is terminal GET /api/rigs/<kernelId>/spec: claude-code ×3, terminal GET /api/rigs/<kernelId>/nodes: only claude-code / terminal However, the spec library only indexes the default dual-runtime file: GET /api/specs/library {"kind":"rig","name":"kernel","sourceType":"builtin", "relativePath":"rigs/launch/kernel/rig.yaml", ...} That file has runtime: codex for the operator agent and the queue worker, and its summary says "Dual-runtime variant; Claude Code + Codex both authenticated." rig-cla

[Bug] rig up fails readiness on containerized / older-tmux hosts — tab field-separator collision Summary On hosts running tmux 3.3a (the version shipped by Debian 12 / bookworm, Ubuntu 22.04, and many common Linux container base images), rig up <spec> fails every node with: Readiness timeout after 30s — harness did not become interactive: tmux session not responsive even though the tmux sessions are clearly alive and the agent harness (Claude Code / Codex) is running inside them. Root cause: tmux 3.3a substitutes TAB bytes (0x09) with _ (underscore) in -F format output, which breaks the adapter's tab-delimited parser. Environment where reproduced Host OS: Linux (arm64), container base node:22-bookworm (Debian 12) tmux version in container: tmux 3.3a (Debian package) OpenRig: @openrig/cli (latest, installed via npm i -g) Rig spec: research-team (builtin) Node: 22.x Not observed on macOS hosts with Homebrew tmux 3.4+. Reproduction In any Debian 12 / Ubuntu 22.04 container or VM: a

Summary On a machine with cmux 0.63.2, OpenRig's daemon cannot control cmux even though shell cmux works fine. rig setup and the initial rig doctor both report [OK] cmux_daemon, so the failure is invisible until the user clicks the Open CMUX button in the UI and nothing happens. Root cause Recent cmux versions migrated automation.socketControlMode to default "cmuxOnly" (see socketControlPasswordMigrationVersion in cmux defaults). In that mode cmux rejects all external socket clients at the control-mode layer — no password, env var, or daemon restart will help. OpenRig needs socketControlMode: "automation" (or more permissive) in ~/.config/cmux/settings.json. Reproduction Fresh npm install -g @openrig/cli on macOS with cmux 0.63.2 rig setup → reports [OK] cmux_install, [OK] cmux_auth rig doctor → reports [OK] cmux_shell, [OK] cmux_daemon (false positive) Open UI, click CMUX on any node → nothing opens, no error surfaced in UI rig daemon stop && rig daemon start → now rig doct