This article is derived from the plugin's already-indexed fields (wiki / faq / compatibility_json / readme), not freshly generated by AI. Source field is noted at the end of each section.

Quick start

dsh-plugin-bridge

— source: plugin_wiki.wiki_content

Install & verify

dsh plugin --profile web add dsh-plugin-bridge

Run the command above in your DSH Web Profile. Then enable the plugin in the plugin list.

— source: plugins.install

Key points

• Default — accuracy first: the target restates the handoff in one short turn and waits. You verify it before any work starts.
• --continue — lower latency/cost: the target restates and begins the next step in the same model request.
• In both confirmation modes, any stored goal is paused before kickoff. The goal driver cannot silently queue another model round.
• If pausing fails, Bridge fails closed: it cancels automatic startup and sends no kickoff.
• Installing the plugin adds zero prompt tokens to normal sessions. /bridge is a host slash command, not a model tool or skill.

— source: plugin_wiki.readme_en (fallback readme_raw)

FAQ

Must I restart dsh web after installing the plugin?

Yes. The plugin is mounted at startup. After installing, you need to restart dsh web once, and /bridge will appear in the input box (README.md:44 / docs/guide.zh.md:17).

Will the plugin become invalid after upgrading DSH?

After upgrading, run /bridge --doctor first. It will print out which of the 13 gateway methods are currently exposed, the current mode, and the active configuration; if any method is missing, it will directly name it (src/command.ts:212-229 / src/api-rpc.ts:74-82).

How much does the new session "remember" after migration?

In the pro tier, probe availability is 95%; what gets lost is mainly things like numbers being completed to common values (ports rewritten to 3000/8080), so be sure to scan numbers during preview (README.md:84-95 / docs/guide.zh.md:131).

Why not switch preset directly in the original session?

The upstream has a hard lock at the gateway layer, and it's locked correctly: tool calls in history are only valid under the original tool set. Changing preset midway will leave "ghost calls" that the new preset cannot execute, silently degrading quality. Bridge chooses to create a new session for migration rather than bypassing the lock (README.md:146-152 / src/migrate.ts:413-420).

How much token does migration cost? Will it make normal sessions more expensive?

When only migrating without installation, normal sessions use 0 prompt tokens; the compression worker实测about 1.6K input + 0.7K output. The default mode spends an extra confirmation round that only restates; --continue merges the restatement and work into the same goal round. The big token cost is usually the subsequent agentic work (README.md:46-58 / docs/guide.zh.md:139).

What if the numbers or paths in the summary are wrong?

The preview result will be written to a local temporary file and the path will be printed. Just edit that file directly, then run /bridge code --go --file to execute with the modified summary (src/command.ts:310-330 / docs/guide.zh.md:62-68).

How to roll back if not satisfied after migration?

The original session is not touched at all; continue working in the original session; archive the new session. Bridge does not write to the original session (src/command.ts:286 / README.md:124-126).

Which DSH versions are supported? How much Node is needed?

Verified interfaces on DSH 0.1.0-rc.6 / rc.7 / rc.8; Node ≥ 22 (CI covers 22/24). No native modules (package.json:37-50 / README.md:169).

— source: plugin_wiki.faq_json

Compatibility

• DSH: 0.1.0-rc.6+
• Node: >=22
• Platforms: 跨平台

— source: plugin_wiki.compatibility_json

Pitfalls

Review the upstream repo before installing. This guide is auto-derived from indexed fields and may lag the latest release. If anything contradicts the official docs, treat the upstream source as authoritative.

— source: general rule