Connection and workspace model
A connection is a live session with one destination. A workspace is a set of bindings that say which connection currently provides files, which provides the console, and which provides settings. Keeping those two ideas apart is what lets one window mix sources, survive a partial failure, and reconnect without losing your layout.
How it works
Connections and bindings
A connection has an identity and a lifetime: it is opened, becomes ready, serves requests, and ends. A binding points a workspace capability at a connection, and is itself versioned — replacing a binding creates a new generation.
That generation is the fence. When a response arrives after its binding has been replaced or closed, it is discarded rather than applied. Without that rule, a slow directory listing from a connection you already swapped out would repaint the file list with another machine's contents. It is why disconnecting and reconnecting feels clean instead of leaving stale fragments behind.
Composition
| Capability | May come from | Constraint |
|---|---|---|
| Files, text editing, transfers | One connection | The whole family must share a single source |
| Console | Any connection | Independent of files |
| Remote settings | Any connection | Independent of files and console |
Files are indivisible because locations are opaque provider tokens: a path from one source is meaningless to another, so listing here and downloading there could not be made safe. Console and settings carry no cross-references, so they are free to come from elsewhere — a terminal on a jump host beside files on the machine behind it is a supported arrangement.
Partial failure
A failure is scoped to the capability that failed. If the console connection drops, the terminal reports it and the file list keeps working. If the files connection drops, open editor documents keep their unsaved text and saving is disabled until a source is available again — the desktop never discards local work to reflect a remote failure.
Every operation therefore has three outcomes, not two: succeeded, failed, and uncertain. A write whose acknowledgement was lost is reported as uncertain rather than guessed at, because the file may well have changed. Where the outcome is unknown, the desktop says so and leaves the decision to you.
Sessions versus saved hosts
A saved host is a profile: address, user, authentication method, preferences. It is not a session, and it never holds a password or passphrase — secrets stay in the native layer for the life of the connection and are not written into profiles. Connecting instantiates a session from a profile; editing the profile afterwards does not reach into a running session.
Lifetime
Ending a connection closes what it owns: terminal channels, open handles, in-flight transfers, adapter processes. Cleanup is bounded and verified rather than assumed — when the core cannot confirm that a process tree ended, it keeps that adapter's files reserved instead of releasing bytes a live process might still be reading. Closing a workspace window ends its connections; the saved layout survives.
Boundaries
Bindings are chosen when a workspace is configured, not negotiated at runtime: an adapter's service catalog is fixed at initialize and cannot grow later, so gaining a capability means reconnecting. Reconnection is not resumption — a new session starts clean, with new handles, new terminal channels and no transfer continuity. Interrupted transfers are restarted, not resumed.
Composition across connections is supported but lightly travelled in an early prototype. If you drive one hard, prefer the arrangements described in Workspaces and windows, and report what breaks.
Related guides
- System architecture — the layers these bindings sit between.
- Workspaces and windows — composing sources in practice.
- Recover from a dropped connection — what to do when one fails.
- Providers and device detection — how a connection reports what it can do.