DSH Plugins Marketplace

DSH Plugins

Plugins

/

dsh-enhanced-plugins

s

dsh-enhanced-plugins

Manifest valid4

DeepSeek Harness(DSH)一站式增强套件,基于公开插件扩展点构建,无需修改 DSH Core。提供 Windows Launcher、桌面通知与动态桌宠、Plugin Community、MCP Server Manager、模型输入类型配置、最后一条消息编辑与重新生成,以及 Claude Code / Codex Subagents 实时控制。所有功能均可独立安装,支持全量部署、

UI (client)hasBundlePatch

dsh-enhanced-plugins

中文 | English

An enhancement suite for DeepSeek Harness (DSH): seven independently installable Cordis bundles plus one Windows companion.

  • Does not modify DSH core; every Web feature uses public plugin extension points.
  • Installs everything in one pass or keeps only the independently packaged features you select.
  • Keeps Host, Web Client, and Windows Companion lifecycles and security boundaries separate.

Features · Quick start · Feature guide · Compatibility and migration · Configuration · Development

Features

The installer only needs the stable “feature ID.” Every feature also has a self-contained selective package.

| Feature | Feature ID | Selective package | Platform and entry point | What it adds | | --- | --- | --- | --- | --- | | Windows Launcher | windows-launcher | dsh-enhanced-windows-launcher | Windows Start menu | Tray controls for Web, Headless, profiles, source builds, and diagnostics | | Desktop alerts and pet | notification | dsh-enhanced-notification | Windows; Settings → Desktop Pet | Task sounds, a custom WAV library, and a native animated pet | | Plugin Community | plugin-market | dsh-enhanced-plugin-market | Web; Settings → Plugin Community | Search, safely preflight, install, and uninstall community plugins | | MCP server manager | mcp-server-manager | dsh-enhanced-mcp-server-manager | Web; Settings → Plugins | Manage stdio / Streamable HTTP servers and import local configuration | | pi-ai model request types | model-input-types | dsh-enhanced-model-input-types | Web; Settings → Plugins | Declare whether a model accepts text-only or image requests | | Edit last message | edit-last-message | dsh-enhanced-edit-last-message | Web; latest user message | Change that turn and regenerate in the same session | | Product subagents | sub-agent | dsh-enhanced-sub-agent | Web; Settings → Subagents | Enable or disable Claude Code / Codex tools in real time | | Official Team monitor | agent-team-monitor | dsh-enhanced-agent-team-monitor | Web; team icon on the current conversation composer | Role-grouped running/history child sessions, native details, Team dependencies and mailbox counts |

The historical aggregate package is dsh-enhanced-plugins. Launcher-managed installs now express “all” as every independent Profile package plus the required global Launcher, so any one Profile feature can later be removed without changing the others.

Quick start

6.2.2 launch modes and compatibility

Plugin 6.2.2 supports exactly DSH 0.1.5-rc.2 at source commit c291e7961a515f6d7af9304e7fd1d257929aef26. Release tag: 6.2.2/dsh-0.1.5-rc.2(c291e7961a).

This release reduces repeated Launcher layout during navigation, scrolling, and feature filtering, and refreshes button labels when launch mode changes. Each function retains its latest execution log, with bounded reads for the UI.

Choose Browser or Source Desktop at the top of Launcher Overview. The saved choice also controls login startup; existing settings default to Browser. Source Desktop reuses the bound DSH checkout and the Launcher toolchain: Start Desktop runs pnpm run start:desktop, while Build and Start runs pnpm run dev:desktop. Missing build artifacts disable ordinary startup and direct you to Build and Start. Install the checkout dependencies with pnpm install --frozen-lockfile first. Desktop output and failures appear in Desktop Logs; Stop terminates only the Launcher-owned invocation. An active build invocation blocks starting Web against the shared artifacts. The old DesktopExecutable setting is ignored; no EXE selection is required.

The official source command regenerates apps/desktop/.desktop-build/development/project on each launch. Its data defaults to the sibling home directory there, or the inherited DSH_HOME; DevTools stay closed unless explicitly enabled with DSH_DESKTOP_OPEN_DEVTOOLS=1. This source mode disables the official package-management UI and has no public argument to inherit Web bundles. Launcher therefore does not copy Web plugins into its generated profile. The packaged Desktop application owns its separate desktop profile; dsh plugin --profile desktop remains unsupported.

Recovered inbox edits retain replacement semantics. Missing or stale edit targets fail explicitly instead of silently appending ordinary input.

Requirements

  • Node.js 22.19.x, or Node.js 24 and later.
  • A recent DSH Web profile that runs from source; see the DSH Web UI quickstart.
  • Supported DSH source baseline: 0.1.5-rc.2. Other releases are not included in the compatibility declaration.
  • This DSH version no longer requires fs-ext for Session locking. Follow the target checkout’s native build requirements; Launcher uses the system .NET Framework csc.exe. Do not skip dependency install scripts.
  • Windows Launcher, native sounds, and the desktop pet require a full Windows desktop edition with Windows PowerShell 5.1: Windows 10 version 1607 or later, or Windows 11. The required OS capabilities are the same on Home, Pro, Education / Pro Education, and Enterprise; Windows in S mode, IoT / reduced-footprint editions, and Windows 10 versions 1507 and 1511 are outside this baseline. Windows feature updates outside Microsoft's lifecycle are best-effort because the required Node.js toolchain does not guarantee end-of-life operating systems. The installer does not depend on a particular tar.exe. The remaining features are cross-platform.

[!IMPORTANT] DSH remains a developer preview. If a DSH upgrade causes compatibility issues, check the verified version and commit above first.

[!CAUTION] Check the DSH/plugin repository layout before copying an install command:

  • Sibling-directory install: both repositories share the same parent directory; use the commands below as written.
  • Different-directory install: the repositories have different parent directories; add -DshCheckout "absolute path to the DSH source" to the command.

Install every feature

When both repositories share a parent directory, run this from the root of this repository:

<workspace>/
├── deepseek-harness/
└── dsh-enhanced-plugins/
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\migrate-to-enhanced-plugin.ps1

Omitting -Features, or passing -Features all, installs the seven independent Cordis packages and the required Windows Launcher; it no longer uses the root aggregate package to represent “all.” The launcher is deployed to %LOCALAPPDATA%\DeepSeekHarness\Launcher and creates a Start menu shortcut. Add -CreateLauncherDesktopShortcut if you also want a desktop shortcut. Running the installer directly only installs or updates the program files; it does not start or open Launcher. An update initiated inside Launcher still performs the required version restart and readiness check.

If the DSH checkout is not a sibling, provide its location explicitly:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\migrate-to-enhanced-plugin.ps1 `
  -DshCheckout "E:\projects\deepseek-harness"

Install selected features

List the stable feature IDs exposed by this version:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\migrate-to-enhanced-plugin.ps1 -ListFeatures

Then pass the final set you want to keep. For example, install desktop alerts, MCP management, and message editing only:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\migrate-to-enhanced-plugin.ps1 `
  -Features notification,mcp-server-manager,edit-last-message

Common combinations can replace the -Features value in that command:

| Goal | Feature set | | --- | --- | | Windows desktop experience | windows-launcher,notification | | Agent and model enhancements | mcp-server-manager,model-input-types,edit-last-message,sub-agent | | Plugin discovery and integration management | plugin-market,mcp-server-manager |

-Features is not an additive list. It describes the final project feature set that the target Profile should retain. Windows Launcher is a required global component: it is added by the backend, is not written in the list, and cannot be removed through feature selection. -Features none removes this project's Profile packages while keeping Launcher. The installer:

  1. Installs dependencies and builds every selected feature.
  2. Installs and verifies that every selected bundle or companion loads.
  3. Only then removes the aggregate package, unselected sibling features, and declared legacy conflicts.
  4. Detects and cleans up the retired file-reference plugin.

Launcher plugin management

The source installer records the DSH checkout, this repository's source path, Git remote/ref, source revision, and each managed Profile's desired set in %LOCALAPPDATA%\DeepSeekHarness\Launcher\install-state.json. The control center's Plugin Management page then provides:

  • a dynamic feature catalog generated from packages/*/package.json, so normal new features do not require Launcher changes;
  • first-use default selection, per-Profile desired state, individual install/removal, and aggregate-package migration;
  • Windows system-proxy resolution for the plugin remote URL before a safe Git fetch; when Windows selects a proxy, a command-scoped Git setting applies it to every backoff attempt and expires afterward without changing existing Git configuration. Connection-reset retries switch to HTTP/1.1, followed only by a local merge --ff-only so pull does not make a second network request; when Git is unavailable, Launcher downloads an exact-commit source ZIP, while an extracted source directory or manual source ZIP can be bound without network access;
  • npm ci, a production npm run build, and runtime-entry validation in a persistent isolated sources/runtime-* snapshot only when the source revision or desired feature set changed; Profiles always link to a retained active snapshot, while snapshots no longer referenced by any Profile are safely removed; repository-wide development typechecks remain a source-checkout concern so sibling DSH type paths do not block an isolated install; native stderr warnings remain in the log while failure is determined by the real process exit code; Launcher-owned DSH is stopped only after these checks pass;
  • an external coordinator that switches Launcher versions only when the executable hash changes, waits for readiness, rolls back failures, and restores DSH when appropriate; restoration is reported successful only after DSH remains Launcher-owned for 15 consecutive seconds;
  • recovery of a still-running or interrupted coordinator after Launcher restarts, plus preservation and partial reconstruction when install state is damaged.

The first version supports only a local DSH source checkout and source installs of this repository. It does not support npx, a global dsh, npm-published packages, or GitHub Releases. A dirty, ahead, or diverged Git checkout is never reset, rebased, or overwritten.

If a prerequisite step fails, the installer does not dismantle the previously working combination. Restart the current Web profile once after a successful install if DSH is already running.

Feature guide

1. Windows Launcher

windows-launcher · Start → DeepSeek Harness Launcher · Windows 10+

DeepSeek Harness Windows Launcher overview

A Windows control center outside the Cordis plugin tree for local DSH users who do not want to keep a terminal open.

  • Web control: inspect status, start, open, restart, or stop Web; identify services already bound to the port without taking ownership of them. Even when browser auto-open is disabled, Open Page uses the authentication entry for the current Launcher-owned DSH process, and launch tokens are not written to Launcher logs.

  • Tasks and profiles: run one-shot Headless tasks and background profiles with unified UTF-8 results and logs.

  • Web runtime: Overview places a compact Browser / Source Desktop selector beside the title and combines service status with primary actions in one light card. Runtime and startup options follow below. The selector supports Left/Right keys; actions fit one row or a balanced two-row layout in narrow windows. The runtime card shows NVM sandbox/system mode, required and actual Node and npm/pnpm/Yarn versions, detection sources, and preparation/failure status. The Node version selector offers Automatic (highest compatible version) and the installed NVM versions. Choosing a version saves it for subsequent Web/Desktop starts, DSH builds, and plugin source operations; existing settings default to Automatic. Refresh updates the installed-version list. A manual version must still satisfy project requirements; a missing or incompatible selection fails without switching to another Node. Missing saved versions remain visible so you can choose another version or return to Automatic. Running versions come from the current launch record; changing the selection does not restart an existing process, and external service versions are never inferred.

    Every Web start, including tray, restart, and login startup, detects nvm-windows. When installed, Launcher reads the bound DSH checkout or a recognizable npm DSH shim. Node selection follows .nvmrc, .node-version, volta.node, then engines.node, always respecting engines.node, and chooses the highest matching installed NVM version in Automatic mode; manual mode uses only the saved version. Manager selection prefers packageManager/devEngines.packageManager, then Volta, engines, and lockfiles. Lockfiles identify the tool or Yarn generation, not an exact version. Missing manager versions download into Launcher's sandbox directory on first start and are reused; conflicting declarations produce an error.

    Sandbox mode invokes the same DSH CLI directly with the selected Node, isolating the service PATH, npm/Yarn global install directories, and npm/Yarn/Corepack caches without running nvm use or changing system Node, NVM links, or DSH source. pnpm retains its user/project store configuration and normal store location so existing source and profile dependencies can be reused. Launcher and the candidate installer clear only storage overrides inside the Launcher sandbox inherited from older versions; the installer restores its caller environment on exit. This is process-level toolchain isolation, not a file or network permission sandbox. Without NVM, the original launch path remains intact. Missing compatible Node, invalid declarations, or download failures stop startup with an explanation; install missing Node with nvm install. Unrecognized custom launchers need a DSH source binding. DSH source builds and plugin source operations reuse the Overview Node selection and sandbox, including the declared DSH pnpm and npm bundled with that Node. After a DSH pull, detection runs again before clean; build detection does not require installed dependencies or CLI artifacts. Plugin operations validate the candidate source Node/npm requirements before npm ci, building, stopping DSH, or installing profiles; incompatible requirements fail instead of selecting a different Node. Build/update logs record the selected runtime. Without NVM, Automatic mode retains the system toolchain; a saved manual selection reports an error until NVM is restored or Automatic is selected. Headless and other profiles retain their existing flows.

  • Source maintenance: Update Source and Build (更新源码并构建) runs git pull --ff-only against the bound DSH checkout, then pnpm run clean, pnpm install --frozen-lockfile, and pnpm run build in order. Before pulling an HTTP(S) remote, Launcher resolves the current Windows system proxy for that remote URL. When Windows selects a proxy, Launcher applies it through a command-scoped Git setting for this pull only; the setting expires after success or failure and never writes or overwrites repository, user, or system Git proxy configuration. SSH remotes do not use this HTTP(S) proxy discovery. Build Only (仅构建) uses the current local source, skipping Git updates while still running all three pnpm steps. Without Git, Update Source and Build can also skip the pull after confirmation. Both build buttons stay disabled during an operation to prevent duplicate runs. Before cleaning, Launcher checks the checkout for clean/build scripts and a lockfile, and verifies that pnpm is available. Any failed step stops the remaining steps; lockfile errors never fall back to an unfrozen install. Git progress and pnpm warnings are not treated as failures: the real exit code determines the outcome. The page distinguishes pull, clean, dependency-install, build, and environment failures, with larger log text and an Open Log Folder action. Full UTF-8 output, command-engine errors, and the final outcome remain in logs/dsh-build.log across refreshes and page navigation. Stop DSH instances using this checkout before running: clean removes existing build artifacts, which are not restored if a later step fails. Launcher does not automatically stop or restart DSH for this action; start it manually after a successful build.

    The source-operation process temporarily sets pnpm_config_verify_deps_before_run=false so pnpm's automatic install before scripts cannot change the lockfile before the explicit frozen install. This does not edit repository or global pnpm settings.

  • Diagnostics: collect command, port, working directory, status, and log information, with a dedicated DSH Source page.

  • Desktop behavior: system tray, optional login startup, a centered vertical layout at every window size, per-monitor DPI scaling, and consistent rounded scrollbars for both pages and text areas independent of the Windows theme. Diagnostics, task input/output, source-build logs, and plugin-operation logs share the same styling, with mouse-wheel, touchpad, thumb-dragging, track-paging, and keyboard support. Every log view filters ANSI/ECMA-48 terminal controls that a plain text box cannot interpret, preserving readable content without rewriting the original UTF-8 log file. Launcher remembers the last display and normal window bounds, then remaps them into a visible work area when the display topology changes.

Process ownership, exit, and background behavior

Launcher only stops DSH process trees that it started. A service already using the configured port is shown as an external Web service: the page can be opened, but Launcher will not take it over, restart it, or terminate it.

The tray exposes two exit paths. “Exit Launcher Only” leaves DSH running; “Exit Launcher” first requests a safe stop of Launcher-owned services. If the service is external or the stop times out, exit is cancelled with a reason.

Tasks and profiles run in no-console child processes. User task content travels through a UTF-8 request file to the PowerShell command engine and is never concatenated into cmd.exe. Hiding the main window stops foreground polling while the tray and background services continue running.

Web, source Desktop, source builds, and each profile retain only their latest execution log. A new run replaces the previous one while keeping all stages, errors, and exit codes from that run together. The Launcher log resets after a new UI instance acquires the singleton lock; activating an existing window does not clear it. Update cleanup keeps its latest log, and plugin updates continue to reuse updates/current. Another run cannot overwrite an active execution log. Headless output is displayed after completion and replaced by the next task.

Each diagnostics or build-log read accesses at most the last 256 KiB before selecting the requested lines, avoiding full-file scans of a large current run during navigation and refresh; reads do not modify that run's log. Page scrolling does not trigger layout. Feature filtering reuses rows and preserves selections, and select-all/clear updates the change summary once. Switching launch mode refreshes button labels without requiring a scroll.

Login startup, deployment, and source binding

Login startup is off by default. You can start Launcher in the tray only, or start Launcher and launch DSH Web in the background after a 30-second initialization delay. The modes are mutually exclusive and can both remain disabled.

Versioned deployment directories keep Start menu and login-startup entries pointed at the current release without depending on profile node_modules. The installer preserves an explicitly configured DSH command. For a local DSH checkout, it generates and verifies a safe direct CLI entry and records that checkout as the only permitted source-build root.

Settings, runtime state, install state, update requests, and logs live under %LOCALAPPDATA%\DeepSeekHarness\Launcher. Tray updates and plugin changes reuse the fixed updates\current workspace. Before the next operation, its previous requests, results, logs, and source ZIP are cleared, retaining only the latest operation. A running coordinator prevents the workspace from being overwritten, and Launcher resumes tracking it after restarting. After the control center loads the installation state and after update operations finish, Launcher automatically removes unused legacy GUID update directories in the background, including their build files, node_modules, and logs. Directories with a running coordinator, a source binding, or references from any Profile remain and are checked again when the control center is opened or a later update finishes. Source bindings inside old update directories migrate to retained sources snapshots during successful installation; active plugin snapshots are still managed under sources. Cleanup supports long paths and never follows directory links. Unverifiable or failed deletions are logged and retained without failing an otherwise successful installation. Launcher remains selected and required in the management UI. The control center does not self-uninstall; run migrate-to-enhanced-plugin.ps1 -UninstallLauncher from this repository to remove the program files, shortcuts, and login-startup entry. Logs and user settings are preserved by default.

2. Desktop alerts and pet

notification · Settings → Desktop Pet · Sounds and pet require Windows 10+

Desktop alerts, custom sound library, and pet settings

  • Confirmation, completion, and blocked events can each be disabled or mapped to two built-in sounds or a custom WAV.
  • Changing a sound previews it automatically, with a manual preview button as well. Shared gain ranges from 0–100%; 100% is approximately +6 dB, with soft limiting for near-peak PCM / IEEE Float WAV files.
  • Each file is limited to 2 MiB and the shared library to 64 files, all stored in the current DSH profile.
  • The pet switches live between the Flat Whale, 3D Whale, and Whale Girl characters.

| Aggregate state | Pet behavior | | --- | --- | | Idle | Sleeping loop; mouse contact or dragging triggers an interaction, with optional non-topmost idle mode | | Working | Focused swimming or operating a task panel | | Confirmation | Surprise, head turn, or question-mark cue; highest priority | | Completed | A short celebration for top-level tasks only | | Blocked | A short tired or concerned response for top-level tasks only |

The pet can be dragged across monitors and stores normalized per-monitor positions. Resolution, scale, work-area, or display-topology changes remap it into a visible area; changing the startup corner clears the drag record. The pet stays out of the taskbar and Alt+Tab task switcher; disable it in Settings when you want to hide it. Windows “Show animations” accessibility preferences reduce every state to a representative still frame when animations are disabled.

Both the resident pet and short-lived sound processes are owned by the DSH subprocess service and exit cooperatively when disabled. Companion pipe closure during Ctrl+C, plugin reload, or ordinary shutdown is treated as a normal teardown condition. A known retired pet ID is migrated to Flat Whale on the next launch; other unknown values continue to fail validation.

3. Plugin Community

plugin-market · Settings → Plugin Community

Plugin Community page

  1. The first visit uses a bundled snapshot. “Sync latest index” uses ETags to fetch a schema-validated snapshot published by GitHub Actions every six hours, retrying temporary 429/502/503/504 responses.
  2. Search by repository, package, description, or topic. A live preflight checks repository identity, commit, and distribution shape before installation.
  3. One-click install is offered only for matching npm bundles with no install lifecycle scripts. Verifiable build-free source bundles can be installed at a pinned commit after confirmation; every other path links to its installation guide.
  4. Install and uninstall run as cancellable background jobs. The target profile, bundle patch, and composition are verified afterward, with automatic rollback on failure.
  5. The Installed tab separates market-managed plugins from externally managed ones. Only the former can be removed from this page.
Index publishing, network proxies, and credentials

The .github/workflows/update-plugin-index.yml workflow publishes the market-index branch. It enumerates the complete topic, revalidates only new or changed repositories, and refuses to overwrite the last result after an abnormal shrink or failed build. This project is also a built-in verified channel contribution, so it remains discoverable before the remote mirror catches up and is not duplicated afterward.

Neither the bundled snapshot nor automated index sync requires a GitHub token. Host downloads use the global transport installed by the supported DSH versions, including its proxy validation, direct routes, and NO_PROXY rules. Set HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY in the launching environment or $DSH_HOME/.env; the market does not install or close its own proxy dispatcher. If install preflight hits GitHub API limits, Settings can store a read-only, short-lived fine-grained token. It is sent only to the local DSH Host and stored through the credentials service.

The page displays index generation time. An index older than 24 hours receives an explicit warning while the last usable snapshot remains available.

4. MCP server manager

mcp-server-manager · Settings → Plugins → Plugin configuration → MCP Servers

MCP server manager

  1. Add a unique name and choose stdio or Streamable HTTP.
  2. Configure command, arguments, working directory, and environment for stdio; configure an HTTP(S) URL and headers for HTTP.
  3. The Host can import local Claude Code and Codex configurations in one pass. Duplicates are skipped and unsafe conversions report a reason.
  4. Review the format audit at the top of the card and save. The Host starts, updates, or unloads each connection independently.

Environment and header values are masked when existing servers reach the browser. Unchanged secrets are not reconstructed from, or overwritten by, redacted snapshots.

Drafts retain the configuration revision at the start of editing. If another page or external editor changes the configuration, saving an older draft is refused without deleting the other editor's new servers; discard the draft, review the latest configuration, and edit again. Interrupted saves leave the saving state and retain the draft. Failed writes re-read Host configuration, and older read responses cannot overwrite newer refresh results.

5. pi-ai model request types

model-input-types · Settings → Plugins → Plugin configuration → pi-ai model request types

pi-ai model request type settings

Add pi-ai model overrides on the DSH Models page or in settings.yaml, then choose Provider default, Text only, or Text and images for each model. Changes save immediately.

The card appears only when the official llm-pi-ai settings namespace is available. It stores a capability declaration and does not probe the endpoint; verify that the provider truly accepts images before declaring Text and images.

6. Edit last message

edit-last-message · Latest editable user-message bubble in the current session

Edit and resend the latest user message

  1. Wait for the current session to finish, or stop it first.
  2. Select Edit last message and change the text inline.
  3. Select Resend or press Ctrl/⌘ + Enter; press Esc or Cancel to leave edit mode.

Resend stays inside the current session: the plugin replaces model context starting at the edited user message, then generates through the same AgentLoop. The DSH Session log remains an append-only audit record, and side effects from tools that already ran are not rolled back. Uploaded generic files render with the DSH file-card presentation, while messages containing any attachment or other non-text block do not expose the editor, preventing silent data loss.

6.2.2 preserves DSH rc.2 sent-reference previews: selecting a file or a Skill actually loaded in that step opens the current session's right sidebar without changing or resending the text. Edited bubbles also preview files; their Skill labels use only invocation records from the edited step, never records from the replaced turn. Resends keep plugin attribution, so slash text alone does not trigger a new user Skill invocation.

Since release 6.1.0, the plugin writes V3 replacement operations and uses standard plugin attribution containing the original message ID, without embedding event sequence numbers. DSH migration can renumber events without losing the edit's identity. Older nested markers and the 5.x edit-last-message source kind are not accepted by the V2-to-V3 migrator. Before opening such sessions in the new DSH, stop every DSH Host and run the offline repair on each affected log:

node .\scripts\repair-edit-last-message-session.mjs "C:\path\to\session.jsonl.zstd"
node .\scripts\repair-edit-last-message-session.mjs --write "C:\path\to\session.jsonl.zstd"

The first command is read-only. The second converts both historical marker formats to standard plugin attribution and creates a timestamped backup beside the original artifact. A truncated, corrupt, mismatched, or concurrently changed log is refused instead of being silently rewritten.

7. Product subagents

sub-agent · Settings → Subagents

Claude Code and Codex subagent toggles

Enabling Claude Code or Codex applies immediately to every Agent preset carrying this controller, including running sessions. Disabling a toggle removes the matching tool in real time. The corresponding product and its official DSH provider must still be installed locally.

Both toggles default to off. Writes use path-addressed operations and settings revisions, so a redacted or stale snapshot cannot overwrite changes from another page or an external editor.

8. Official Team monitor

agent-team-monitor · Current conversation composer → Team icon

Official Agent Teams read-only monitor

  • The session-owned icon appears in the composer's model/context control group after workflow, Agent Teams or native child sessions are detected. Click to open; switching conversations immediately closes the panel and clears old data. No global overlay or header button is registered. Ordinary conversations with no delegation/team activity have no icon.
  • “Roles & child sessions” groups exact recorded member names / creation labels while keeping multiple sessions for the same role distinct. Missing labels appear under “Unlabelled role”; no role is inferred from prompts or titles. Filter All / Running / History and inspect each session's title, ID, mode, creation time and state. Discovery includes nested children within this conversation tree, never unrelated roots.
  • Click an available session row to enter DSH's native openSubagent details view, using the exact parent/child IDs and freshly checked native catalog mode. Running, historical and nested sessions share this path. Selection changes or plugin disposal fence late navigation; missing/corrupt records remain visibly unavailable rather than becoming fabricated sessions.
  • Standard workflow and experimental Agent Teams are separate mechanisms and are displayed separately. The monitor reads the current session's own tool-workflow/* durable records for run names, actually started members, phases and completion/failure/cancellation. It never infers future roles, task dependencies or mailbox data from a script. Members pair by runId + seq; inherited workflow history cannot become a new fork's team.
  • The Agent Teams view follows the selected Lead or roster-member session. It shows member status, task dependencies/owners/readiness, advisory write-scope overlaps, and queued mailbox counts. Select a task for details; select a member to open its official subagent transcript.
  • The Host reads the official ctx.agentTeams service. For cold history, the official Agent Teams runtime owns and registers the agentTeam projection, which the monitor replays through public ctx.sessionProjections.restore(). Logs come from read-only sessionQuery.observeSession() observations; no Agent is activated and no second team state is created.
  • Only the current conversation is polled (1.5 seconds open / 5 seconds collapsed); hidden pages and disconnected Hosts pause polling. New members and state changes refresh automatically without opening the panel. Click the icon, outside the panel, or press Escape to close. Failed/old replies cannot appear as live state after a session switch or reconnect.
  • The monitor does not enable Agent Teams or workflow, register model tools, create/wake/interrupt members, edit tasks, or schedule work. Standard workflow monitoring needs no experimental Team package. To inspect live or historical Agent Teams state, enable that runtime separately following its Team documentation, so it owns and registers the projection.
  • Supports the DSH 0.1.5-rc.2 source ABIs. This plugin neither bundles the experimental package nor fetches it from npm; Agent Teams history replay requires the official runtime and its projection to be mounted in the active profile. Runtime status and task completion are independent: inactive does not mean completed, and tasks depend on model-reported updates. Mail bodies and raw provider errors are never sent by the monitor. Views cap at 256 members / 1,000 tasks with explicit truncation and complete totals.
  • Workflow views cap at 100 runs / 256 total member rows with complete totals. Unfinished cold records are never presented as live work; a closed enclosing step/turn marks an unfinished run interrupted. The monitor reads public records, never reads/executes workflow scripts, and never presents ordinary subagents as an experimental Team.
  • Native discovery uses public subagents.listDescendants; read-only sessionQuery.observeSession() supplies own titles and turn outcomes. Exact Agent running/idle state takes precedence; residency alone is not execution. History means currently non-running, not necessarily successful. At most 256 child rows are inspected/displayed, prioritizing executing Agents; truncation shows displayed/total counts and filters count displayed rows only. Catalog failures do not hide existing Team/workflow data.

Install only this Profile feature with -Features agent-team-monitor; use -ListFeatures to inspect all choices. The normal required Windows Launcher behavior is unchanged. Light/dark/system themes and English/Chinese follow DSH settings.

Compatibility and migration

  • Version pairing: plugin 6.2.2 supports DSH 0.1.5-rc.2 at the source baseline listed above. The aggregate, all seven standalone bundles, and Windows Launcher use 6.2.2.
  • V3 editing: replacement operations use startSeq/endSeq; current attribution retains the root message ID across event renumbering. Run the offline repair described above before migrating historical edit logs. Attachment bubbles use the current public FileTypeIcon export instead of the removed DocumentFileIcon.
  • Historical monitoring: Cold monitor reads use the shared public sessionQuery.observeSession() API with projectionMode: 'none', release the observation after reading, and never activate an Agent or commit crash recovery. Custom profiles need a sessionQuery provider for historical monitoring; the standard Web profile already supplies one. Agent Teams v1/v2 history compatibility remains owned by the active official Team projection; rejected history is shown as incompatible, never rewritten by this plugin.
  • Installation preflight: the installer and Launcher plugin updater read dshEnhanced.compatibility from the root package.json before building, stopping services, or changing a profile. The exact allowed versions come from dshVersion plus optional additionalDshVersions; peer dependencies declare the same supported versions. An unsupported DSH version, missing or malformed declaration, or mixed plugin package versions stops installation. A matching version whose commit is absent from sourceCommit and additionalSourceCommits, local source changes, or no Git metadata produces an unverified-source warning.
  • Current interfaces: Client features use client-store, ui-session, ui-chat, and public Remotes, without the removed dsh-client-runtime, connection.api, or hostDescription. Host settings owners pass validated namespace literals and use SettingsProvider.installSection(). Session consumers use eventAt() / snapshotEvents() and keep SessionLogOffset inheritance metadata separate from SessionHeader; Team Monitor preserves that exact cut through query observations and projection replay. This project follows the public interfaces of the source commit above.
  • Provider provenance: the subagent-codex and subagent-claude-code Loader IDs are unchanged. Their official implementations are re-exported through this package's sub-agent/codex and sub-agent/claude-code entries (./codex and ./claude-code in the standalone bundle), so the new DeepSeek active-package inventory can resolve ownership without being disabled or changing DSH.
  • Standalone builds: feature distributions include their own source and build scripts. npm install --legacy-peer-deps, npm run prepare, and npm pack work without a sibling DSH checkout; the matching DSH runtime still supplies public peer services. Rebuilding Windows Launcher requires Windows and a .NET Framework 4.x compiler.
  • Architecture boundary: Web features extend public Services, events, slots, and settings. Windows Launcher is an independent companion and never joins the Cordis plugin tree.

Check the version pairing without building or installing (add -DshCheckout when the checkouts are not siblings):

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\migrate-to-enhanced-plugin.ps1 -CheckCompatibility

Use the matching plugin release for an older DSH version instead of bypassing peer dependency checks or forcing this release to install.

  • File reference retired: current DSH provides native @ file references. Type @ in the composer, or @" for paths containing spaces. The old referenced-file feature ID and # snapshot syntax are no longer provided.
  • Automatic cleanup: -Features referenced-file is rejected explicitly. A normal installer run removes the historical selective package or the feature carried by an older aggregate install.

Configuration

The default composition lives in cordis.patch.yml. A later profile patch replaces the target Loader row's entire config, so an override must restate every field that row still needs.

Desktop alert defaults

| Field | Default | Purpose | | --- | --- | --- | | completionSound | subtle | Completion sound: off, subtle, prominent, or uploaded custom | | confirmationSound | prominent | Attention sound: off, subtle, prominent, or uploaded custom | | blockedSound | prominent | Blocked sound: off, subtle, prominent, or uploaded custom | | soundGain | 0 | Shared 0–100% positive gain; 100 is approximately +6 dB | | petEnabled | false | Show the native global desktop pet | | petCharacter | classic | classic (Flat Whale), multiview (3D Whale), or whale-girl | | petIdleTopmost | true | Keep the idle pet topmost | | petSize | 112 | 80, 112, 144, or 176 device-independent pixels | | petPosition | bottom-right | top-left, top-right, bottom-left, or bottom-right |

Six *CustomSoundFile / *CustomSoundName fields are Host-owned selection references for the three events. The shared catalog is stored at desktop-notifications/sound-library.json inside the profile. Upload and choose sounds through Settings instead of editing these fields manually.

Plugin Community Host configuration

| Field | Default | Purpose | | --- | --- | --- | | profile | web | Target profile for install and uninstall | | topic | dsh-plugin | Topic required by validated channel entries | | channelUrl | HTTPS snapshot on market-index | Publication used by Sync latest index | | pageSize | 12 | Plugins per page | | operationTimeoutMs | 120000 | Install and uninstall timeout | | githubTokenEnv | GITHUB_TOKEN | Credentials reference name | | cliPath | empty | Optional absolute DSH executable path |

Bundled assets/plugins-cache.json is a read-only bootstrap snapshot and the incremental-validation seed for the first automated index run. The Host owns cached snapshots, ETags, background tasks, and installation records under DSH home. Plugin Community never parses shell commands out of READMEs and never enables dangerouslyAllowAllBuilds.

To expose product-subagent tools to selected Agent presets only, disable or remove the root subagent-product-toggle-tools row and mount the appropriate entry inside each target preset:

  • Aggregate package: dsh-enhanced-plugins/sub-agent/preset
  • Selective package: dsh-enhanced-sub-agent/preset

Do not mount both layouts in the same scope.

Development and verification

This repository uses the following read-only sibling checkout as its DSH API, type, and assembled Web UI baseline:

D:\work\workspace\github\deepseek-harness

Regular verification commands:

DSH's runtime and lib/types must come from the same source build. Passing typecheck against stale declarations does not verify compatibility with an updated checkout.

npm install
npm run typecheck
npm test
npm run build
npm run pack:dry-run
git diff --check

On Windows, npm run verify:compat additionally installs all seven features individually into an isolated DSH home, then checks all-features, reselection, cleanup, and aggregate profiles against the real Host and Client artifacts. It requires built DSH and plugin artifacts and leaves the normal profiles untouched. Reports stay under the Git-ignored .verify-dsh-home/. Interactive behavior and light/dark appearance still require the real Web page.

Set DSH_VERIFY_CHECKOUT to a prepared copy of the verified DSH source commit when running npm test or npm run verify:compat against an isolated build. The default remains the sibling checkout, and the installer still checks the declared version.

npm run verify:desktop-launcher verifies source command selection, build prerequisites, duplicate suppression, pnpm version failures and process-tree cleanup with the compiled Launcher. npm run verify:desktop-source executes the unchanged official start:desktop script through Launcher in a temporary source view, waits for the actual Electron page, and stops the owned process tree. It leaves the sibling checkout unchanged.

npm run verify:desktop-host loads the official Desktop Host with a fixed plugin snapshot in an isolated directory and verifies the actual Client index response. It does not build or modify the DSH checkout.

npm run verify:launcher exercises the compiled Launcher and PowerShell command engine in temporary directories, including clean/install/build ordering, failure stops, and real pnpm frozen-lockfile rejection. It requires Windows, Git, and pnpm on PATH; it does not clean or rebuild the real DSH checkout.

npm run verify:launcher-ui compiles real WinForms controls in an isolated directory and checks scrolling, filtering, bulk selection, page/mode changes, repeated layout, bounded UTF-8 log reads, and disposal of retired controls. It measures navigation with an approximately 64 MB log and checks all five pages at normal, compact, wide, and 150% layouts, saving screenshots under .verify-dsh-home/ui-performance/. Timings measure UI processing and offscreen drawing, not display frame rates; pass/fail checks avoid fixed timing thresholds that vary with machine load.

npm run test:launcher-toolchain covers version detection, NVM fallback, declaration conflicts, and isolated environments (build Launcher first). On Windows, node scripts/verify-launcher-sandbox.mjs <DSH-checkout> verifies real Web readiness, the selected manager, cached restart, and stop using a temporary DSH Home. It may download the required manager, references DSH source read-only, and saves screenshots and results in .verify-dsh-home/sandbox-artifacts.

npm run verify:pack packs each standalone distribution, installs only its build dependencies in an isolated directory without DSH peers, runs prepare, and checks its repacked entries. The Windows Companion part requires Windows as well.

Browser bundles use CSS Modules and consume only DSH --dsw-alias-* semantic theme tokens, so they follow light, dark, and system appearance automatically. See the DSH plugin development guide and architecture reference for public extension points.

npm run verify:edit-web installs the editor in an isolated profile and drives Chromium against the real Web composition with a local SSE model fixture. It checks repeated edits, request-history replacement, file and Skill reference previews, reload, and light/dark screenshots without a real model key. It uses Playwright from the built DSH checkout and requires its Chromium browser. typecheck rejects mismatched Session declarations or stale Chat declarations without rc.2 openSkill. Web and Desktop verification commands accept DSH_VERIFY_CHECKOUT for an isolated build.

License

MIT

Similar plugins

dsh-custom-plugin

by AlexPeng07

dsh-custom-plugin是一个为 DeepSeek Harness (DSH) Web GUI 打造的增强插件。提供:背景天气特效/玻璃拟态、时间线轨道、项目文件夹、提示词库、对话导出、Mermaid 图表渲染、引用回复、余额查询与每日 Token 用量面板等多种便利功能

UI & ExperienceManifest valid

6

436/wk

Apache-2.0

TypeScript

Sep 12, 2026

dsh plugin --profile web add @alexpeng/dsh-custom-plugin

by Luaphes

DSH的插件创意市场来啦!~~~欢迎使用&提供反馈!!DSH 插件创意市场 · DeepSeek Harness 插件发现与一键安装面板 全量嗅探官方 dsh-plugin topic(900+),过滤蹭标签噪音,保留人工精选标记; 支持总星数/最新发布/最近推送排序、即时搜索、语言过滤; 点安装先校验 dsh.bundle 声明,装不了的一律拒绝。零依赖零构建,装进 Web UI 的 Plugi

Manifest valid

3

59/wk

MIT

JavaScript

Sep 12, 2026

dsh plugin --profile web add dsh-plugins-market

by wannanbigpig

一个为 DeepSeek Harness 最新源码补齐工程能力的外置插件(Bundle),无需修改宿主源码。插件直接融合进宿主原生 Right Sidebar、文件资源标签和底部 Dock:复用宿主已有的文件树、标签页、拆分/悬浮布局,只补充可编辑高亮、Git Review/提交、Worktree 和交互式 PTY。所有项目操作以当前 Session 的 cwd 为边界

Manifest valid

0

MIT

JavaScript

Sep 12, 2026

dsh plugin --profile web add @wannanbigpig/dsh-sidebar

by magian1127

DeepSeek Harness (DSH) plugin: A comprehensive enhancement plugin with UI polish, layout tweaks, prompt injection, and more. 综合性增强插件,界面优化、布局调整与提示词注入等更多功能。

UI & ExperienceTerminal & ClientsManifest valid

29

1.2k/wk

MIT

TypeScript

Sep 13, 2026

dsh plugin --profile web add deepseek-harness-zh_pro

by LX2000WASD

在 Web UI 中一键管理 DeepSeek Harness (DSH) 插件:查看、实时启停、安装/卸载、更新检测、健康检查(依赖/冲突/兼容性分析)、环境管理、插件市场。bundle 与非 bundle 插件全覆盖

Terminal & ClientsManifest valid

69

MIT

TypeScript

Sep 12, 2026

dsh plugin --profile web add dsh-web-plugin-manager

by dshplugin

DeepSeek Harness 社区内置插件市场(dsh-plugin)— 搜索插件、下载并安装 4000+ 人工精选社区插件,每日更新、完全免费。内置在 Harness「设置 → 插件中心」,无需离开应用即可浏览、搜索、安装各类 AI 插件。

Tools & CapabilitiesManifest valid

111

MIT

TypeScript

Sep 14, 2026

dsh plugin --profile web add dsh-plugin