Compatibility and known limitations
What works today, what is unverified, and what does not exist yet. Read this before treating a missing feature as a defect — most gaps here are known and deliberate, and the release notes are where they change.
Availability
This page describes ShellCanvas 0.1.x, the early prototype series. Version 0.1.13 has published Windows x64, Linux x86_64 and macOS Intel/Apple silicon packages. Windows has the broadest live validation; Linux and macOS native app-frame probes passed, while real SSH and installed-app sessions there need broader testing.
Interface
Implemented and exercised
| Area | State |
|---|---|
| SSH connections with host-key verification | Working; verification precedes authentication and fails closed |
| SFTP file browsing and management | Working, subject to what the remote account and server allow |
| Browsing without SFTP | Limited POSIX shell mode on compatible Linux hosts; read-only folder browsing on some RouterOS hosts |
| Downloads, uploads and folder transfers | Working; no resume |
| Terminal sessions | Working |
| Text editor with drafts and conflict handling | Working |
| Saved hosts and workspace layouts | Working; no credentials stored in profiles |
| Remote settings for detected Linux hosts | Working, from a provider-supplied schema |
| Apps and themes | Installed locally from packages on Windows, Linux and macOS; native app-frame probes passed, with broader non-Windows user testing pending |
| Connection adapters | Native packages must include the current OS/architecture; per-adapter coverage varies |
| App SDK, adapter SDK, filesystem SDK | Provisional 0.1 prototypes; interfaces may change |
Validated narrowly
- App runtime isolation has targeted probes on Windows, Linux and Apple silicon. It is not certified against a hostile package; full user-session behavior on Linux and macOS still needs testing.
- Filesystem bridges and local drive mounting are prototype-stage and depend on a bridge application you install yourself.
- Device detection recognizes Linux and MikroTik RouterOS over SSH. Windows OpenSSH uses generic SSH behavior; only the services actually observed are offered.
Not implemented
Serial, Telnet and FTP connections. Any built-in device API beyond what a provider supplies. A publisher-verified extension marketplace. Windows code-signed installers or Apple-notarized packages. Session resumption and transfer resume. Remote settings for non-Linux hosts.
None of these are available through a workaround or a hidden setting. Where you see an SDK for extending ShellCanvas, that is the supported way to add a source or a feature — see Build your first adapter.
Examples
Check what your own build actually offers, rather than assuming from this page:
- Version — the desktop reports its version in Settings. Compare it against the release notes before reporting anything.
- Connection capabilities — open the workspace's connection details. A capability that is absent there is absent, full stop.
- App permissions — App Manager lists what each installed app declared and what you granted.
- Adapter services — the adapter's own documentation, confirmed by what the desktop enables after connecting.
Errors
At a compatibility boundary you will see an unavailable state rather than a crash. The common ones:
| What you see | What it means |
|---|---|
| A capability shown as unavailable | The connection's provider does not advertise it. |
| This capability is not provided by the selected service | The workspace bound a source that lacks it. |
| A transfer direction refused through an adapter | The adapter advertises only part of the transfer methods. |
| Read-only settings, or read-only documents | The provider offers reading but not applying or saving. |
| An install refused for compatibility | The package declares a client platform this desktop does not satisfy. |
| An unsigned-installer warning from Windows | Expected. Releases are not code-signed yet. |
App and adapter failures use a fixed set of codes — invalid, closed, aborted, denied, unavailable, busy, failed, deadline. unavailable is the compatibility one: the operation does not exist here, as opposed to denied, which means it exists and is not permitted.
Lifecycle and permissions
Boundaries move between releases, and the CHANGELOG is the record of which ones did. Because the SDKs are provisional, an extension built against one 0.1.x release may need rebuilding against the next; the manifest's declared schema version and platform compatibility are what the desktop checks, and a refusal there is the mechanism working.
A granted permission is necessary but never sufficient. Nothing on this page changes with more permissions: if the host does not provide a capability, no grant can produce it.
Related guides
- Requirements — platforms, versions and what you need on the host.
- System architecture — why boundaries fall where they do.
- Trust and isolation model — what is verified, and what is not claimed.
- Report a reproducible issue — reporting something that is genuinely broken.