Coordinate with OpenRig agents on registered remote machines using SSH or HTTP connections. Select the intended host, inspect agent state, send messages, and interpret failures while checking whether remote actions actually took effect.
Use when addressing a registered remote OpenRig host, choosing its transport, or interpreting a cross-host result.
Review the instructions the agent will receive before you install.
Use a registered host address and the entry's declared transport. SSH entries run a remote CLI through a single-hop shell; HTTP entries use the remote daemon. These paths have different prerequisites and command coverage. Check the exact command's help and the target installation before a consequential operation.
rig host list shows registered hosts. rig host add --help describes registry
writes; rig host doctor --help describes reachability checks. Inspect the
configured OpenRig home rather than assuming the default ~/.openrig/hosts.yaml.
Registry changes affect later routing, so make them within the requested scope.
hosts:
- id: test-vm
transport: ssh
target: test-vm.local
user: example-user
- id: remote-dev
transport: http
url: http://remote-dev.example:7433
bearer_env: REMOTE_RIG_TOKEN
The registry requires a hosts array, unique non-empty ids and a supported transport. SSH needs a non-empty target; user and notes are optional. HTTP needs a URL and accepts at most one of bearer_env or bearer_file. Omitting both is valid for a tokenless target. A configured but unavailable bearer is a permission failure, not anonymous fallback. Host ids also have reserved-name validation; use the actual validator's error rather than inventing an alias that collides.
rig send dev-worker@example-rig "check the assigned result" --host remote-dev --verify
rig capture dev-worker@example-rig --host remote-dev
rig ps --host remote-dev --nodes --json
rig whoami --host remote-dev
These coordination commands select SSH or HTTP from the registry entry. They do not silently try another transport when one fails. A host-qualified target can be convenient, but confirm its parsing and any persisted host selection with the particular command. Explicit --host is preferable for consequential cross-host work.
Queue destinations use explicit --host or a supported host-qualified destination; queue writes do not follow persisted host selection. The CLI separates the host from the canonical seat in the routing envelope. Different queue subcommands have different flags: check their help instead of copying a flag from send. A local success message alone does not establish remote persistence or pickup.
| Signal | What to inspect |
|---|---|
| registry-load-failed / unknown-host | Registry path, entry and exact destination |
| ssh-unreachable | SSH connection, target and transport diagnostics |
| permission-gate | The configured SSH or HTTP credentials and target policy |
| remote-daemon-unreachable | Target listener and actual running daemon identity |
| remote-outcome-unknown | The request may have arrived (timeout, dropped connection, unreadable reply): check its effect, for a send the target pane, before any retry |
| remote-command-not-found | Remote CLI installation and executable lookup |
| remote-command-failed | The remote operation's own status and error |
The exact result taxonomy depends on the path. HTTP failures expose the remote status/error; SSH distinguishes the shell transport from the remote command. Do not start or replace a remote daemon merely because a diagnostic suggests it; first establish the target's state and the authority for that lifecycle action. A timed-out write may have reached its destination. Reconcile its durable effect before retrying.
Transport success is not delivery verification or agent consumption. SSH forwards --verify and returns the remote CLI result. HTTP preserves the remote transport verdict and explicitly reports that the local pane-effect check did not run cross-host. Inspect that result and the destination effect required by the task; never replace it with “SSH exited zero” or “HTTP returned successfully.”
Cross-host output names the host/target; JSON envelopes carry cross_host metadata. The precise envelope differs by command and transport. Preserve the underlying remote result when passing evidence onward.
A target's host suffix selects a destination; a sender's origin identifies where a reply belongs. Use the rendered reply address and verify its host mapping. Current send derives the sender from the executing seat context, not a caller's --from assertion. It adds origin-host identity at cross-host forwarding; do not assume local sends have the same suffix. Unknown identity remains unknown.
This guide describes the implemented command paths, not proof of a live remote journey on your installation. Forks, handovers and other lifecycle compositions need their own supported command and scoped authority; reading remote state does not authorize them.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Automate website interactions through a command-line browser tool. Navigate pages, fill forms, extract text, save screenshots or PDFs, reuse login sessions, and compare page states to check the effects of actions or website changes.
Design and maintain applications where OpenRig agents help run the system. Organize instructions, shared state, and artifact checks, then trace unexpected behavior to the code, skill, or schema that needs repair.
Design and run bounded procedures in environments where current conditions are uncertain. The skill separates agent judgment from precise tool actions, verifies each effect, and records checkpoints so interrupted work can resume from observed evidence.
Create reusable starting configurations that combine an agent’s role, startup context, and source history. The skill guides registry entries, checks whether their sources are current, and manages their progression from initial capture to recommendation or retirement.
Guides the design and review of agent startup context, including role files and links to authoritative records. It helps identify stale guidance, missing updates, overloaded startup files, and instructions that lose the purpose of the work.
Configure selected OpenRig command permissions in Claude Code or Codex at the agreed project or user scope. Preserve existing restrictions, verify that settings load and behave as intended, and record additions so they can be removed later.