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.