connect

dsh-connect

English | 中文

The all-in-one plugin for connecting DeepSeek Harness (DSH) agents to chat platforms (Feishu / Lark, Telegram, DingTalk, and the Web mirror; more to come): session binding, agent driving, streaming reply bridging, interactive menu cards, local commands, and the web-settings stack.

One install, one config block: the core connect service, every channel adapter (feishu / telegram / dingtalk / web), and the web-settings stack all live in this single package. Enable the channels you use via the channels selector. The former split packages (dsh-connect-feishu, dsh-connect-telegram, dsh-connect-dingtalk, dsh-connect-web) and the dsh-connect-all bundle no longer exist.

What it looks like

The point of the plugin is the conversation, so that is what is shown first.

A question, answered from the chat. When the agent needs a decision it posts a card with the options as buttons. Tapping one — or replying with its number or text — answers the same question, and every earlier question stays answered above it:

A long task reporting progress. The same conversation, further along: the reminder has advanced from 5 minutes to 15, and a second question follows the first answer. This is the behaviour that matters most on a long run — the card keeps reporting instead of freezing on its first message:

Configuring it without typing config. /settings opens a button menu — model, reasoning effort, notification level, progress interval, language, and a config overview. Nothing here needs a YAML edit, and the same controls exist per chat, so one conversation can be tuned without changing the profile:

These are Chinese-language screenshots taken in Feishu, because that is where the project

is actually used. The UI strings exist in English too (language: en).

The settings pane is configured separately — the full walkthrough, with its screenshots, is further down.

Why this exists

DSH's own Web GUI is excellent, and nothing here replaces it. What it cannot do is reach you. An agent that runs for twenty minutes on a long refactor has no way to tap you on the shoulder while you are in a meeting, on a phone, or away from the machine — and you have no way to answer it when it stops to ask a question.

dsh-connect closes that loop. The agent keeps working in a real DSH session on the real host; you get a native chat client as the control surface:

• Start work from anywhere, on any device. Feishu, Telegram and DingTalk all have

mature mobile and desktop clients. You are not tunneling into a web UI or keeping a tab open; you message the bot the way you message a colleague.

• Watch it work, or don't. The chat card streams the reasoning and tool calls live, so

a long turn is legible instead of a spinner. When you would rather not read it, drop the chat to 输出重要节点 or 只输出结果 and get the answer once, whole, at the end.

• Answer the agent where the question appears. When the agent needs a decision

(ask_user_question) or permission for a risky action, the question arrives as buttons in the same conversation. Answering from chat is a first-class path, not a fallback — and the Web GUI stays fully functional, so whoever answers first wins.

• Keep the audit trail in the conversation. Every task, result and approval is a

message you can scroll, search and forward, in a tool your team already has.

Two properties make this usable rather than a demo:

1. It is the real agent, not a chat wrapper. Sessions live in DSH and are bound 1:1 to

chats; the same session is simultaneously visible in the Web GUI as a mirror. Switch between the two freely — the transcript, working directory and context are the same object, not a copy.

1. The quiet levels are genuinely quiet. Only full sends repeating status lines.

The two quieter levels send discrete events only — this is asserted by tests, because "notifications you cannot turn off" is the failure mode that makes people uninstall a bot.

Who it is for. Anyone running DSH who wants to operate agents from a chat platform — solo operators running a bot for their own workspaces, and small teams sharing one bot in group chats behind an allowlist.

Overview

dsh-connect binds a chat conversation to a DSH agent session and drives it end to end:

• Session binding & routing — one chat ⇄ one agent session, persisted in a bindings.json route store; sessions can be created, resumed, switched, cleared and mirrored to the DSH Web GUI.
• Streaming replies — the model's live deltas are bridged into the channel's native streaming (Feishu typewriter cards): the thinking hint opens the reasoning phase, reasoning streams live with readable paragraph breaks, tool calls appear as 🔧 progress lines, and a liveness heartbeat keeps the card moving even through long silent stretches (long first-token waits, heavy tool runs) so it never sits frozen on "Thinking…". The runner keeps two subscriptions, because 0.1.5-rc.2 split what used to be one: the durable session/event stream carries turns, tools and settlement, while the transient agent/assistant-stream frames carry the deltas — the assistant/chunk session event that used to carry both is gone.
• Notification levels — per-chat control over how much of the process is streamed: 尽量输出过程 (full process) / 输出重要节点 (key milestones) / 只输出结果 (result only). Only `full` sends repeating status lines; the two quieter levels send discrete events instead (see the table below). Switch any time via the settings menu or /notify; the choice is persisted per chat and applies immediately.

Level · Thinking hint · Reasoning text · Tool-call lines · Liveness heartbeat · 5-min progress reminder · Final answer 尽量输出过程 full · once · streamed live · streamed live · sent on a timer · sent, with the step count · streamed live 输出重要节点 important · once · not sent · not sent · not sent · sent, with the step count · sent once, whole, at task end 只输出结果 result (default) · not sent · not sent · not sent · not sent · sent, with the step count · sent once, whole, at task end

The liveness heartbeat is repeating chatter ("still here"), so only full gets it. The 5-minute progress reminder is a status report you configured with progressTimeoutMs, so it runs at every level — set it to 0 to turn it off everywhere. Both edit the streaming card in place rather than posting a new bubble.

• Automatic context compaction — optional, off by default. With autoCompact on, a session is compacted automatically at the end of a turn once context usage reaches autoCompactThresholdPct (default 80%), so a long unattended run does not stop on a full window. The task-end card states which rule is active. Toggle it per chat with /autocompact on|off|.
• Task-end stats — after every task a compact card reports the model used, input/output tokens, elapsed time and context-window usage, and suggests /compact when the context is getting full.
• Interactive menus — button cards for status, tasks, history, goals, schedule, model/effort switching, workspace picking, language, and more (see the in-chat / commands).
• Media handling — downloads user images/attachments, passes them to a vision-capable model (or a configured vision model) so text-only main models never stall on images.
• Locking & queuing — a per-chat write lock is held by the chat side, and messages that arrive while another writer holds it are queued and drained on release. The lock is one-sided, and that is worth knowing before you rely on it: it is enforced only on the chat side. The Web GUI reads the mirrored session straight out of DSH's session store and never sends inbound messages through this plugin, so it is write-always — the Web side cannot be made to respect the lock from this repository, and a Web user editing the same session is not blocked by it. Running the same session from two writers at once is therefore possible, not prevented.
• Web mirror (auto) — every Feishu conversation is automatically available in the DSH Web GUI as a mirrored session (disable with autoMirror: false).

Who is it for? Anyone running DSH who wants to operate agents from a chat platform — solo operators running a bot for their own workspaces, and small teams sharing a bot in group chats with an allowlist.

Compatibility

Aspect · Value DSH version · ^0.2.0-rc.2 (peer @deepseek-ai/dsh-agent, dsh-llm, dsh-session) Cordis · ^4.0.1 Node.js · ≥ 20 (ESM, NodeNext) Last verified · 2026-10-10 against DSH 0.2.0-rc.2 on Windows — host load, Feishu WebSocket transport, the web-settings pane, and an end-to-end round trip against a live dsh host (the E2E suite's live leg)

Keep the peer range in step with the host. Upstream ships no changelog or migration guide, so a stale range is the only thing standing between this plugin and silent breakage: DSH 0.1.5-rc.2 deleted the Session.events accessor and the assistant/chunk event type outright, and every dsh-* package is versioned on the same line. When you upgrade DSH, bump peerDependencies (and devDependencies) for dsh-agent, dsh-llm and dsh-session together, re-run tsc, and re-run the test suite — a range that no longer overlaps the host version is the signal that the bridge needs another migration.

DSH refuses to load a plugin whose range does not cover it, so a stale range is at least loud: installing 0.9.0 on 0.2.0-rc.2 is rejected with *"may cause crashes or data loss"* before anything runs. 0.9.3 is the version that covers 0.2.0-rc.2; see Upgrading from 0.9.0.

The plugin runs on the DSH Host plane (process-level singleton services), not inside an agent preset.

Install / Uninstall

Plugin management is a thin wrapper over pnpm in the DSH profile:

# Install the single all-in-one plugin (core + all channel adapters + web-settings)
dsh plugin --profile web add dsh-connect

Upgrade

dsh plugin --profile web update dsh-connect

Disable — override the bundle-registered entry with disabled: true in the profile patch (see ~/.dsh/profiles//cordis.patch.yml):

- id: connect
  name: dsh-connect
  disabled: true

Complete removal — uninstall the package and delete the data it created:

dsh plugin --profile web remove dsh-connect
# then remove the plugin data (see "Permissions & data" below):
rm -rf .dsh-connect            # binding route store (stateDir)
rm -f ~/.dsh/.dsh-connect/feishu-credentials.json

Installing in the Desktop app

The Desktop app carries its own reserved profile (desktop) and installs into it from its own UI, not from a terminal: `dsh plugin --profile desktop …` is refused with *profile "desktop" is managed exclusively by the Electron application*, because only the app's own carrier is allowed to manage that profile. In the app, the install surface is a sidebar panel named Plugins — the first entry in the sidebar's panel list — whose header button Add plugin takes a package name. The app then tells you when it applies: *changes take effect on next start*.

Settings is not where that lives. Settings has two read-only pages instead — Bundled plugins (the built-in list and their status) and Plugin list (session plugins / global plugins) — which is exactly where the Plugins page's own help line points: *the built-in plugin list and their status are under Settings → Bundled plugins*.

dsh-connect's own pane (Settings → dsh-connect) appears only once the plugin is actually installed and loaded, so a refused install leaves nothing to find there yet.

When the install resolves to an older version

Two pnpm 12 behaviours bite a fresh install, and both look like a lie: the Desktop plugin list offers the newest version, yet what lands on disk is the one before it — or the install ends in ERR_PNPM_IGNORED_BUILDS while still leaving the dependency in package.json.

1. pnpm's built-in 24-hour release cooldown. minimumReleaseAge defaults to

1440 minutes and is non-strict: a bare add dsh-connect resolves to the newest release *older than 24 hours*. The version query the Desktop shows you is a read, not an install, so it is not subject to the policy — for one day after every publish the two legitimately disagree.

1. An undecided build script. protobufjs, reached through

@larksuiteoapi/node-sdk, has a build script pnpm 12 will not run until you decide about it. It reports that *after* writing the dependency, which is why the failure looks like a half-finished install.

Append this to the profile's pnpm-workspace.yaml ($DSH_HOME/profiles/web/pnpm-workspace.yaml; on Windows the Desktop app's profile is %USERPROFILE%.dsh\profiles\desktop\pnpm-workspace.yaml), then install again:

minimumReleaseAgeExclude:
  - dsh-connect
allowBuilds:
  protobufjs: false

minimumReleaseAgeExclude exempts only this package; prefer it to minimumReleaseAge: 0, which turns the 24-hour supply-chain protection off for everything in the profile. allowBuilds is the spelling pnpm 12 accepts — onlyBuiltDependencies and ignoredBuiltDependencies no longer work and still fail with the same error.

The exemption cannot ship inside dsh-connect: a package cannot grant its own transitive build allowance from its own manifest, so the consuming profile is the only place it can live.

The two remedies are not interchangeable. Naming the version explicitly — dsh plugin --profile web add dsh-connect@ — does defeat the cooldown on its own, but it does nothing for the build script: that install still ends in ERR_PNPM_IGNORED_BUILDS, because allowBuilds is the only thing that decides protobufjs. If you would rather not edit the profile at all, the pin gets you the right *version*; it does not get you a clean exit.

Two more things worth knowing:

• Uninstall before reinstalling. DSH rejects a second add of an installed

plugin with already-installed, so remove it first.

• Restart `dsh` (or the Desktop app) afterwards: host plugins load at

process start.

Quick start

1. Install the plugins (see above).
2. Add the minimal config to ~/.dsh/profiles//cordis.patch.yml — the shape is also in examples/minimal.config.json, and the fully commented version is examples/profile-cordis.patch.yml in the repository (that path is outside the published tarball, hence the absolute link). The plugin registers itself via its bundle manifest, so only override its config — do not insert it again (a duplicate id crashes dsh at boot):

- id: connect
     name: dsh-connect
     # workDir: D:\your\workdir     # agent working directory (default: process cwd)
     config:
       channels: [feishu]            # which channels to activate; omit = all built-in
       # channelDefaults: { language: zh }   # keys applied to every channel that doesn't set its own
       feishu:
         appId: cli_xxxx
         appSecret: cli_secret_xxxx
         transport: websocket
         requireMention: true
         dmMode: open

1. Start the host — dsh web (or dsh run). With no credentials configured, the feishu channel enters one-click onboarding: scan the QR / open the link from the log to authorize the bot.
2. Send a message to the bot in Feishu. The bot replies with a streaming card; /help lists all commands; the conversation also appears in the DSH Web GUI automatically (auto-mirror).

A fully reproducible example is the examples/ folder plus the repository's Feishu setup manual (Feishu app creation, event subscriptions, publishing).

Questions and approvals in a conversation

When the agent needs a decision from you it stops and asks, and the asking happens in the chat — no switching to the Web GUI:

• A question with options renders as a card with one button per option. One tap answers it and the card immediately moves on to the next question. Once every question is answered the card is replaced by a summary of each question and the answer given, and the buttons disappear — leaving them live made the card look like it was still waiting, and a tap on one did nothing at all, because a tap on a retired card is deliberately absorbed rather than reported as expired.
• A question without options has no buttons to offer: the bot sends the question as a prompt and you reply in the chat. That message is the answer.
• A tool approval (an action that needs your go-ahead) is a card too, with Allow once / Reject buttons. This one accepts only a tap — a plain chat message sent while an approval is waiting is not recorded as its result.

One chat holds one pending card at a time. A second request is handed back to the host's own path (the Web GUI) rather than fighting the first card for the same message — and so is a card that could not be delivered, or a request cancelled before you answered; in each case the chat is released, because a leaked pending entry would silently swallow your next message.

"This action is no longer active" means the card has expired — it auto-closes after 60 s idle, so ask again. A double tap, or a tap landing right after the previous question was answered, falls inside the card's redraw window and is ignored silently rather than misreported as expired.