Claude-to-IM: a DI-driven bridge from Claude Code SDK to Telegram, Discord and Feishu

The integration work Claude-to-IM takes off your hands

Wiring a coding agent into a chat platform is mostly plumbing that has nothing to do with the agent. Telegram wants long polling and HTML; Discord wants a Gateway WebSocket and its own Markdown dialect; Feishu wants WSClient and rich text cards. Each has different message length ceilings, different rate limit behavior, and different ways of showing a button the user can press. Claude-to-IM targets that layer specifically. According to the README, it handles message routing, streaming previews, permission approval flows, Markdown rendering, chunking, retry, rate limiting, deduplication and audit logging, and it delegates persistence, LLM calls and permission resolution back to the host application through dependency injection. The intended reader is a developer building a product that already has a database and an LLM client, and who wants IM reach without owning three adapter codebases. The README is explicit that this is a library, not a standalone application, and it points anyone who wants a finished desktop client at CodePilot, the GUI project it was extracted from.

Adapters, Bridge Manager and the four interfaces you must write

The README's architecture diagram is a straight line: an adapter turns platform traffic into an InboundMessage, the Bridge Manager orchestrates, and the host application sits below a dependency injection boundary. Inside the manager, four pieces do the work. The Channel Router maps an incoming chat to a bound session. The Conversation Engine drives LLM streaming. The Permission Broker runs the tool approval flow. The Delivery Layer does chunking, retry and deduplication. The README states that all bridge modules reach host services through a DI context obtained from getBridgeContext(), never through direct imports. That is the design decision the whole library rests on, and it is also the cost: four interfaces stand between you and a working bridge. BridgeStore is the largest, described in the README as roughly 30 methods covering settings, sessions, messages, channel bindings, audit logs, dedup tracking, permission links and channel offsets. LLMProvider wraps your model client. PermissionGateway resolves pending tool permissions. LifecycleHooks is optional. The package.json confirms the runtime footprint: @anthropic-ai/claude-agent-sdk, discord.js, @larksuiteoapi/node-sdk, markdown-it and ws, with Node 20 or newer required.

Installing claude-to-im and running the in-memory example

The README gives two install paths. The first is the published package, which is version 0.1.0 in package.json and requires Node 20 or above.

npm install claude-to-im

The second is a clone, useful if you want to read the host interface definitions while you work.

git clone https://github.com/op7418/Claude-to-IM.git
cd Claude-to-IM
npm install

Before writing any host code, run the bundled example. It is self-contained, with an in-memory store and an echo LLM, so it exercises the bridge without a bot token or a database.

npx tsx src/lib/bridge/examples/mock-host.ts

The README does not describe the expected console output of that example, so treat it as a way to watch the message path rather than as a pass/fail check. Once you have a host, registration is three calls. The example below is the README's own, with the four interface objects stubbed.

import { initBridgeContext } from 'claude-to-im/context';
import * as bridgeManager from 'claude-to-im/bridge-manager';
import type { BridgeStore, LLMProvider, PermissionGateway, LifecycleHooks } from 'claude-to-im/host';

const store: BridgeStore = { /* your persistence layer (~30 methods) */ };
const llm: LLMProvider = { /* wraps Claude Code SDK streamChat */ };
const permissions: PermissionGateway = { /* resolves pending tool permissions */ };
const lifecycle: LifecycleHooks = { /* optional start/stop callbacks */ };

initBridgeContext({ store, llm, permissions, lifecycle });
await bridgeManager.start();

const status = bridgeManager.getStatus();
// { running: true, adapters: [{ channelType: 'telegram', running: true, ... }] }

Configuration is not a file the library reads. The README states that every setting is resolved through BridgeStore.getSetting(key), so your host decides whether that means a database row, an environment variable or a settings panel. Three keys are required: remote_bridge_enabled, which must be the string "true"; bridge_{adapter}_bot_token, for example bridge_telegram_bot_token; and bridge_{adapter}_allowed_users, a comma-separated authorization list. Optional keys include bridge_auto_start (default "false"), bridge_{adapter}_enabled (default "false"), bridge_{adapter}_stream_enabled (default "true"), bridge_default_cwd (default $HOME) and bridge_model, whose default the host decides. Replace {adapter} with telegram, discord or feishu.

The BridgeStore surface and the SSE format are the real adoption cost

Two constraints decide whether this library fits your project. The first is the size of BridgeStore. Roughly thirty methods is not a thin adapter over a key-value store; it is a schema, and the README lists what it has to cover: settings, sessions, messages, channel bindings, audit logs, dedup tracking, permission links and channel offsets. If your application has no persistence for chat sessions and per-channel offsets, you are designing that model before the bridge does anything useful. The second constraint is the LLM interface. The README says LLMProvider.streamChat() must return a ReadableStream<string> of SSE-formatted events matching the Claude Code SDK's protocol: text, tool_use, tool_result, permission_request, status and result. The README is blunt that this is not a generic chat completion interface. If you are not on the Claude Code SDK, you are writing a translator from your client's output into that event vocabulary, and the shape of tool_use and permission_request events is exactly what your translator has to get right. The README also notes there is no bundled database driver and no LLM client, which is consistent with the DI design rather than a gap in it, but it does mean the library cannot be evaluated end to end without host code.

Where Claude-to-IM is the wrong choice

The clearest failure case is a team that wants a bot running this afternoon. Nothing in the README offers a deployable binary or a container; the out-of-the-box path is CodePilot, a separate desktop application, not this library. A second mismatch is any stack that is not Node.js, since the package ships TypeScript with an engines field of node >= 20 and the DI interfaces are TypeScript types. A third is a host that cannot produce the SDK's SSE event stream. The README says adapting another client's output to that format is your job, and there is no fallback path documented for a plain chat completion API. There is also a thinner area worth noting: the README documents what the security layer does, listing input validation, token bucket rate limiting at 20 msg/min per chat, user authorization whitelists and audit logging, but it does not document how failures in those paths surface to the operator, and it does not describe rollback or recovery behavior for a partially delivered message. The deduplication and retry logic exist, but what an operator sees when retries are exhausted is not stated.

How this differs from writing your own grammY or discord.js bot

The realistic alternative is not another bridge library; it is three small bots. A developer would reach for grammY or node-telegram-bot-api for Telegram, discord.js for Discord and the Feishu SDK directly, then write the glue. The difference in approach is where the abstraction sits. A hand-written bot owns one platform and can use that platform's idioms without translation: Telegram's HTML parse mode, Discord's embeds, Feishu's cards, each handled natively. Claude-to-IM instead normalizes all three behind one InboundMessage and one outbound delivery layer, and pays for that with per-platform adapters that must translate Markdown into three dialects and with a single rate limiting policy of 20 msg/min per chat that applies across platforms. The second difference is session state. A small bot can keep a chat-to-session map in memory and lose it on restart; Claude-to-IM pushes that state into BridgeStore, which is more work up front and survives restarts. If you only ever need one platform, the normalization buys you little and the thirty-method store is a heavy tax. If you need three, the alternative is maintaining three permission-approval flows that behave differently.

Maintenance, versioning and the MIT licence

The repository is not archived, and the last push was on 2026-03-23. That is roughly six months before today, so the project is not in a state where regular updates can be assumed from the commit history alone. There are no retrieved releases, and package.json still reads version 0.1.0, which means the published artifact has not been versioned past a pre-1.0 number. For adopters this matters in two ways. The package is published with a prepare script that runs tsc -p tsconfig.build.json, so installing from git builds from source, and the exports map points at dist paths for the bridge context, adapters, markdown and security modules. Upgrade cost is therefore tied to TypeScript compilation rather than to a bundled runtime. The licence is MIT, which permits commercial use and modification; the repository ships a LICENSE file at the top level alongside README.md and README.zh-CN.md. The dependency list includes @anthropic-ai/claude-agent-sdk, discord.js, @larksuiteoapi/node-sdk, markdown-it and ws, so your dependency surface grows by those packages plus their transitive trees. Nothing in the README describes a migration policy or a compatibility guarantee between minor versions, and at 0.1.0 that is the assumption to work from.

Editorial conclusion

Adopt Claude-to-IM if you already run a Node.js 20+ application with its own persistence layer and you want Telegram, Discord or Feishu support without writing three separate bot integrations; the DI surface is the price of that reuse. Do not adopt it if you want a running bot today, if you are not using the Claude Code SDK, or if you cannot commit to implementing and maintaining roughly thirty store methods. Before writing any adapter code, verify two things in the source: that the BridgeStore method list in src/lib/bridge/host.ts matches the storage primitives you already have, and that your LLM client can emit the SDK's SSE event protocol, because that format is the one interface the library will not abstract away for you.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. op7418/Claude-to-IM on GitHub
4. README