What a join code actually grants

A p2pmux session is a trusted shared shell. Anyone holding the code or ticket can see every pane and take interactive control of the terminals that are available. They can run commands as that machine's user, read anything that user can read, and print a secret to the screen. Share it with people you would hand your unlocked laptop to, and nobody else.

There is a second half to that sentence, and both halves are true at once. Credential files and processes never leave the machine that hosts a pane: your API keys, your SSH keys and your logged-in CLIs stay on your disk, and a teammate driving your pane is running a program on your computer rather than copying anything to theirs. That is what makes "start Claude Code on my subscription, without giving you my key" work.

It is not a sandbox. Nothing stops a controller from running cat ~/.aws/credentials. If that distinction matters for a given collaborator, use a separate low-privilege user account and keep production credentials out of shared panes.

Where things run

ThingWhere it lives
Your shell, your agent, your buildYour machine. Always.
Your API keys and credential filesYour disk. Never uploaded.
Terminal output and keystrokes Encrypted, peer to peer — or through an iroh relay when NAT blocks a direct path. A relay forwards encrypted bytes it cannot read.
Tabs, panes, who is whereBetween the peers in the session.
One anonymous count a day m.p2pmux.com, and only if you said yes when p2pmux asked. A random id, the version, the OS, how many sessions and whether anybody joined one. Run p2pmux telemetry show to see it.

The two servers we run

Joining takes a ten-character code instead of a two-hundred-character ticket, and that convenience needs somewhere to look the code up. That is rv.p2pmux.com. The second is m.p2pmux.com, which counts how many people use p2pmux, and is described further down. Neither is on the connectivity path and neither ever sees a byte of your terminal.

It cannot read what it stores. Your client turns the code into two separate values: an address to store the record at, and a key to encrypt it with. Only the first is ever sent. The service receives an opaque handle and a sealed blob, holds them for a few hours, and hands them back to whoever presents the same handle. There is no configuration of that service that reveals a ticket, because the key never reaches it.

We do not claim "no servers". iroh's public relays exist and carry encrypted traffic when a direct path cannot form, and the code lookup above is ours. What we claim is narrower and checkable: your processes and your credential files stay on your machine.

The count, and why we ask instead of assuming

p2pmux can send one line a day to m.p2pmux.com. It asks you once, the first time you run it, with the whole thing on screen. Most developer tools collect this quietly and let you opt out in a settings file. That would get better numbers and it is the wrong trade for a tool whose entire claim is that your keys stay on your disk.

The line is, in full:

There is no field for a hostname, a directory, a session name, a command, or anything you typed — and no setting that adds one, because the whole schema is eight columns in a file you can read. Your IP reaches that server, the way one reaches every web server; it rate limits writes and is never stored. "Not stored" is the honest claim, and "not seen" would be a lie any traceroute disproves.

p2pmux telemetry show prints the exact line this machine would send. p2pmux telemetry off stops it. DO_NOT_TRACK=1 and CI are honoured without being asked, and a machine with no terminal to ask in — a droplet running the fleet agent — is never asked and never sends.

Because it is asked for rather than assumed, these numbers undercount real use by an unknown amount, permanently. We would rather have a number we can explain than a bigger one we cannot.

Limits worth knowing