Plugins

Open the plugin catalog, inspect the declared source, permissions, platforms, runtime requirements, and exact revision, then install the repository. Catalog selection never approves or enables code.

swemux plugin install OWNER/REPOSITORY --ref RELEASE_TAG
swemux plugin list
swemux plugin approve PUBLISHER.PLUGIN

The catalog supplies a literal release tag, which pins the inspected release. A branch is accepted but is a moving channel, and every changed byte still requires approval.

The configurable development root defaults to ~/swe-mux-plugins. Settings and swemux plugin discover inspect only direct child repositories with a root manifest. Discovery is inert: each candidate still needs an explicit Link action and content approval. An arbitrary repository remains linkable when a monorepo, worktree, or alternate drive should stay where it is.

swemux plugin development-root ~/swe-mux-plugins --create
swemux plugin discover
swemux plugin link ~/swe-mux-plugins/my-plugin
swemux plugin approve PUBLISHER.PLUGIN

After an edit, run swemux plugin refresh, validate, and approve the current bytes. Actions pick them up on their next run. A live pane remains its old process until it is closed and relaunched or replaced with swemux plugin restart-panes PUBLISHER.PLUGIN.

Managed updates are never automatic. Checking reads source-channel metadata only. Downloading creates a separate durable review stage while the active version keeps running. Settings shows exact revision and permission or capability changes before a separate approval promotes those bytes.

swemux plugin check-updates
swemux plugin update PUBLISHER.PLUGIN
swemux plugin approve-update PUBLISHER.PLUGIN

A plugin process runs as your operating-system user. The permission list limits which cooperative swe-mux callback operations receive a token. It is not a sandbox for files, processes, credentials, or network access.

• Acquisition, catalog browsing, validation, and inspection execute no plugin code.
• Approval is bound to the complete source content and security-relevant manifest fields.
• An update review leaves the active version enabled until separate approval.
• Uninstall retains plugin config and state unless purge is separately confirmed.

• ActionsBounded explicit commands that exit and retain capped output in the command log.
• PanesInteractive terminal tools opened as a Project tab, right-hand split, or popup.
• EventsBounded commands subscribed to exact normalized application events.
• StartupOne bounded restoration command after enablement or daemon startup.
• LinksValidated terminal URL patterns routed to an action from the same plugin.

1. Create one standalone repository with a root manifest, directly runnable source, tests, README, and licence.
2. Declare every platform, runtime, capability, context, and callback permission the code requires.
3. Run swemux plugin validate ., link it locally, and exercise every contribution and lifecycle transition.
4. Publish a GitHub release whose tag matches the manifest version, then add the swe-mux-plugin topic.

swemux plugin validate .
swemux plugin link .
swemux plugin approve PUBLISHER.PLUGIN
swemux plugin disable PUBLISHER.PLUGIN
swemux plugin uninstall PUBLISHER.PLUGIN

The catalog reads only public repository metadata and the manifest at an exact commit. A valid community listing is discoverable, not reviewed or endorsed.