README: document ControlMaster negotiation behaviour
This commit is contained in:
@@ -85,11 +85,14 @@ pi -e ~/src/src_local/pi-extensions/extensions/ssh-controlmaster.ts --ssh user@h
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. On `session_start`, establishes a ControlMaster: `ssh -fN -o ControlMaster=yes -o ControlPersist=yes -o ControlPath=<socket> <remote>`
|
||||
2. All tool calls use `-o ControlMaster=no -o ControlPath=<socket>` to multiplex over that socket — near-zero per-call overhead
|
||||
3. The system prompt is patched to tell the LLM it's operating on `<remoteCwd> (via SSH ControlMaster: <remote>)`
|
||||
4. User `!` shell commands are also routed over SSH
|
||||
5. On `session_shutdown`, sends `ssh -O exit` to cleanly tear down the master
|
||||
1. On `session_start`, runs `ssh -G <host>` to read the effective config for that host
|
||||
2. If `~/.ssh/config` already configures `ControlMaster auto` or `yes` for the host, the existing system socket is reused — no second connection is opened and pi does **not** tear down the master on exit (it was the system's to manage)
|
||||
3. Otherwise pi establishes its own master: `ssh -fN -o ControlMaster=yes -o ControlPersist=yes -o ControlPath=/tmp/pi-cm-<pid>.sock <remote>` and shuts it down cleanly on exit
|
||||
4. All tool calls multiplex over the socket with `-o ControlMaster=no -o ControlPath=<socket>` — near-zero per-call overhead
|
||||
5. The system prompt is patched to tell the LLM it's operating on `<remoteCwd> (via SSH ControlMaster: <remote>)`
|
||||
6. User `!` shell commands are also routed over SSH
|
||||
|
||||
The status bar shows `⚡ own master` or `⚡ system master` so you can see which path was taken.
|
||||
|
||||
**Status bar:** Shows `SSH ⚡ user@host:/path` when the master is ready, `⟳ connecting…` during setup, and an error state if the master fails to start.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user