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 wrongLifecycle
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 statusOutputs (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: 0rig 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 | jqThe 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,errorstate.
Useful in scripts:
if rig status > /dev/null; then
rig hub publish
fiLogs
.rig/tap/daemon.log — tail it when something's off:
tail -f .rig/tap/daemon.logYou'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 resumedetects stale pidfiles and replaces them. - Pending edits are recovered on next start from the local watch state.
- Use
tail .rig/tap/daemon.logto see what happened, thenrig resume.
If the daemon repeatedly crashes:
- Check
tapd --versionmatches 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:
- Open the conflicted file. Look for sync-conflict markers.
- Edit to the resolution you want.
- 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 frombinding_membersand 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 > 1and someone had already joined via it).
A removed member's local file copy stays intact on their disk — sync just stops.
See also
- Status JSON shape (it's embedded in
rig doctoroutput too) - Recovery — when you need to undo
- How collab works