pty experimental

Remote sessions

pty sessions on another machine work just like local ones. fabric carries the connection, and pty never touches the network itself.

How it's wired#

On the machine with the sessions, expose pty's remote server through fabric:

fabric expose pty-remote --exec -- pty remote-serve --stdio

fabric starts one pty remote-serve for each connection and pipes the connection to it. There is no separate server to keep running.

From any trusted peer, the everyday commands take --remote <peer>:

pty list --remote <peer>
pty peek --remote <peer> <ref>
pty send --remote <peer> <ref> --seq "ls" --seq key:return
pty attach --remote <peer> <ref>

Here <ref> is a session's id or display name on the remote machine.

A persistent remote shell#

Put the two together and you get something SSH doesn't give you. A pty session already persists on its daemon, and replays its screen when you attach. So pty attach --remote to a long-lived shell session is a persistent remote shell. Close your laptop, reconnect from another network, and pick up exactly where you left off.

Who does what#

• fabric moves the bytes. It finds the peer, picks a direct or relayed path, authenticates it, reconnects, and checks the grants that decide whether this peer may reach pty-remote at all.
• pty owns the session: the program, the screen and the lifecycle.

Neither needs to know the other's internals. pty asks fabric for a local socket and speaks its own protocol over it. That's the same contract any tool can use.

Why it matters for agents#

Every smalltalk seat runs in a pty session. The same idea that lets you reattach to your own shell from anywhere lets you watch, or step into, an agent's terminal on another machine.