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 what it is talking to and adapts accordingly: Linux hosts get richer navigation metadata and a settings schema, while anything unrecognised falls back to generic SSH behaviour that still gives files, a terminal and transfers. Detection is a provider-internal concern. It produces capabilities and metadata, and a failed detection narrows the feature set — it never breaks the session or lets a guess about the remote platform escape upwards.
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 is currently meaningful for Linux over SSH — other systems reach a working generic path rather than a tailored one, and Windows or macOS destinations are not a validated target. 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.