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. Windows x64 is the only platform with published installers and end-to-end validation. Other platforms build from source but are not verified, and nothing on this page should be read as support for them.
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 |
| 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, themes and connection adapters | Working on Windows; installed locally from packages |
| App SDK, adapter SDK, filesystem SDK | Provisional 0.1 prototypes; interfaces may change |
Validated narrowly
- App runtime isolation has targeted validation on Windows. It is not certified against a hostile package, and its behaviour on other platforms is unverified.
- Filesystem bridges and local drive mounting are prototype-stage and depend on a bridge application you install yourself.
- Device detection is meaningful for Linux over SSH. Everything else takes a generic path.
Not implemented
Serial, Telnet and FTP connections. Any built-in device API beyond what a provider supplies. A public extension registry, marketplace or update channel. Signed installers. Published packages for macOS or Linux. 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.