Shared rigs

A shared rig is a rig with [sync] enabled. The owner runs rig share, invites collaborators, and from then on every change to shared files propagates between machines in near-real-time.

Underneath, a sync daemon called tapd watches the workspace, sends changes to a relay, and applies remote changes back. You don't normally interact with it directly — the rig share / rig who / rig status verbs are the only surface you need. If you want to know how it works, see How collab works.

Mental model

You                          Relay                       Teammate
──────────                  ─────────                   ──────────
edit file ──► tapd ──► HTTPS ──► tapd ──► apply file
                       (small,
                        end-to-end
                        verified)

Each machine runs tapd. The relay coordinates. Files in [package].include sync; files in [local].dirs and the default-excluded paths do not.

When to use it

Good fits:

• Team research workspaces — multiple people accumulating notes, prompts, examples.
• Shared agent prompts — your support team iterating on a single Claude rig.
• Operational runbooks — two engineers jointly editing a migration playbook.

Bad fits:

• Public rigs. A rig published to the Hub for thousands of strangers — each install is its own copy; there's nothing to "share" between them.
• Solo work. Adds complexity for no benefit.
• High-frequency machine-generated writes. The sync layer assumes humans editing; thousands of writes per minute will overload it.

Pages

• Start a collaboration — rig share --enable, the binding, the daemon.
• Invite people — rig share <email>.
• Join — rig join <url>.
• Members — rig who / rig role / rig unshare.
• Sync daemon — rig pause, rig resume, rig status.
• Recovery — rig history and rig restore for deleted/overwritten files.
• Leave — rig disconnect, rig disconnect --purge.
• Publishing a synced rig — why rig hub publish can refuse.
• How collab works — architecture: tapd, the relay, bindings.

Prerequisites

You need all three:

• The rig CLI: npm install -g @rigxyz/cli
• The sync daemon: npm install -g @rigxyz/tapd
• A signed-in Rig Hub account: rig login (browser-based, one-time per machine)

tapd is a separate package so non-collaborators don't pay the install cost. rig login is required even for the inviter — the relay won't create a binding without identifying its owner.

Concepts at a glance

• Binding — the relay-side record that ties this workspace to a logical collaboration. Created by the first rig share or rig join. Stored at .rig/tap-binding.local.json (per-device, never committed).
• Member — a Rig Hub account that's part of a binding, with a role (owner, editor, or viewer). Inspect with rig who, change with rig role, remove with rig unshare.
• Role — what a member can do. Owners can manage members and mint invites. Editors can read/write/subscribe. Viewers can read/subscribe (no writes).
• Device — each machine has its own credential in the binding file. One member can have multiple devices (laptop, desktop, etc.). Revoking the member cascades to all their devices.
• Invite — a URL the owner gives to a prospective collaborator. Member invites (--role editor) attach the joiner to binding_members; pure-capability invites give a device credential without a member row.
• Daemon (tapd) — the local process that watches files and ferries changes. Detached, pidfile-managed at .rig/tap/daemon.pid.
• Relay — the coordinator. Hosted at https://tap-relay.fly.dev by default. Stores binding metadata, change events, and blobs (content-addressed by sha256 in object storage).

See also

• [sync] manifest reference
• How collab works — architectural details for the curious.