Manifest reference

[sync] — live workspace

Opt the rig into a live, synced workspace. (Legacy block name: [collab].)

[sync]
enabled  = true                      # `rig init` default; false = local-only
relay    = "https://tap-relay.fly.dev"
provider = "tap"
name     = "research-team-2026q2"    # optional, defaults to [rig].name

rig init writes [sync] enabled = true by default (--no-sync writes false). With it, the first rig share or rig join binds the rig and starts syncing, the rig install step starts the daemon automatically, and rig doctor adds a sync check section.

The legacy block name [collab] is still recognised; [sync] is canonical.

Fields

provider (string)

Currently only "tap" is supported. This is the sync provider — see How collab works for the architecture.

relay (string, URL)

The sync relay endpoint. For production use, the default is https://tap-relay.fly.dev. For local development you might point at http://127.0.0.1:4030.

The relay is a thin coordination service — it does not see plaintext file contents, only ciphertext and metadata. Detail on how collab works.

enabled (boolean, optional, default true)

false keeps the [sync] section in rig.toml but opts out of sync: the daemon stays down and rig share refuses unless you pass --enable (which flips it back to true). Useful when handing the rig off to someone who doesn't yet want sync turned on. Absent block = the same local-only behaviour, just undeclared.

name (string, optional)

The binding name on the relay. Defaults to [rig].name. Override when you want multiple bindings for the same rig (e.g. one per team or per project).

When to add it

You're confident the rig is something multiple people should be editing together. Most rigs don't need this — solo rigs work fine with [sync] enabled = false. Only keep it on when you have a concrete collaboration use case:

  • A research workspace your team is jointly building up.
  • A shared agent your support team edits prompts in throughout the day.
  • A migration playbook two engineers are jointly iterating on.

When not to use it

  • Public rigs distributed via the Hub for many strangers to install. Each user gets their own copy; there's nothing to collaborate on.
  • One-shot or single-user workspaces.
  • Anything you wouldn't want syncing edits between two terminals on your laptop.

Turning it on for an existing rig

New rigs already have [sync] enabled = true. For a local-only rig, the first rig share binds and goes live in one step:

rig share <teammate-email>   # binds + goes live, then mints an invite
# or, to go live without inviting yet:
rig share --enable

See Start a collaboration.

Turning it off

Disconnect this checkout, then set the block local-only:

rig disconnect          # or: rig disconnect --purge
# then set [sync].enabled = false (or remove the block) in rig.toml

rig disconnect removes the local binding pointer at .rig/tap-binding.local.json and stops this device's daemon — the remote workspace and your membership are untouched. --purge also removes manifest-tracked files.

Required tooling

Synced rigs need tapd on PATH:

npm install -g @rigxyz/tapd

tapd is the local sync engine. You'll never invoke it directly — rig share / rig status / rig resume shell out to it. See Install the CLI — for collaboration.

See also