Plugin system

Understand plugin delivery, profile scope, desktop integration, and recovery.

Harness plugins can extend the host runtime, contribute tools, and add UI integrations. The desktop app adds lifecycle management and a controlled bridge to native features.

Responsibilities

Component	Responsibility
Harness host plugin	Registers tools, routes, system context, and lifecycle hooks
Client plugin	Adds panels or UI behavior to the Harness web application
Tauri bridge plugin	Exposes approved desktop commands and events to the embedded client
Desktop manager	Installs, upgrades, removes, repairs, and reports plugin state
Profile	Owns its plugin declarations and configuration

Built-in plugins and recovery

Before Harness starts, the desktop checks the active profile and restores missing integrations or outdated paths from bundled copies. Failures are logged. The built-in bridge can recover automatically, but first-time preparation of runtimes, the core, and selected community plugins still needs network access.

The current release manifest contains 13 built-in packages:

Role	Built-in packages
Native bridge and UI	dsh-tauri, dsh-tauri-ui, dsh-tauri-mobile-ui
Workspaces, sessions, and local kernels	dsh-tauri-kernel, dsh-tauri-worktree, dsh-tauri-archive, dsh-tauri-rightclick
Configuration and connections	dsh-tauri-extension, dsh-tauri-model, dsh-tauri-remote
Background and system features	dsh-tauri-scheduler, dsh-tauri-pet, dsh-tauri-notification

Mobile UI adapts the browser interface; Remote manages SSH and inbound sharing. Kernel connects existing Codex/Claude CLIs. Its interface requires Harness 0.2.1-alpha.2 or newer and actual bridge capabilities; being bundled does not make every feature available on the older recommended core.

Preset and community plugins are installed, upgraded, or removed as needed. running-changes is not shipped in this release. dsh-win-terminal-inspector is deprecated and startup attempts to remove it automatically; it is no longer an optional Minimal repair choice.

Local paths and hot reload

Besides registry sources, plugins can be mounted from a local directory: the spec is normalized to link: plus an absolute path, so the profile stores a link declaration to the source directory rather than a copy.

The desktop keeps a separate HMR patch layer for these plugins. Before Harness starts, the mounted local source directories become watch roots, written to cordis.hmr.patch.yml in application data and injected with --patch into the core’s @deepseek-ai/dsh-hmr. That file is independent of profile patches you write by hand and is removed when the switch is off or no local plugin is mounted.

The patch layer only defines the watch scope: the core’s HMR performs the actual reload, disposing and re-importing the plugin and rebuilding its fiber without restarting the Harness service. Ignore rules cover node_modules, hidden directories, and cache and data directories.

Communication path

Mobile UI only adapts the client. Remote and Kernel communicate through their host HTTP routes; Kernel then starts local CLI subprocesses. Features needing native desktop capabilities use this bridge path:

1. The embedded Harness client invokes an integration exposed by its client plugin.
2. The plugin sends a structured request through the desktop bridge.
3. Tauri command handlers validate the operation and call the responsible Rust service.
4. Results or lifecycle events return to the client and update its panel state.

Plugin installation is code installation. Profile scoping prevents configuration collisions, not malicious filesystem, process, credential, or network access. Review third-party source and pin trusted versions where possible.

For user-facing operations, see Plugins.