deepseekplugins

DeepSeek Harness plugin

dsh-telegram-bridge-winada82

A DSH profile bundle that ships the Telegram ↔ DeepSeek Harness bridge as a model-callable install tool. Requires the session sandbox policy to allow subprocess TLS to api.telegram.org

Tools & Capabilities
Jump to install

Source facts

Repository
winada82/dsh-telegram-bridge
Latest update
Aug 18, 2026
Category
Tools & Capabilities
GitHub stars
0
Format
plugin
Catalog evidence
Upstream dsh.bundle evidence
Evidence path
package.json#dsh.bundle
Checked against
0.1.0-rc.8
Upstream check date
2026-08-20

This evidence comes from the upstream catalog. This site has not installed, run, or security-reviewed the plugin.

Install

Start with a prompt that asks an agent to review the GitHub repository and source. Switch to the command if you want to install it yourself.

Copy this prompt into DSH, Codex, or another agent and ask it to review the GitHub repository and source first.

Do not install or run any commands yet. Read this plugin's GitHub repository, README, and relevant source code. Then answer the questions below clearly and directly so I can decide whether it fits my needs:

1. What is this plugin, and what problem does it solve?
2. Who is it for, and what are its typical use cases?
3. How is it used after installation? Include one minimal example.
4. What known limitations or privacy, security, compatibility, or maintenance risks does it have?
5. Give a clear recommendation: recommend, conditionally recommend, or do not recommend, with reasons.

Distinguish statements documented by the repository, inferences from source code, and unknowns. If evidence is insufficient, say so explicitly. Do not guess or simply repeat the README.

GitHub: https://github.com/winada82/dsh-telegram-bridge
Plugin: dsh-telegram-bridge-winada82
Author: winada82

Check the source files

Read the README and other files from this plugin directory before installing.

File explorer3 files
README.mdSource · read only

winada-dsh-telegram-bridge

A DeepSeek Harness profile bundle that ships a Telegram ↔ DSH bridge as a one-call install tool. Once the bundle is mounted, the model gains an install_telegram_bridge tool that registers and starts the bridge in the current session.

What the bridge does

  • Long-polls the Telegram Bot API and routes incoming chat messages to a DSH sub-agent.
  • Sends the agent's reply back to the originating chat.
  • Adds a live status indicator (typing action + editable "⏳ Processing…" message with elapsed time).
  • Adds a /model command with an interactive inline-keyboard provider/model picker (callback_query-driven).
  • Adds /new (fresh conversation), /reset (clear context), /status (bridge health), and registers the lot with Telegram via setMyCommands so the client shows them in the / suggestion menu.
  • Persists a diagnostics file at .tg-bridge-diag.json in the host's writable cwd so you can inspect cycles, errors, and the resolved sandbox policy from outside the process.

Install

# from inside the DSH profile you want to use:
dsh plugin add github:winada/dsh-telegram-bridge

(pnpm add github:winada/dsh-telegram-bridge from the profile directory also works.) After the install completes and the host is restarted (or the bundle is picked up by reload), the install_telegram_bridge tool is registered.

Configure

You need a Telegram bot token from @BotFather and at least one allowed chat id (your own Telegram chat id, which you can find with @userinfobot).

In any DSH session, ask the model:

> Install the Telegram bridge. My bot token is <digits>:<secret> and my chat id is 5805491987.

The model will call install_telegram_bridge { bot_token, allowed_chat_ids: [5805491987] }. The tool returns the new Plugin id (tgram-<n>) and Package id, and the bridge starts polling immediately.

To re-install with a new token or different allowlist, ask the model to run install_telegram_bridge again — it appends a fresh Package and switches the active version via cordis_run update.

Requirements

The bridge uses pwsh Invoke-WebRequest as its HTTPS transport and routes every subprocess call through ctx.sandboxPolicy.resolve({ session }). The deployment default sandbox policy is workspace-write, which blocks TLS to api.telegram.org (the subprocess fails with "The SSL connection could not be established ... inner=Authentication failed"). The bridge therefore requires the resolved session policy to be danger-full-access (or equivalent) for its subprocesses.

The install tool does not check this — it succeeds under any mode. If polling times out, check /status (the bot's bridge status reply) and your profile's cordis.patch.yml for the relevant sandbox-policy row.

Known limitations

  • The transport uses one pwsh process per Telegram HTTP call; the cadence is about one cycle every 3-6 seconds plus occasional stalls up to 30 seconds on poor networks. Acceptable for personal bots, not for high-throughput fan-out.
  • The dynamic Plugin lives in process memory — it disappears when DSH restarts. After a restart, ask the model to call install_telegram_bridge again, or extend your profile boot to call it automatically.
  • Per-chat model overrides are kept in process memory only.
  • The bot's conversation history per chat is capped at 12 turns.

License

MIT.

Back to searchOpen GitHub repository

More related plugins

View category