Preface

In DeepSeek Harness (DSH), a single session often handles only one matter serially: dispatching a subtask means waiting for it to finish, or switching windows to monitor another session. If you wish to “continue coding in the current session while another session reads documentation and replies in the background,” and want the creator to gatekeep privilege escalations in sub-sessions, orchestration capabilities beyond the host are required.

dsh-cross-session-approval is a community-maintained workflow bundle (maintainer zsjs110110-cpu, current README version 0.3.10), targeting DSH 0.2.x (peer dependency >=0.2.0-rc.2 <0.3.0). It provides ten cross-session tools, task dispatch registration, cs_ short alias addressing, sub-session permission clamping, and an approval bridge that transfers sub-session sandbox privilege escalation approvals to the creator session within the same host. The plugin is published as the npm package dsh-cross-session-approval under the MIT license; the community directory page is at SkillHub, and the source code and documentation are at GitHub.

What is this

In short: Once loaded into a configured DSH profile, the agent can create top-level persistent sessions, deliver tasks and messages, read status and message tails, broadcast in bulk, rename, and archive via tools. When a sub-session requires privilege escalation, the spawning creator can call cross_session_approve to make the decision.

It is not a standalone MCP service but a bundle loaded with the host process; tool calls occur within DSH sessions and are not PowerShell commands executable directly in the shell.

Dispatch metadata is written to .cross-session/registry.json under the current workspace (directory name adjustable via stateDir in cordis.patch.yml), using a temp file plus atomic rename for writes. The registry contains task bodies and reply summaries, which may be sensitive and should be kept as local workspace data only. Read failures block operations dependent on the registry; write failures generate warnings, but completed deliveries are not rolled back.

Core Features

Ten Cross-Session Tools

Tool Summary
cross_session_spawn Create a top-level persistent session and deliver a task without waiting for completion
cross_session_send Send a message to a specified session, with control over wake-up and interruption of the current step
cross_session_reply Reply to a specified session and wake it up (task sessions should use this to send results back to the spawner)
cross_session_status View the dispatch registry overview or filter by session_id
cross_session_read Read the tail of session messages (default 10, max 50), does not wake the target
cross_session_list List top-level sessions in the current workspace, supporting archive, tag, and workspace filters
cross_session_broadcast Deliver messages to up to 20 targets individually and report success/failure
cross_session_rename Modify session title (1–60 characters)
cross_session_archive Archive a session
cross_session_approve Handle cross-session approvals, decision is allow or reject

Single task or message bodies are truncated at 32 KiB UTF-8; the registry retains up to 200 records, evicting the least recently active items when exceeded. The registry is not a complete session history.

cs_ Short Aliases

Some display pipelines replace long session IDs with placeholders, making it impossible to address them by copying placeholders from the interface. The plugin derives an alias using FNV-1a with cs_ plus 10 base62 digits (total length 13, e.g., cs_xwx698M4Wa). cross_session_list and cross_session_status return the alias; tool parameter names remain session_id, to, or reply_to. Aliases are for addressing, not authorization credentials.

Sub-session Permission Clamping (A / F)

Default spawnPermission: cap: When creating via cross_session_spawn, the sandbox level, approval policy, and workspace cannot be wider than the caller (if permission is omitted, the narrower/stricter combination of the deployment defaults is taken). The optional agent_preset specifies a host custom mode ID, defaulting to inheriting the caller; cwd defaults to the caller’s workspace root, and callers without the highest level cannot point outside the workspace.

Default forkPermission: cap: Performs similar narrowing for forked creations with parentSession; strict rejects directly if the source session is not loaded. Enabling the approval bridge requires spawnPermission to be cap, not off.

Cross-Session Approval Bridge

Task sessions created by cross_session_spawn can transfer approval to the creator session (owner) when requesting sandbox privilege escalation via pwsh or run_code. The owner must remain active in the same host; this version does not reload an unloaded owner for approval. Ownership is written to memory only during spawn and is not persisted after restart; old tasks fall back to local UI approval.

Upon receiving a notification, the owner calls cross_session_approve using a key formatted like apv_XXXXXXXXXXXX (different from the approval/asked ID used for auditing). Only the creator of the requesting session can handle it; dangerous rule hits or inability to determine force a rejection, and the owner has no authority to override.

Installation and Enablement

Requires Node.js 18+ and a configured DSH 0.2.x profile with available models. The following uses profile name dev as an example; please replace with your actual name.

Method 1 (npm, recommended by README): Install in the profile directory; npm will resolve @deepseek-ai/* peer dependencies.

$profileDir = Join-Path $HOME ".dsh/profiles/dev"
cd $profileDir
npm install dsh-cross-session-approval@0.3.10

Method 2 (GitHub Release tarball): Suitable for dsh plugin installation and the awesome-dsh-plugin market directory.

dsh plugin --profile dev add "https://github.com/zsjs110110-cpu/dsh-cross-session-approval/releases/latest/download/dsh-cross-session-approval.tgz"

Method 3 (Source Code): Requires repository read permission; place the repository in the profile’s node_modules/dsh-cross-session-approval and append the package name to dsh.profile.bundles in that profile’s package.json:

{
  "dsh": {
    "profile": {
      "bundles": ["dsh-cross-session-approval"]
    }
  }
}

Verify and start:

dsh --profile dev --dump-config
dsh --profile dev --no-open --port 0

The config output should include cross-session-approval without skipping for that bundle; there should be no failed to import for this plugin at startup. After entering the session, confirm the tool list contains the ten items above. Successful configuration does not imply the approval bridge is enabled as expected; verify against startup warnings and items like approvalBridge.enabled in cordis.patch.yml.

Relevant configuration snippet for the approval bridge (see the repository cordis.patch.yml for full items):

config:
  stateDir: .cross-session
  spawnPermission: cap
  forkPermission: cap
  approvalBridge:
    enabled: true
    timeoutMs: 300000

Typical Usage

The following are tool call examples within a DSH session; cs_XXXXXXXXXX must be replaced with the alias actually returned by spawn.

cross_session_spawn({ name: "检查文档", task: "阅读 README,列出安装步骤中的歧义;完成后回复结果。" })
cross_session_status({ session_id: "cs_XXXXXXXXXX" })
cross_session_read({ session_id: "cs_XXXXXXXXXX", tail: 10 })
cross_session_send({ session_id: "cs_XXXXXXXXXX", message: "请再核对配置示例。", interrupt: false })

spawn will attach a reply target to the task message; after the task session completes, it should call:

cross_session_reply({ to: "<回信目标别名>", text: "结果摘要或失败原因" })

Delivery success and task completion are two different states; judgment requires combining replies with read. It is recommended not to pass permission and cwd on first use, adhering to default clamping and the current workspace.

Approval examples:

cross_session_approve({ key: "apv_XXXXXXXXXXXX", decision: "allow", note: "已核对任务与提权范围" })
cross_session_approve({ key: "apv_XXXXXXXXXXXX", decision: "reject" })

Scenarios and Cautions

Suitable for developers needing multi-session orchestration within DSH 0.2.x: background task dispatch, continued interaction in the main session, sub-session results flowing back via reply, and centralized handling of sub-session privilege escalation approvals by the creator.

Before installation, please review the GitHub repository source code and MIT license yourself. The plugin runs with the current DSH process and profile permissions; persisted registry content may contain task details. Cross-workspace addressing, explicit permissions, and approval bridge limitations are subject to the README. Community directories like SkillHub are independent sites and have no official affiliation with DeepSeek / High-Flyer.

Conclusion

dsh-cross-session-approval consolidates cross-session spawn, messaging, status queries, and the approval bridge into a single 0.2.x bundle, using cs_ aliases to mitigate addressing issues caused by long ID masking. For installation or version details, you can start from the SkillHub plugin page or directly open the GitHub repository README.