ShellCanvas / docs

Appearance

System architecture ​

ShellCanvas is one desktop application with a hard line drawn through the middle of it. Above the line is a React interface that knows about windows, apps and workspaces. Below it is a Rust core that owns every connection, credential and byte on the wire. Nothing above the line ever speaks a protocol.

How it works ​

The layers ​

LayerRuns asOwns
Desktop shellReact in the main webviewWindows, layout, the launcher, workspace state, settings UI
Workspace brokerShell-side, between apps and the coreCapability bindings, permission checks, request routing, app lifecycle
Native coreRust, in the Tauri processSessions, host-key trust, authentication, SSH, SFTP, terminals, adapter and bridge supervision
ExtensionsSandboxed webviews, or separate native processesApps, themes, connection adapters, filesystem bridges

Calls travel one way: an app asks the broker, the broker checks the app's grants and the workspace's bindings, and only then does a native command reach the core. An app cannot address a session directly, cannot name a transport, and cannot reach a capability the workspace has not bound.

What a request looks like end to end ​

Opening a folder in Files:

  1. The Files app calls files.list on the workspace, using an opaque location.
  2. The broker resolves which connection currently provides the files capability, and checks the app's files.read grant.
  3. The core issues the operation on that session — SFTP for an SSH connection, a files.list request over stdin and stdout for an adapter.
  4. The result comes back as a page of entries with a parent, roots and per-entry revisions.
  5. The shell renders it. It never parses the location string, because path syntax belongs to the provider.

The same shape holds for terminals, transfers and remote settings. The capability is the contract; the transport behind it is an implementation detail the layer above is not allowed to assume.

Processes ​

The desktop is one process with several webviews. Each installed app runs in its own sandboxed webview with no filesystem or network reach of its own. Each connection adapter runs as a separate native process, launched from an absolute path, speaking length-prefixed JSON over stdin and stdout with a 4 MiB frame limit and at most 32 requests in flight. Filesystem bridges are separate native processes too, on their own protocol with 1 MiB frames and 32 KiB chunks. A failure in one of those processes is contained to its own connection.

Local by construction ​

There is no ShellCanvas account, no server component and no telemetry. Saved hosts, workspace layouts, installed extensions and app storage live in the desktop's local application data. Connections run from your machine to the destinations you name, and nowhere else; the only network traffic ShellCanvas originates on its own is what you point it at.

The browser preview ​

Running the interface in a browser gives a synthetic preview backed by fixtures. It exists so the UI can be developed and demonstrated without hardware. It is deliberately not a fallback: a native connection that fails never quietly becomes a fixture, and the preview announces what it is rather than imitating a session.

Boundaries ​

ShellCanvas is an early working prototype, and this architecture is honest about which parts are proven. Windows is the validated platform; other targets build but are not verified end to end. Connection adapters and filesystem bridges are native code running with your permissions — the process boundary isolates failure, not trust. The webview isolation that apps run under has been validated on Windows only, and is not a certification against a hostile package.

Composition is real but bounded: a workspace may take files, console and settings from different connections, while the whole files family must come from one source. Capability discovery constrains what the interface offers; it is not a promise that a particular device supports a particular operation.

ShellCanvas documentation

© 2026 ShellCanvas