Reference · Machines and disk
What pairing grants
The requests a paired machine can make once paired, and the ones it cannot.
Pairing is the whole of the authorisation. Once two machines are paired, every request in the list below succeeds with no confirmation asked on either machine, every time it is made.
What a paired machine can do
| Group | Covers |
|---|---|
| The session list | A live stream of every session running on the paired machine |
| A session's transcript | Its snapshot, its live events, and a capped excerpt of its history |
| A session's media | A picture or a design model a tool call produced, a gallery picture or sound, and an archive job's progress and finished zip |
| Writing to a session | Creating one, sending it a message with pictures and a send priority, stopping its turn or a background task, starting a new conversation in it, answering what it is blocked on, archiving it, marking it read |
| A session's composer | Its slash commands, the names of the files in its working directory, and its MCP servers, including switching one on or off |
| A working directory's resume list | Every session archived on that directory and every Claude Code transcript on it no registry row holds yet, reachable for any path a paired machine names, not only a session's own |
| Resuming a session | Restoring one it archived, or adopting one of its adoptable transcripts into a new row |
| A directory on the paired machine | Whether it exists and whether it takes a worktree — the same check its own new-session dialog runs before offering the checkbox, reachable for any path a paired machine names, not only a session's own |
| Settings | Every setting the paired machine's Settings page reads or writes: its General, Services, Claude, Codex, Gemini and DeepSeek settings, its accounts and synced folders, and its update check. An API key, the sudo password or a bot token can be set or cleared and is never read back |
An allow_always answer sent to a permission ask writes its rule into the answering machine's
own permission store. Nothing on either side records which machine a request came from beyond
that.
What is not reachable
The contents of a session's working-directory files stay unreachable. A paired machine sees the paths the composer's file picker lists, which is every file git would not ignore. It never reads those files, and never browses outside that folder.
Every pane, CAD and game route answers as though the machine were not paired at all.
Rebuilding a worktree a paired machine's own git lost is not reachable either. A row blocked
on it reads worktree gone, like any other blocked row, and stays unpickable.
A paired machine cannot act on a third machine through this machine. The routes that relay a call to this machine's own peers are not on this surface. See Another machine's settings for what each tab shows once a request does reach it.
The mechanism
A request travels as plain HTTP, carrying a bearer token issued once, when the pairing PIN is confirmed. The token stands in for a person answering, on every later request over the link.