Introduction¶

Super-agent is an active agent. Once started, it stays resident in the background waiting for events. If used only when necessary, the resident Node process, loaded modules, and runtime state still occupy memory; moreover, without a unified switch, multiple DSH sessions would control the same background process, causing their states to overwrite each other. The mingoyung/dsh-superagent-power introduced below is a client plugin designed to solve this problem: it places the Super-agent background startup and shutdown inside the input bar button, allowing for on-demand exit and memory release.

It is independently maintained by MingoYung and is not an official DeepSeek plugin; the upstream is DeepSeek Harness and the Super-agent research prototype. This plugin does not replace Super-agent itself but only manages the already installed independent Super-agent profile.

What is this¶

One-sentence definition: It adds a Sup button to the DSH input bar to globally start and stop the Super-agent independent background process; when closed, it performs a normal cleanup procedure before exiting.

• Maintainer: MingoYung
• Category: Client (Browser-side UI + Control Service)
• Target Platform: Windows / DSH NEXT
• Version: v0.1.1, MIT License
• Directory Page: https://www.skillhub.cn/plugins/MingoYung/dsh-superagent-power
• GitHub: https://github.com/MingoYung/dsh-superagent-power

The input bar button is the short tag Sup, and the panel displays the full name Super-agent. The button is located in the bottom tool area of the input bar and can be placed alongside buttons for Permissions, REA, Concurrency, etc.

Core Features¶

On-demand Start/Stop Background, Release Memory¶

After Super-agent starts, it continues to occupy memory even if no tasks are currently executing. This plugin moves the process start and stop into the daily chat entry point: click “Start” when needed, and “Stop” when finished. Closing will first call Super-agent’s normal cleanup procedure, then exit the independent CLI process; only after confirming the process has exited does the interface display “Closed”.

The README records a local acceptance observation: the original background main process RSS was about 468 MB, and the process exited after closing. This is an observation for a single environment and is not a promise that all machines will save the same amount of memory; actual usage depends on the version, loaded plugins, tasks, and session state.

The Switch is Global, Not Belonging to a Single Session¶

If Session A is set to “On” and Session B is set to “Off”, but they operate the same background process, conflicts or misleading status will occur. Therefore, the switch belongs to DSH_HOME + Super-agent profile, not to a specific chat session. Switching sessions does not automatically start or close the background; when multiple sessions operate simultaneously, a state version check rejects expired requests to avoid silently overwriting new choices.

Input bar tool area:  [Permissions]  [REA]  [Concurrency]  [● Sup]
                                     │
                         Super-agent · Global
                         Shared by all sessions
                         Closed              [Start]

Opportunity to Clean Up Tasks Before Closing¶

When there are active tasks, the panel requires a second click on “Interrupt Task and Close”. The shutdown flow calls Runtime.stop(), then uses DSH’s appExit() to exit, providing a normal path for task cancellation, background work cleanup, and state persistence. If the control interface is disconnected or the process does not exit, the panel will display an anomaly and will not directly mark the state as “Closed”.

Status Points and Panel¶

The plugin distinguishes four states at status points to avoid duplicate operations and false positives:

Other behavioral points: Global state persistence; the last selection is used when the desktop is started again; requesting background exit on normal desktop shutdown; single controller and serial operations prevent duplicate starts; starting a second instance is rejected if the port is occupied; sessions sharing state within the same rendering window, other visible windows refresh approximately every 5 seconds, refreshing immediately upon refocusing. In the closed state, only the button and control service within the desktop browser are retained, without adding an extra resident controller process.

A trade-off needs to be noted: during the closed period, it will not listen to or process external tasks. The plugin does not do “idle auto-close” because waiting for new events is one of the purposes of an active agent; no tasks do not mean the user does not need it on duty; just keep it open when continuous duty is needed. Closing retains configuration and history, but the recovery behavior after interruption is determined by the upstream Super-agent, and it is not guaranteed that external commands can continue from the interruption point.

Compatibility¶

v0.1.1 explicitly supports DSH 0.2.1-rc.4, 0.2.1-rc.5, and 0.2.2-rc.1. Windows local verification has checked DSH NEXT 2.0.21-next and 2.0.22-next; the new version corresponds to Cordis 4.1.0. CI runs the same set of isolated tests for the three DSH versions mentioned above.

An upgrade check on 2026-11-05 confirmed that the new desktop can still load Sup, open the panel, and read global state; new Gateway and process control regression tests pass. The independent Super-agent still uses CLI 0.2.1-rc.5, and its isolated profile start/stop and process exit tests pass again. Desktop updates do not mean the independent CLI has been updated; this time, the Super-agent runtime was not upgraded to 0.2.2-rc.1.

The DSH host interface and Super-agent internal lifecycle interfaces may still change, and other versions need re-verification. macOS / Linux have not yet completed acceptance.

The plugin depends on existing interfaces like Runtime.stop(), accessing the desktop via native slots and Remote, without modifying DSH’s app.asar or patching the Super-agent core.

Installation and Enablement¶

Installation is divided into two sides: the desktop button/controller and the accompanying module inside the Super-agent process. Simply importing the desktop plugin package cannot complete the entire installation. First, ensure DSH NEXT, Node.js 24+, the independent DSH CLI, and the independent Super-agent profile are ready, then follow the steps below.

Step 1: Install Desktop Package¶

Download the .tgz from Releases, or execute npm ci, npm run check, npm pack in the source directory to build it yourself. Then install it to the desktop profile:

dsh plugin --profile desktop add C:/Downloads/local-superagent-power-0.1.1.tgz

The package name is @local/superagent-power, which is just the namespace for the local plugin; this project has not been published to the npm registry. Confirm that DSH_HOME/profiles/desktop/package.json contains this package and that there is exactly one @local/superagent-power in dsh.profile.bundles. If the installation tool did not automatically add the bundle, append it while preserving the original entry:

{
  "dsh": {
    "profile": {
      "bundles": ["@local/superagent-power"]
    }
  }
}

Then, append a configuration override with ID local-superagent-power to the desktop cordis.patch.yml. The most critical points are homePath, nodePath, cliPath, and profileName. Common configuration items are as follows:

After reloading the desktop, DSH_HOME/plugins/superagent-power/control.key will be generated. If there is no saved selection and no background to take over, it defaults to closed.

Step 2: Configure Super-agent Accompanying Module¶

Append an entry in the Super-agent profile’s cordis.patch.yml. The name points to bridge.js inside the installed desktop package:

DSH_HOME/profiles/desktop/node_modules/@local/superagent-power/bridge.js

The accompanying module runs in the same process as Super-agent, not another daemon process. Both parties must use the same homePath and profileName, and keyFile points to the control key generated in Step 1. Do not add the key file to Git or copy it into public issue reports.

Step 3: Verification¶

1. Click Sup in the input bar of any session and confirm the panel indicates “Global”.
2. Click “Start”, wait for the green dot and “Open”. A separate prompt will appear if the background business is not configured.
3. Switch sessions and confirm that the same global state is displayed.
4. Click “Close” when there are no tasks, wait for “Closed”, and check that the corresponding background process has exited.
5. If the panel prompts that there are active tasks, evaluate whether to interrupt before clicking “Close” for the second time.

Typical Usage¶

Daily usage basically only has two steps: click Sup in the input bar -> “Start” when you need Super-agent to keep watch; click “Close” to exit the background when finished. The first time you start a real business profile will restore its listening and task behavior; the README suggests choosing a suitable idle time or using an independent test profile to verify.

In the closed state, only the button and control service inside the desktop browser are retained, without adding new resident processes; global state is persisted, and the last selection is used when the desktop is reopened. If you want to stay closed next time, click “Close” on the panel first.

If startup fails, you can check DSH_HOME/plugins/superagent-power/worker.log, which is overwritten every time you start; it may contain local login links, which must be sanitized before public reporting. The plugin will not retry startup infinitely; exceptions will be displayed on the panel, and the user decides whether to retry. If the saved selection is still “Open” after an abnormal exit, the next desktop initialization will try to start once.

Suitable Scenarios and Notes¶

Suitable for these types of people:

• Only use Super-agent when needed and do not want it occupying memory in the background for a long time.
• Multiple DSH sessions share the same Super-agent profile and want a single global switch instead of session-level state.
• Want to operate the background process alongside buttons like Permissions and Concurrency in the input bar.

Notes before use:

• The plugin runs with the current DSH process permissions and can start/stop the independent CLI on the desktop. Before installation, you should read the source code and license (MIT) and confirm that the configuration paths, ports, and process parameters fit your deployment.
• This plugin is a community project, not an official DeepSeek plugin; the namespace @local/superagent-power only indicates a local plugin and does not mean it has been published to npm.
• The Sup button will not be registered on a desktop that has not loaded the bundle; just installing files without loading the bundle is ineffective.
• This plugin manages an independently running Super-agent profile and is not applicable to scenarios where Super-agent is directly loaded into the desktop main profile and then the entire desktop process is closed.
• This plugin has not modified system startup items; uninstalling will not delete business configuration and session history.

Conclusion¶

This plugin solves a specific problem: providing a global switch placed in the input bar for the resident background Super-agent, exiting the process via a normal cleanup procedure when closed, avoiding long-term memory occupation when not in use. It does not pursue more complex scheduling capabilities; the trade-off is also clear—during the closed period, external tasks are not listened to or processed. If you are already using DSH NEXT and an independent Super-agent profile, you can start by understanding the directory page and repository below.

• Directory Page: https://www.skillhub.cn/plugins/MingoYung/dsh-superagent-power
• GitHub: https://github.com/MingoYung/dsh-superagent-power