DeepSeek Harness Plugin Manager
DeepSeek Harness Plugin Manager: Install, Toggle & Unload
- Author
- DeepSeekAgent.io Editorial Team
- Published
- Updated
DeepSeek Harness v0.1.6-alpha.2 adds Plugin Manager to the base Profile and exposes both a Plugins page and an Agent-facing plugin_manager tool. The resulting lifecycle covers discovery, Bundle installation, configuration, live enable and disable operations, removal, and persistence in the current Profile.
Plugins are now managed as durable workspace capabilities instead of extensions that require direct configuration-file edits. For plugin authors, successful installation is only half of the contract: load, live disable, re-enable, and final unload all need explicit verification.
Where Plugin Manager sits
The alpha.2 Base Composition mounts two entries:
plugin-manager → @deepseek-ai/dsh-plugin-manager
tool-plugin-manager → @deepseek-ai/dsh-plugin-manager/tools
The Base Composition is shared by Web, Headless, SDK, and ACP profiles. plugin-manager provides the management service, while tool-plugin-manager registers controlled operations as a model-visible tool. The Plugins page and the Agent tool therefore operate on the same Profile state.
Six management actions
plugin_manager selects an operation through its action field:
list_plugins
list_bundles
set_plugin
set_bundle
install_bundle
remove_bundle
Plugin and Bundle represent different levels. A Plugin is a concrete entry loaded by a Profile; a Bundle is an installable group that can be toggled as a unit. List the current state first, obtain exact identifiers, and then mutate it.
Listing
list_plugins and list_bundles accept offset and limit, with a maximum page size of 100. Clients and Agents should paginate instead of assuming one response contains the whole catalog.
Enabling and disabling
set_plugin targets a Plugin Entry ID, while set_bundle targets a Bundle name. Both require an explicit enabled value. Live profiles apply the change immediately; startup profiles may require a restart.
Installation and removal
install_bundle accepts a package specification and can choose whether the Bundle starts enabled. remove_bundle removes an installed Bundle. Both modify durable Profile state and can affect future and currently running Sessions.
Why every operation is privileged
The official tool requests danger-full-access or per-call approval before it acts. Its own permission text identifies the boundary: Profile mutations persist across Sessions, and installed Host code runs outside the workspace sandbox.
Review the operation at four layers:
| Layer | What to verify |
|---|---|
| Package source | name, version, publisher, and source repository |
| Installation | build scripts and the resources they access |
| Runtime | tools, routes, events, and background jobs registered |
| Persistence | target Profile and which Sessions inherit the change |
When an installation finds build scripts, it returns their packages in pendingBuilds. Continue only after the user approves the corresponding names through approvedBuilds. Keep the approval scoped to the current dependency result.
How live toggles work
Alpha.2 moves plugin dependency lookup to runtime and lets Plugin Manager unload plugins. A live Profile typically moves through this state sequence:
installed, disabled
→ resolve dependencies
→ activate and register capabilities
→ running
→ stop new calls
→ release resources and unregister
→ installed, disabled
Disable behavior must mirror activation. Every resource created during load needs a matching release path.
| Load action | Unload counterpart |
|---|---|
| register a Tool or command | unregister it |
| add an event listener | remove the listener |
| start a timer | clear the timer |
| create a file watcher | close the watcher |
| open a port or connection | close the server, socket, or client |
| create temporary data | remove resources that are safe to delete |
Re-enabling is the most revealing test. Duplicate events, duplicate Tool names, or a growing number of background jobs usually means the previous unload was incomplete.
Plugin, Bundle, and Profile
The three concepts operate at different scales:
- Plugin: a concrete capability or service instance, such as a Tool provider;
- Bundle: an installable and distributable group of Plugins;
- Profile: the final composition that selects Bundles and Plugins for a DSH environment.
A marketplace can present a Bundle's purpose, version, source, and install entry. Inside DSH, Plugin Manager expands it into the concrete Profile entries that the runtime manages.
The Creator-mode change
Alpha.2 removes Creator mode's previous Cordis dynamic-definition and execution tools. Creator now installs persistent plugins through Plugin Manager:
describe the capability
→ generate or select a Bundle
→ review manifest, dependencies, and scripts
→ install into a Profile
→ enable and validate
→ reuse in later Sessions
Generated output therefore needs a complete package and lifecycle. Code that runs once inside a Session has not automatically met the requirements of an installable plugin. A Creator Bundle needs a defined entrypoint, configuration schema, dependencies, permissions, activation diagnostics, and unload behavior.
Regression tests for plugin authors
1. Cold start
Install into a Profile with no old instance or cache. Verify dependency resolution, defaults, and first activation.
2. Live disable
Keep a Session open while disabling the plugin. Confirm that new calls stop, in-flight work reaches a clear outcome, and background resources close.
3. Re-enable
Enable it again in the same process and verify that tools, commands, and events register exactly once.
4. Configuration update
Change a material setting. Check that hot-reloadable state updates and restart-only state says so clearly.
5. Remove and reinstall
Remove the Bundle, check for dangling Profile references, then install the same and a newer version to test residue and migrations.
6. Multiple Sessions
Open two Sessions, trigger a toggle from one, and verify that the other observes a consistent state.
What this enables for a plugin marketplace
A marketplace used to solve primarily for discovery. Plugin Manager adds the runtime path for installing a Bundle into a Profile and managing it safely. Marketplace entries can expose:
- exact package name and compatible DSH versions;
- Plugins contained in the Bundle;
- configuration and default permissions;
- install or build scripts;
- live-unload support or restart requirements;
- data retained after removal;
- source repository, releases, and maintainer.
That information helps users understand the boundary before installation and gives DSH's approval surface more concrete context.
Related reading
- DeepSeek Harness v0.1.6-alpha.2 update
- DeepSeek Harness Agent Preset vs Plugin
- DeepSeek Harness security guide
- Complete DeepSeek Harness setup guide
FAQ
Do the Plugins page and plugin_manager tool change the same configuration?
Both use the Plugin Manager service for the current Profile. Changes affect other Sessions using that Profile.
What is the difference between disabling and removing a Bundle?
Disabling preserves the installation and configuration for later reactivation. Removal deletes the Bundle and requires installation and any migrations before reuse.
Why can plugin installation run build scripts?
Some npm dependencies build native modules or generated artifacts during installation. Plugin Manager lists pending scripts and continues those steps only after explicit approval.