Second machine (beta)

Technical chapter.second-machine raw

Beta here means three things, and it is this handbook's word, not the code's: the features in this section are young (credential sync and transcript sync are the newest parts of the daemon, with the least use behind them), they are optional (nothing elsewhere in the handbook needs them), and they are valuable only once you have two machines — a laptop and a workstation, a Mac and a Linux VM. Nothing in ccc-statusd or its docs is labelled beta; grep -i beta over its docs finds nothing. Skip this section until a second machine exists.

What a second machine changes

On one machine, everything lives on its disk: the sessions root and its payload, the Claude login of each official profile, and every session transcript. A second machine wants all three, and each has one mechanism:

flowchart LR
  A[machine one] -- "annex remote (S3-class bucket)" --> S[(object store)]
  S --> B[machine two]
  A -- "credential sync (official profiles)" --> W[get-ucc worker]
  W --> B
  A -- "transcript sync (sealed frames)" --> W

Need	Mechanism	Step
The sessions root's payload reachable from both checkouts	an S3-class annex remote; the `--remote local` store you made in step 03 moves to it	`step.07-annex-remote`
One Claude login shared by both hosts	credential sync — the daemon mirrors each official profile's OAuth record through the worker	`step.08-credential-sync`
Every session transcript readable from either host	transcript sync — the daemon ships sealed frames to the worker and pulls the other host's	`step.09-transcript-sync`

Shapes that do not rot

Both syncs are two lines in $UCC_HOME/user-env.sh and one ccc-statusd restart. The daemon reads its environment once at exec; an export in your shell reaches it only through a restart. The installer creates user-env.sh once and never overwrites it, so the lines survive ucc-cli update.
The namespace is UCC_USERNAME. Credentials live under credentials/<UCC_USERNAME>/, transcripts under transcripts/<UCC_USERNAME>/. A host installed under a different username gets a healthy, disjoint namespace and never sees the first host's records. The installer sets UCC_USERNAME from the install line — the same <username> on both machines is the whole trick.
The worker side is ZT's. The bucket, the per-user Durable Objects and the get-ucc worker already exist. You bring no Cloudflare account, no wrangler, no bucket of your own. The one exception is the annex remote in step 07: that bucket is yours.
Credential records never cross the macOS/Linux line. One record per (profile, os); a Mac and a Linux VM each log in once. Only official profiles sync — a profile whose .env sets ANTHROPIC_BASE_URL, ANTHROPIC_API_KEY or ANTHROPIC_AUTH_TOKEN is never watched.
Transcripts are sealed on the host under CCC_TRANSCRIPT_SYNC_KEY before they leave. The worker holds ciphertext only. The key must be byte-identical on every host; a host with a different key pushes fine and opens nothing of the others' — those files are parked silently, and ccc-statusd transcript status is the one command that shows them (step 09).
A pulled transcript lands in the mirror, $UCC_HOME/shared/mirror/, never under projects/. ccc-statusd resume-session <id> forks it under a new id here; there is no in-place takeover and no merge — a session edited on both hosts is marked diverged, and ccc-statusd transcript resolve <uuid> is the repair.

Names you will meet

Name	What it is
`$UCC_HOME/user-env.sh`	your environment file; both syncs are enabled here
`UCC_USERNAME` · `UCC_R2_BASE_URL` · `UCC_AUTH_TOKEN`	set by the installer; the namespace, the worker URL, your token — never on a page
`CCC_CREDENTIAL_SYNC`	`on` enables credential sync
`CCC_TRANSCRIPT_SYNC` · `CCC_TRANSCRIPT_SYNC_KEY`	`on` plus the 64-hex key enable transcript sync
`sessions.annexRemote`	git config in each checkout naming the annex remote the sweep copies to
`$UCC_HOME/shared/mirror/`	where pulled transcripts land
`ccc-statusd credential status` · `ccc-statusd transcript status`	the two health reads; `curl -s http://127.0.0.1:19223/health` carries both as JSON

Where the detail lives

Annex remote, clone on a new machine, bin/init flags: the installed ccc-sessions-root skill (references/roots.md).
Credential sync: ccc-statusd credential --help and its subcommand help.
Transcript sync: ccc-statusd transcript --help; ccc-statusd transcript status for the live state.
The daemon's own docs travel with its source under .agents/credential-sync.md and .agents/transcript-sync.md — the current word when a page and the code disagree.

Step 07 — an S3-class annex remote, and the local → S3 move

Technical step.07-annex-remote raw

Step 3 gave your sessions root a local payload store — durable against a wiped checkout, not against that disk, and invisible to a second machine. This step moves that payload into an S3-class bucket of yours (AWS S3, Cloudflare R2, MinIO, SeaweedFS) and clones the root on machine two, so both machines share one durable copy that the daemon keeps current every ten minutes.

Step 08 — credential sync (official profiles only)

Technical step.08-credential-sync raw

Log in to an official Claude profile on one machine and the same profile on your other machine is already logged in: the daemon mirrors each official profile's login record through ZT's worker, one record per profile and operating system, and never touches a third-party profile. This step turns that on with one line on every machine.

Step 09 — transcript sync

Technical step.09-transcript-sync raw

Every Claude Code transcript on this machine is shipped to ZT's worker sealed under a key only your machines hold, and your other machine pulls it into a mirror it can read and resume from. This step generates that key once and turns the sync on with the same two lines on every machine.