Providers and device detection
A provider is whatever stands behind a connection and answers for it: the built-in SSH provider, or a connection adapter you installed. It declares which services exist, owns its own navigation and settings vocabulary, and is the only component allowed to know what kind of machine is on the other end.
How it works
Capabilities are declared, not inferred
Every connection publishes a catalog of services and methods when it starts. The desktop enables a role only when the exact service, version and full method set are present — Files needs listing, locating and previewing; mutations need creating, renaming and deleting together; each transfer direction needs its own group. Anything missing is shown as unavailable rather than offered and then failed.
This is the rule the interface follows everywhere: capability discovery constrains what is offered; it never licenses an assumption. No part of the shell may conclude from a capability that the destination is Linux, that paths use forward slashes, that a shell exists, or that filenames are case-sensitive.
Providers own their vocabulary
| The provider owns | Consequence for everything above it |
|---|---|
| Location tokens | Opaque strings. The shell never splits, joins or normalises them. |
| Parent, home and roots | Navigation comes from the listing, not from string surgery. |
| Entry revisions | Moves, renames and deletions are refused when a revision is stale. |
| Settings fields | Host details renders the schema it is given; it has no built-in field list. |
| Device behaviour | Reboot, shutdown and similar actions exist only where the provider offers them. |
Because locations are opaque, a path from one provider is meaningless to another — which is exactly why the whole files family in a workspace must come from a single source.
Detection sits behind the interface
The SSH provider identifies Linux hosts and MikroTik RouterOS through bounded read-only probes. Linux can provide a settings schema; RouterOS can report its version and identity without pretending to support Linux settings. An unrecognised system stays on generic SSH behavior, with Terminal and file actions determined by what the account and server actually permit. SFTP provides full file access; compatible Linux shells or RouterOS metadata may provide limited browsing when SFTP fails. Detection is internal to the provider, and a failed probe does not end an otherwise usable SSH session.
Adapters are providers too
A connection adapter reaches the desktop through the same door. Advertise files v1 and Files works; advertise console v1 and a terminal appears; advertise host v1 with only a read method and Host details renders read-only. Advertise your own service and it is invisible to the shell but reachable by apps holding a grant for it. There is no privileged path that the built-in provider has and an adapter does not.
Boundaries
The provider interface is internal to the application and is not a stable public API; the supported way to add a source is a connection adapter. Device detection recognizes Linux and MikroTik RouterOS over SSH. Windows OpenSSH uses generic SSH behavior and has been exercised for file operations, but its device-specific settings are not supported; macOS destination validation remains narrow. Settings schemas are only as good as the provider that supplies them, and a provider that advertises a capability it cannot honour produces failures the desktop can report but not prevent.
Related guides
- Adapter services — declaring capabilities as a provider.
- Connection and workspace model — how declared capabilities become bindings.
- Filesystem contracts and SDK — the location and paging model.
- Remote settings — a provider-supplied schema in use.