envoy-dsh

dsh plugin --profile web add envoy-dsh

Envoy for DeepSeek Harness

This package is a DeepSeek Harness bundle for [Envoy](../../../README.md). It

does three things in one install:

1. mounts Envoy's stdio MCP bridge with @deepseek-ai/dsh-mcp-client;

2. registers an adapted Envoy Agent Skill on the public ctx.skills service;

3. listens to the agent/pre-step event and, on the first step of a turn whose

user message contains a public link, prepends one short routing message.

The adaptation keeps Envoy's reading, discovery, expansion, visual handoff, and

capability behavior. It changes only the integration surface: the skill uses

the mcp__envoy__* tool names that DeepSeek Harness assigns to the mounted

server.

[中文快速安装](../README.md) · [Envoy 安装指南](../../skills/envoy/INSTALL.md)

One link in, AI-ready material out

Whatever you are looking at, hand it over and get the thing you wanted out:

Markdown, a wiki page, a knowledge-base entry. Douyin, Bilibili, Xiaohongshu,

Zhihu, WeChat posts, articles, PDFs and podcasts all take the same path. A read

returns a source-linked transcript with timestamps, frames, and a material_id

you can quote, so the agent writes from what was actually said, not from the title. For a whole feed,

envoy collect checkpoints every item, so an interrupted run resumes instead

of restarting.

Measured on 123 live links across those platforms: **80% usable as source

material — that is 93% of the links that answered at all — with 0 failures**

and every gap named.

Same 60 turns per arm, with and without the bundle: **ends normally without saying

it could not read 22% → 92%, times out 68% → 0, answer hits at least one

reference-fact keyword 23% → 82%**.

That A/B is exploratory (different caps, no human correctness review); the per-read

behaviour is what the tests assert.

The harness is in docs/experiments/link-compatibility.md; rerun it with

scripts/acceptance/link_coverage.py.

The same Envoy skill ships for Codex and Claude Code; this package is the

DeepSeek Harness build, and the deliverables are the same Markdown, wiki, or

knowledge-base material on all three hosts.

What changes when it is installed

Same model, same links. The difference is what a read puts in front of the

agent.

Ask · Harness on its own · With this bundle

Long article, WeChat post, Zhihu column · Truncated text, or only the digest · Body text with headings and source locators

PDF · First pages, or a screenshot of the page · Per-page text with page numbers and locators

Video (Douyin, Bilibili) · Title, cover, description, danmaku · Bound player file; captions or ASR with a coverage figure; frames when the host declares it can show them

Audio · Nothing usable · Timestamped transcript; low confidence and no-speech are stated, not hidden

Login wall · 403, empty body, or a captcha page · challenge_required plus the human step: import cookies for one site scope, or sign in once

Unreadable page · A plausible guess · partial with the part that was read, and the gap named

The turn-level A/B we ran is exploratory, not a claim: the two arms had

different time limits (900 s and 2400 s) and one arm was graded terminal-only.

Article-level citation counts came out level within noise over 60 turns per arm.

What this bundle guarantees is the per-read behaviour above, and the tests

assert it.

What stays the same without the bundle

Reading a link without Envoy still works. What the bundle adds is not a new

capability the model lacks, but a bounded one: declared visual input, a

retained material you can search instead of re-fetching, an explicit gap when

a source cannot be read, and a human step instead of an executable command

when the page needs one.

Requirements

• DeepSeek Harness with the Plugin Manager (engines.dsh is >=0.1.5).
• macOS, Linux, or Windows. The launcher is plain Node (node -e <script>),

written once in launch.cjs, so every platform mounts the same bridge. On

Windows the private runtime lives under %LOCALAPPDATA%\envoy-dsh\runtime

and its executables are Scripts\envoy.exe / Scripts\python.exe.

Nothing else. No separate CLI install, no envoy browser setup, no Python

preflight: on first use the bundle provisions the pinned runtime wheel into

~/.local/share/envoy-dsh/runtime (%LOCALAPPDATA%\envoy-dsh\runtime on

Windows) with uv or the system Python's venv, and the isolated Chromium is

installed the first time a page actually needs a browser. An envoy already on

PATH is used as-is when it is new enough. The one machine it cannot cover has

neither envoy nor uv nor python; the mount then fails with a single line

naming uv. Browser profiles, ASR, and OCR stay optional and on-demand — see

[INSTALL.md](../../skills/envoy/INSTALL.md) when a task needs them.

A visible window is not the agent's to open

Envoy reads headlessly. When a page needs the user's identity, the tool returns

requires_human: true inside details.needs_user_action; relay the question and

options to the user, stop, and wait for their answer. Do not set

ENVOY_VISIBLE_BROWSER, and do not run a command that opens a window. Visible

mode only works for a human at an interactive terminal (stdin and stdout both a

TTY, with explicit opt-in); the CLI refuses it under this plugin's stdio

transport, so a login prompt with no window on screen is expected.

Install

In the app: Plugin Manager → search Envoy → Install. That is the whole flow —

the bundle ships its own Harness patch, so nothing in the profile is edited by

hand.

From a shell, one command (it finds the CLI inside the desktop app when dsh

is not on PATH):

curl -fsSL https://raw.githubusercontent.com/regrevia/Envoy/main/integrations/install.sh | sh -s -- dsh

Without the script it is the same single command, optionally with

--profile <name>:

dsh plugin --profile web add envoy-dsh

A release tarball (envoy-dsh-<version>.tgz on the GitHub release) i

…(truncated)