Commander Plugins

Plugin discovery

Commander discovers viewer, thumbnail, converter, packer and filesystem plugins at startup. Installed plugins can register support for specialized formats, then Commander routes matching files or operations to the plugin instead of treating them as generic content.

Plugins are intended for formats and file-like sources that do not belong in the core application: CSV and database viewers, archive and disk-image handlers, document previewers, source-code tools and other focused integrations.

Server-deployed plugins

Plugin packages are published to the download server. The website loads the live https://commander.t3.tigrisfiles.io/plugins/index.json catalog at runtime, so available plugins can be shown without baking plugin names into the static Hugo build.

The catalog exposes each plugin’s name, description, version, capabilities, supported platforms and verified package. Commander and the website only show plugins that are present in the server catalog, which keeps the public list aligned with what is actually available for installation.

Plugin sources

Inside the app, the Marketplace installs from a built-in public catalog by default. Under Settings → Plugins → Sources you can add your own catalog URLs — any index.json in the same format, including private or organization catalogs. Commander fetches every source, merges the results and badges each plugin with the source it came from; when two sources list the same plugin, the first source wins. A source that fails to load is reported without hiding the plugins that did load. Each package is verified against the SHA-256 recorded in the source it is installed from, so a plugin is only ever installed from the catalog that vouches for it.

Plugin catalog pages

The dedicated Commander plugins page separates browsing, plugin submission and custom plugin requests into tabs. Its Browse tab provides search plus type and platform filters so the catalog remains usable as it grows. The main Commander page introduces the plugin system and links to this catalog without duplicating its entries. Selecting a plugin opens its own shareable page, which derives supported formats and behavior from capabilities, then shows installation steps, compatibility, publisher, license, package size and SHA-256 integrity data when supplied by the catalog.

Catalog entries can also include richer optional presentation metadata:

These fields are optional. Older catalog entries continue to receive a complete page from their description and capability metadata, while newly deployed entries can add richer details without a website rebuild. All public metadata should describe the deployed package rather than an unreleased repository state.

Compatibility

Each plugin should declare the platforms or targets it supports. When platform metadata is present, Commander can avoid offering incompatible packages, and the website can label plugin entries for macOS, Windows or Linux.

If a plugin is installed locally but is no longer advertised by the server, the installed copy can still be discovered at startup. The server catalog only describes what is currently available to download.

Updating plugins

Because plugin availability is read from the current release’s plugin catalog, publishing a new plugin or new plugin version is a deployment operation rather than a website rebuild. After the release manifest points at the new version, the plugin catalog page and compatible app clients can load that version’s plugins/index.json on their next refresh.

Commander also supports plugin install and uninstall workflows in the app. The server catalog describes what can be installed, while local discovery determines which installed plugins are active at startup.

Long-running packer plugins can report progress while extracting or creating archives. Plugins that emit progress drive the same cancellable progress UI as native file operations; plugins that do not still run with an indeterminate operation indicator.

Submitting a plugin

Plugin maintainers can use the Add a new plugin form on the dedicated plugin catalog page to submit a public source repository for review. Include the plugin manifest, source code, reproducible build instructions and a license in the repository. The submission also identifies the plugin capabilities, supported platforms, current version, external requirements and optional media links. Descriptive metadata can be refined during review before the plugin is published.

Submissions are reviewed for protocol compatibility, packaging, catalog metadata and security before publication. Submission does not guarantee acceptance. Never include credentials, signing keys or other secrets in the form or repository.