Collaborate

The sync daemon

rig resume / pause / status — control the background process that does the sync.

The daemon — tapd — is the local process that watches files, sends edits to the relay, and applies incoming edits. You should never need to invoke tapd directly. The rig workspace verbs are the user-facing surface.

Commands

rig resume    # spawn detached daemon (restore sync on this device)
rig pause     # graceful stop (halt sync on this device)
rig status    # show state; non-zero exit if anything's wrong

Lifecycle

rig resume spawns tapd as a detached process. Pidfile at .rig/tap/daemon.pid. Logs to .rig/tap/daemon.log. Survives terminal close.

rig pause sends SIGTERM and waits for clean shutdown. The daemon flushes any pending writes before exiting.

rig install starts the daemon automatically when [sync] is enabled in the manifest, so a fresh install is sync-ready without manual intervention.

rig disconnect stops the daemon as part of its teardown.

Status

rig status

Outputs (human form):

✓ binding: research-q2 (id: bnd_a1b2c3)
✓ daemon:  running (pid 12345)
✓ sync:    idle, last update 2026-05-27T14:23:11Z
✓ scope:   3 collaborators (1 owner, 2 invited)

✗ apply errors: 0
✗ conflicts:    0

rig status reports a state enum: local | disabled | declared | live | paused | offline | revoked | error. --verbose adds members, invites, mounts, and conflicts; --json is machine-readable:

rig status --json | jq

The structured output is what rig hub publish and rig hub update check.

Exit codes

  • 0 — daemon running, sync clean.
  • non-zero — any of: daemon stopped (offline), conflicts, apply errors, error state.

Useful in scripts:

if rig status > /dev/null; then
  rig hub publish
fi

Logs

.rig/tap/daemon.log — tail it when something's off:

tail -f .rig/tap/daemon.log

You'll see:

  • File watch events
  • Push/pull batches
  • Apply outcomes
  • Network errors

The log is also a useful artifact when reporting bugs — but redact paths that contain personal data before sharing.

When the daemon dies

If tapd crashes:

  • The pidfile is left behind. rig resume detects stale pidfiles and replaces them.
  • Pending edits are recovered on next start from the local watch state.
  • Use tail .rig/tap/daemon.log to see what happened, then rig resume.

If the daemon repeatedly crashes:

  • Check tapd --version matches what the relay expects.
  • Upgrade: npm install -g @rigxyz/tapd@latest.
  • Filed issues should include the log.

Conflicts

Conflicts happen when two devices edit the same file in the same region faster than the sync can reconcile. rig status shows them:

✗ conflicts: 1
  - data/templates/email.md  (you vs. alice@…)

To resolve:

  1. Open the conflicted file. Look for sync-conflict markers.
  2. Edit to the resolution you want.
  3. Save. The daemon picks up your edit and propagates.

Until conflicts are resolved, rig hub publish and rig hub update refuse to run.

Revoking access

Two surfaces, depending on what you want:

  • Kick a member entirely: rig unshare <email>. Removes them from binding_members and cascade-revokes every capability token they hold for this binding, in one transaction. Their tapd starts failing on next sync attempt.

  • Demote rather than kick: rig role <email> viewer. Their existing token still resolves, but writes start failing on their next sync request — no token rotation needed on their side.

  • Kill an unaccepted invite: rig unshare <inv_…>. Cascades to any tokens already minted from it (relevant if it had --max-uses > 1 and someone had already joined via it).

A removed member's local file copy stays intact on their disk — sync just stops.

See also