DeepSeek Harness 插件

dsh-webhook-bridge

Generic webhook receiver for DeepSeek Harness — POST to a local endpoint to wake a dsh agent.(英文原文)

跳到安装方式

来源信息

GitHub 仓库
ben7am1n/dsh-webhook-bridge
最近更新
2026年8月13日
分类
自动化与任务
GitHub stars
1
载体类型
plugin
目录证据
上游声明已找到 dsh.bundle
证据路径
package.json#dsh.bundle
核对版本
0.1.0-rc.8
上游核对日期
2026-08-20

该证据由上游目录提供。本站没有安装、运行或安全审核这个插件。

安装

默认先复制一段 Prompt,让 Agent 读 GitHub 仓库和源码;需要自己装时再切到命令。

复制这段 Prompt,发给 DSH、Codex 或其他 Agent,让它先读 GitHub 仓库和源码。

请先不要安装或执行任何命令。阅读这个插件的 GitHub 仓库、README 和关键源码,然后用清楚、直接的方式回答以下问题,帮助我判断它是否适合我的需求:

1. 这个插件是什么,解决什么问题;
2. 适合哪些用户和典型使用场景;
3. 安装后如何使用,并给出一个最小使用示例;
4. 有哪些已知限制,以及隐私、安全、兼容性或维护风险;
5. 给出“推荐 / 有条件推荐 / 不推荐”的明确建议和理由。

请区分仓库明确说明、根据源码推断和未知信息。证据不足时请明确说明,不要猜测或照抄 README。

GitHub:https://github.com/ben7am1n/dsh-webhook-bridge
插件名:dsh-webhook-bridge
作者:ben7am1n

检查来源文件

安装前先看这个插件目录里的 README 和其他文件。

文件资源管理器2 个文件
README.md来源说明 · 只读预览

dsh-webhook-bridge

Generic webhook receiver for DeepSeek Harness — POST to a local endpoint and wake a dsh agent. CI, monitoring, or any HTTP-capable service can feed messages to a harness agent over plain HTTP. Zero runtime dependencies beyond the official schema library (node:http only).

Overview

dsh-webhook-bridge exposes a small local HTTP server. Each request to POST /hook/:channel delivers a message to that channel's agent session; committed assistant text can be streamed back to an optional callback URL. It is a protocol driver in the dsh extension model — the same role as the official ACP/JSON-RPC bridges, but for any system that can send HTTP.

Who is it for?

  • CI pipelines that want an agent to triage a failed build.
  • Monitoring/alerting systems that want an agent to investigate an incident.
  • IM bots and webhooks (GitHub, GitLab, generic services) that need to hand a payload to a harness agent.
  • Developers who want a readable reference for writing an HTTP-based protocol-driver plugin.

What it does

  • Serves POST /hook/:channel (Bearer-secret auth) and GET /health.
  • Maps one channel to one agent session; the first message creates the agent, later messages followup() into the same session.
  • Extracts message text with a documented precedence: JSON message > text > content; non-JSON bodies are used verbatim.
  • Optional reply_url in the body: committed assistant text is POSTed back as {"text": "..."}.
  • Rejects unauthorized, malformed, and oversized requests (401/400/413).

What it does not do (yet)

  • No TLS (terminate TLS at a reverse proxy; the endpoint binds loopback by default).
  • No webhook signature verification beyond the shared Bearer secret.
  • No cross-restart persistence of channel→session mapping (in-memory; see Compatibility).

Compatibility

  • Requires Node.js ≥ 22.19 (global fetch, node:http).
  • Built and verified against @deepseek-ai/dsh@0.1.0-rc.6 / @deepseek-ai/cordis@^4.0.1.
  • Last verified: 2026-08-14.
  • Channel→session mapping lives in memory: restarting dsh loses open sessions (a new request recreates them).
  • dsh is in developer preview; re-verify after harness updates.

Install / Uninstall

Install into a dsh profile (local checkout):

cd /path/to/deepseek-harness
pnpm dsh plugin --profile web add /path/to/dsh-webhook-bridge

From GitHub (source install — pnpm runs the prepare script, so allow it once):

pnpm dsh plugin --profile web add github:<you>/dsh-webhook-bridge
# pnpm ≥10 blocks the build script on first install; copy the printed package key
# into <profile>/pnpm-workspace.yaml under allowBuilds, then re-run.

Uninstall:

pnpm dsh plugin --profile web remove dsh-webhook-bridge

Quick start

1. Pick a shared secret (e.g. openssl rand -hex 24) and set it in the profile's cordis.patch.yml (or export DSH_WEBHOOK_SECRET):

``yaml - id: dsh-webhook-bridge name: dsh-webhook-bridge config: secret: 'your-shared-secret' ``

2. Start dsh, then deliver a message:

``sh curl -X POST http://127.0.0.1:8788/hook/ci \ -H "Authorization: Bearer your-shared-secret" \ -H "Content-Type: application/json" \ -d '{"message": "CI failed on main: run the release pipeline diagnosis"}' ``

3. To receive the agent's answer back:

``sh curl -X POST http://127.0.0.1:8788/hook/incident \ -H "Authorization: Bearer your-shared-secret" \ -d '{"message": "Investigate the 5xx spike", "reply_url": "https://your-service.example/hook/agent-reply"}' ``

Configuration

All keys live under the dsh-webhook-bridge row's config:

KeyTypeDefaultMeaning
hoststring127.0.0.1Bind host. Loopback only by default; bind 0.0.0.0 only behind a firewall/proxy.
portnumber8788Bind port.
secretstringenv DSH_WEBHOOK_SECRETRequired in Authorization: Bearer <secret>. Empty = every request rejected.
providerstringProvider route for created agents (falls back to profile default).
modelstringModel for created agents (falls back to profile default).
cwdstringprocess.cwd()Working directory for created agent sessions.
maxBodyBytesnumber1048576Request body limit; larger bodies get 413.

Permissions & data

  • Network exposure: the server binds 127.0.0.1 by default. If you bind externally, put it behind a reverse proxy with TLS; the shared secret is the only gate.
  • Auth: constant-time comparison (timingSafeEqual); unauthenticated requests get 401 and never create an agent session.
  • Reply callbacks: only to an explicit reply_url supplied in the request body, restricted to http:/https:.
  • Filesystem: the plugin writes nothing; agent sessions inherit the harness workspace policy.
  • Secrets: never commit the secret to the repository; use the env-var form in the shipped patch.

Troubleshooting

SymptomCauseFix
401 on every requestWrong/missing Authorization header or empty secretCheck config.secret and the header spelling (Bearer prefix required)
413 payload_too_largeBody over maxBodyBytesRaise maxBodyBytes or send smaller payloads
400 empty_messageNo message/text/content field and empty raw bodyInclude one of the recognized fields
404 not_foundWrong path or methodUse POST /hook/<channel>; /health is GET only
Replies not arrivingNo reply_url supplied for the channelInclude reply_url; the plugin only calls back when one is set
Agent error surfaces in logsModel/provider failure in the harnessFix the agent composition; the plugin forwards the request as 500

Development

pnpm install
pnpm run typecheck     # tsc --noEmit
pnpm run build         # tsc → lib/
pnpm run test          # vitest: HTTP behavior 200/401/400/413 + extraction helpers

Structure:

  • src/index.ts — plugin entry (name/inject/Config/apply), session mapping, and createBridge (pure HTTP transport, injectable message handler).
  • tests/ — integration tests start a real server on an ephemeral port and assert the HTTP contract without booting a full harness.

Design notes:

  • createBridge(config, deps) separates transport from agent logic: the HTTP layer is fully unit-testable, and apply supplies the handleMessage callback that creates sessions and forwards messages.
  • Zero runtime dependencies is a goal — node:http and node:crypto cover everything needed here.

License & security

MIT. Report security issues privately via the repository's security advisory. The bridge executes no agent code itself; all agent behavior is governed by the harness's own permission and sandbox policy.