Extension permissions and trust
ShellCanvas takes extensions from three sources, and they are not equally contained. Knowing which is which tells you what a given "yes" actually grants.
How it works
Three kinds of extension
| Kind | What it is | Containment |
|---|---|---|
| Themes | JSON data: colours and a few sizes | No code at all. Nothing to grant. |
| Installed apps | A package of JavaScript and CSS, loaded into an isolated frame | A sandboxed frame with no network access and a permission-checking broker. Native frame probes passed on Windows, Linux and Apple silicon. |
| Connection adapters | A native executable that supplies files, a console, settings or custom services | None. Native code, running with your operating-system permissions. |
An adapter is the one to think hardest about: installing it is like running any other program you downloaded. ShellCanvas reviews its identity and hashes its files, and says explicitly that a hash identifies content but does not authenticate a publisher.
What an app can ask for
An app declares permissions in its package; you see them, in plain language, before installing:
| Permission | What the app may do |
|---|---|
system.storage | Keep its own local data and settings |
system.dialogs | Show message boxes and file pickers |
system.network | Send data to API endpoints you configure for it |
system.console | Open and control remote consoles |
files.read, files.edit, files.create | Read, change and create files on the connected host |
files.manage, files.move, files.copy | Rename and delete, move, copy |
files.upload, files.download | Transfer files between your computer and the host |
system.clipboard.read / .write | Read clipboard text, including content from other apps, or replace it |
system.clipboard.image.read / .write | The same for images |
system.clipboard.files.read / .write | Work with files copied for transfer |
host.settings.read / .write | Read or change settings the device exposes |
services.<id> | Call every method of one adapter's custom service |
How a grant is enforced
Two independent checks stand between an app and an action:
- The grant. The desktop intersects what the package declares with what you approved. Anything else fails with denied, in the broker, not in the app.
- The capability. The connection must actually offer the service. A host without SFTP may offer only a limited file fallback, so a file grant cannot enable actions that fallback does not advertise.
An app therefore cannot widen its own access by asking again at runtime, and a permission you approved yesterday does not apply to a host that cannot serve it.
What no app ever receives
API keys it asked you to configure, the local paths you pick in a download dialog, native session handles, direct desktop IPC, browser network access, and any other app's data. App storage is keyed to the installation, so two apps cannot read each other's state.
Updates and removal
An update is reviewed like a new install, and newly requested permissions start unselected. Windows that are already open keep the version and grants they started with until they close. Removing an app retires its installation identity; a reinstall starts with empty storage and no access to the old saved connections. Old local records and credential-store entries are not automatically erased.
You can disable an app instead: it stops launching but keeps its data and its open windows.
Boundaries
- Installed app isolation has targeted native probes on Windows, Linux and Apple silicon, using a frame without same-origin privileges, a strict content policy with no network access, and a broker that checks every call. Broader live Linux and macOS sessions remain untested.
- Containment of hostile code is not claimed. The boundary is designed to stop an app doing what it was not granted, not to withstand a determined attacker, and there are no CPU or memory limits.
- Adapters are outside all of that. They are trusted native programs; app permissions do not constrain them.
- Bundled apps — Files, Terminal, Editor, Host details — are part of ShellCanvas itself. Their declarations prevent accidental undeclared calls; they are not a security boundary.
- A package hash is not a signature. It identifies reviewed bytes, nothing about who produced them.
Related guides
- Install and update apps — the review screens in practice.
- Trust and isolation model — the same boundaries from the implementation's side.
- Adapter packages — what installing an adapter involves.
- App lifecycle and services — how permissions and availability behave for developers.