Run OpenRig across machines

# On the home machine. Replace the placeholder with its private address.
rig daemon start --host <home-private-address> --port 7433

If the daemon is already running, check its current configuration and rig daemon --help before changing it; repeating a start command is not a substitute for configuring the running service. Keep existing agents and work in mind when arranging a restart.

From the laptop, pair with that private address:

# On the laptop
rig host pair http://<home-private-address>:7433 --id home

Replace the angle-bracketed address; don’t type it literally. home is the name this machine will use to route to the other host.

Pairing waits for an approval on the target machine. Use a target with a registered human approval recipient. The command prints the approval item and the exact command to run there:

# On the home machine, using the approval ID printed by pair
rig queue update <approval-qitem-id> --state done --closure-reason no-follow-on

Once approved, the laptop records the host and its token. If the target has several registered human recipients, supply the appropriate address with --human on the pair command.

Check the registration and connection:

rig host list
rig host doctor
rig ps --host home --nodes

Then pair the return route from Home to Laptop, using the laptop’s reachable private address and --id laptop. Repeat between Home and Dogfood: Home calls its VPS host dogfood, and the VPS calls its home host home. Each target needs its own approval. Host names are local registry names, so use them consistently in each machine’s commands.

You can also register SSH or HTTP hosts manually with rig host add. They have different prerequisites and command coverage; OpenRig does not silently switch from one transport to the other. Use rig host add --help for that alternative.

# On the laptop
rig ps --host home --nodes
rig send owner@project "What changed while I was away?" --host home
rig capture owner@project --host home

Use the real seat address from rig ps. The host chooses the machine; the seat address chooses the agent. capture reads that agent’s terminal screen. It does not copy the agent’s memory or conversation into yours.

For work that needs an owner, create a queue task on the destination host:

# On the home machine, as the project owner
rig queue create --host dogfood --destination dogfood@testing \
  --id invitation-check \
  --summary "Dogfood the new invitation flow" \
  --body "Use the invitation revision in your project checkout. Try awkward cases and return findings to owner@project on home."

Choose a fresh task ID for your own work. The destination agent reads and claims the task on its own machine:

# On the dogfood VPS, as dogfood@testing
rig queue show invitation-check --full
rig queue claim invitation-check

In 0.5.17, queue create accepts --host. Queue show, claim, list and handoff run on the machine that holds the task. Queue writes do not follow rig host select; selecting a remote host is not enough to move an assignment there.

# On the dogfood VPS
rig queue create --host home --destination owner@project \
  --id repeat-invite-fix \
  --summary "Fix the repeated-invitation error" \
  --body "On the invitation revision, invite the same address twice. The second attempt shows an error. Handle this case and return the new revision to dogfood@testing."

The home owner reads and claims that local task, then organizes the repair in the project’s existing mission:

# On the home machine, in the project workspace
rig queue show repeat-invite-fix --full
rig queue claim repeat-invite-fix
rig scope slice create dream-saas repeat-invite \
  --template bug-fix \
  --title "Handle repeated invitations" \
  --intent "Make repeated invitations behave usefully instead of returning an error."

Here dream-saas is an existing mission in the example project. Substitute your own mission. The slice is created on Home, where the project lives; the finding crossed the network as a task. Pairing did not synchronize a mission directory.

After the build team makes the fix, it makes the new revision available through the project’s normal source-sharing process and asks Dogfood to recheck. Dogfood reports back to the home owner, which records the outcome and the next action:

# On Home, after receiving the dogfood result
rig queue update repeat-invite-fix \
  --note "The repaired revision passed the repeated-invitation check; dogfood is continuing through the next flow."

A note records progress; it doesn’t change the task’s state. The home owner still decides whether more work remains. Keep the project assignment, the dogfood task and the repair task distinct.