DSH plugin creation mode: persist config via plugin_manager

A DeepSeek Harness (DSH) plugin can be configured and persisted with prompts: in creation mode, the agent writes a config-only bundle, inserts the target plugin in a patch, and installs it via plugin_manager install_bundle. The plugin config belongs to the current profile, affects its sessions, and survives a process restart; with HMR enabled, new tools appear in the same running session. This is the official path to change plugin config in natural language without editing files by hand.

What a DSH plugin creation mode provides: Plugin Manager and read-only runtime inspection

Creation mode provides two things: Plugin Manager and a read-only runtime inspection (source). The division of labor is:

1. Plugin Manager — installs / removes bundles and disables entries. Expect: the agent lands config changes from prompts.
2. Read-only runtime inspection — reads the current running state. Expect: you can see the current state before changing config, avoiding blind edits.
3. Config ownership — plugin config belongs to the current profile and affects that profile's sessions. Expect: what you change is this profile's bundle and patch, and it survives a restart.

This means two things: first, prompt-based config is not temporary in-session state but is really written into the profile; second, it uses the same config system as custom profiles, one edited by hand and the other edited by the agent.

How a DSH plugin installs config with prompts: an MCP server example

The official example connects an MCP server: start a Web profile, choose creation mode, and have the agent configure the server on the current profile with a prompt (source). The prompt looks like:

Configure the MCP server at <endpoint> on the current profile, named demo. Enable its tools immediately, then call its ping tool and tell me the result.

The agent's action sequence is fixed:

1. Write a config-only bundle — generate a bundle that contains only configuration. Expect: no plugin code is changed.
2. Insert the plugin in a patch — for example @deepseek-ai/dsh-mcp-client. Expect: the target plugin is mounted into the plugin tree.
3. Run plugin_manager install_bundle — install the bundle. Expect: it returns a management result, and with HMR enabled the tool appears in the same session immediately.

Verification needs two pieces of evidence: the management result application: applied, and a successful call to mcp__demo__ping. Seeing only the first is not enough to prove the config really took effect. To learn the MCP client's config fields, see MCP plugin config.

How to read DSH plugin config results: applied, restart-required, and failure

A management result has three directions, and each is read differently (source):

1. application: applied — config is active. Expect: usable in the current session, verified with one real tool call.
2. restart-required — the entry is saved but not yet active. Expect: it takes effect after a process restart; do not misread it as failure.
3. Failed entry — the config itself has a problem. Expect: fix the config per the error and retry.

Read the bundle patch before changing config to confirm the entries you are about to change; disabling an entry or removing a bundle goes through Plugin Manager, and the accepted config and connection-failure behavior follow the official MCP client reference.

Three self-checks after writing: did you double-verify with applied plus one real call; did you distinguish restart-required from failure; did you read the patch before changing it. To compare how community plugins are installed into a profile, search DSH Plugin Hub.