A StablEdge plugin is a .seplugin package that is either signed or installed with your confirmation. It can offer its own workspace interface, top bar widgets, Agent Skills and Worker processes that run in the background. The host loads, isolates and authorizes the plugin, and the plugin can use only the capabilities its manifest declares and you grant.
What plugins can do
| Contribution | Manifest field | Notes |
|---|---|---|
| Workspace interface | contributions.workspaces | An HTML page that runs in a sandboxed iframe. It can replace the file area, the editor area or both, and talks to the host through the Workspace Bridge. |
| Top bar item | contributions.topbar_items | A widget in the top bar: static text, a number that a worker method refreshes, or a small embedded page. |
| Skills | contributions.skills | A Markdown description that tells the Agent how to use the plugin. |
| Resources | contributions.resources | Static assets shipped with the package, such as icons and sample data. |
| Knowledge provider | contributions.knowledge_providers | Declares a worker that provides knowledge search. For now it is only validated in the manifest; the host does not consume it yet. |
| Worker | workers | Background logic that runs in a process of its own and talks to the host over JSON-RPC. |
| Background tasks | triggers, event_channels | Call a worker at an interval, at startup or on wake; or keep an SSE, WebSocket or Webhook connection open. |
| Credentials | credentials | Static secrets or OAuth2 tokens the host keeps and injects into a worker's requests as declared. |
A plugin must provide at least one of knowledge_providers, workspaces, skills or resources.
How it runs
- Host: The StablEdge desktop app. It checks installs, grants permissions and manages sessions, and it carries out all network and file access on the plugin's behalf.
- Workspace interface: The
payload/ui/*.htmlinside the package, running in an iframe limited by CSP. It can reach the host only through thewindow.stabledgePluginSDK. - Worker: The
payload/worker/*inside the package, running as a child process and exchanging messages with the host over JSON-RPC (protocol version2.0) on standard input and output. - Service: A callable service published by the host or by another plugin, reached through the
service.invokepermission.
Security model
- Sealed file set: The manifest's
fileslist the SHA-256 of every file in the package. They are checked one by one at install, and an extra or a missing file makes the install fail. - Least privilege: Every capability must be declared in
requested_permissions. Required permissions are granted at install; optional ones you tick yourself. - Signing and trust: A plugin whose signature checks out against the official public key comes from the official source; every other plugin is treated as a developer build, and you must allow unsigned plugins in Settings before it can be installed.
- Disabled by default: A newly installed plugin stays disabled until you enable it.
Protocol versions
The current manifest protocol is v3 ("schema_version": 3). v1 and v2 manifests still install, for compatibility and migration only; new plugins always use v3.
Next steps
- Quick start: write a workspace plugin from scratch and install it in the desktop app.
- Manifest reference: the complete description of manifest fields.
- Permissions: what the 14 permissions are for and how they are granted.
- Example plugins: the bundled PC Control plugin and common manifest patterns.