dsh-im 把聊天框接到本机 AI：Codex 有哪些相近方案？

在手机里发一句“检查这个项目的报错”，让电脑上的 AI 继续读文件、执行检查，再把结果送回聊天窗口——dsh-im 做的是这条连接。

它是社区维护的 DeepSeek Harness 插件，采用 MIT 许可证。与 Codex 比较时，最需要看清的是消息流向和执行位置：让 AI 读取聊天记录、从聊天软件发起云端任务、远程操作本机 AI，是三种不同需求。Codex 已有相关插件、官方入口和社区桥接，但它们不能仅凭“支持 Slack／Telegram”就互相替代。

本文是资料核查与选型分析。核对日期为 2026 年 10 月 7 日（北京时间）；没有安装这些桥接工具，也没有完成真实 IM 渠道试验。

dsh-im 接上了什么

dsh-im 把消息平台的输入交给本机 DeepSeek Harness，再将任务过程、答案和支持的附件送回原聊天。模型调用、文件操作与命令执行由 Harness 承担，插件处理机器人连接、消息路由、会话绑定和回传。它也提供 AI Office Connector，让本机主动连接公网 Office 接收任务；这是一条额外的任务入口。¹²

截至核对时，仓库 main 的 package.json 标为 4.37.0，要求 Node.js ≥22.19，声明兼容 DSH 0.2.0-rc.2、web Profile。更新日志把 4.37.0 标在 10 月 7 日。这些是仓库清单和维护者声明，不能据此保证 实际安装到的 npm 版本、任意宿主版本和你的设备均已验收。³⁴

README 的渠道表列出飞书、微信、钉钉、企业微信、企业微信自建应用、QQ、Slack、Telegram、Discord、WhatsApp、iMessage 与实验性的 Matrix。仓库简介仍写“9 channels”，更新日志另有“13 个聊天渠道”的内部口径；本文按具体接入方式说明，不把这些数字混成统一的平台数量。

• 飞书、钉钉、企业微信机器人：使用各平台的长连接或 Stream／WebSocket，过程展示随平台卡片能力变化
• 微信：README 描述为腾讯 iLink 长轮询和扫码绑定；不代表任意个人账号、接口或客户端都可用
• 企业微信自建应用：走 HTTP 回调，需要配置企业与应用凭据，和智能机器人接入分开
• Slack、Telegram、Discord：分别使用 Socket Mode、Bot API 长轮询和 Gateway；私聊、群聊提及与线程规则不同
• WhatsApp：扫码关联设备，默认只响应账号自聊，开放其他联系人需要另行配置
• iMessage、Matrix：iMessage 当前说明仅支持文本私聊；Matrix 加密功能仍有明确缺口

这里的价值在于保留任务上下文。可以把聊天绑定到已有 Session，使用 /new 让下一条消息建立新会话，用 /stop 停止当前回合，用 /steer 补充正在执行的任务。4.37.0 又加入每个机器人独立的排队／插话设置：默认排队，自动插话针对普通纯文字，沿用 /steer 权限。附件和审批继续走各自流程，AI Office 不适用这个设置。¹⁴

如果任务超时，README 还描述了后续结果检查与补发：继续跟踪原任务，完成后回到原聊天或线程，而非重新提交问题。维护者同时限定，补发不重放审批、问题或文件工具调用。评估这项能力时，应分别看“任务完成”和“平台收到结果”，不能只看机器人在线状态。¹

Codex 有类似插件吗？先看消息方向

图 1：依据公开文档绘制的结构示意，AI 生成，非产品截图。

Codex 有相近能力，分布在几条路线中。

在 Codex 内处理 Slack 内容，可以使用 Slack 插件。 OpenAI 当前插件文档把“总结频道、起草回复”列为例子。插件可以包含 Skills 和 MCP 工具：前者给出工作步骤，后者连接外部服务。此次目录检索也返回了 Slack；这是插件可发现性的证据，实际使用仍依赖账号连接、权限和工作区配置。安装读取 Slack 的插件，本身没有证明它能把 Slack 变成控制本机 Codex 的机器人。⁵

从 Slack 发起代码任务，有官方入口。 当前指南使用 @ChatGPT，在工作区启用 Cloud delegation 且具备可用的已发布共享环境时，把仓库工作交给独立 Codex Cloud 任务，再将结果返回线程。文档也提示此前使用 @Codex 的用户，在管理员启用新应用后改用 @ChatGPT。因此，旧教程里的名字和设置步骤需要复核。执行位置是云端环境，不是读者电脑上正在打开的目录。⁶

从 Telegram 驱动本机 Codex，社区已有桥接。 两个同名项目展示了不同实现：

• maleon17/codex-telegram-bridge 的 README 描述为每个 Telegram 用户维护一个常驻 codex app-server，支持恢复线程、停止和运行中补充消息；其要求是 Linux、Python 3.10+ 与 systemd。
• ssamssae/codex-telegram-bridge 的默认路径连接正在运行的 tmux Codex TUI，将输入送到可见终端，再观察 JSONL 会话日志回传结果；其文档还描述了审批按钮和媒体回传。该路线依赖终端、日志格式与桥接程序之间的配合。

这里的本机 Codex 指 CLI／TUI，或桥接维护的 App Server 会话；上述两款 Telegram 项目不能据此证明能接续桌面 App 当前聊天。这些是项目作者对实现和能力的说明，本次没有验证断线恢复、审批转发或多账号隔离。它们属于自行部署的社区桥接，不能当成 OpenAI 官方插件或安全背书。⁷⁸

• 在 Codex 中总结 Slack 讨论、准备回复：Slack 插件；当前 Codex 任务及连接的 Slack 服务
• 在团队 Slack 中发起仓库任务：官方 Slack 入口与 Codex Cloud；工作区授权的云端环境
• 从手机控制本机 Codex CLI 会话：社区 Telegram 桥接；自己维护的电脑或服务器
• 用飞书、微信等渠道调用本机 Harness：dsh-im；本机 Harness Host

还有一个容易混淆的例子：OpenAI 文档列出了 Apple Messages 插件，但明确说它不能让用户通过 Messages 远程与 ChatGPT 交互。读取或发送消息的工具，与接收消息并启动 Agent 的入口，需要分别核对。此次检索未确认一个与 dsh-im 渠道覆盖相当的统一 Codex 官方插件；这也不能推出社区没有其他实现。⁵

微信、飞书、企微、钉钉和 QQ：Codex 的社区选择

本次插件目录按平台中英文名称检索，没有返回这些中文 IM 的条目。这是当前账号可见目录的结果，不能推断私有市场或社区没有实现。公开仓库已经有更接近 dsh-im 的多渠道方案。

• 飞书、钉钉、企微、微信和 QQ 多渠道：cc-connect；桥接本机 Agent CLI，明确支持 Codex，也支持其他 Agent
• 个人微信私聊与会话管理：codex-weixin；优先使用 Codex App Server，可回退到 exec
• QQ，以及额外的微信文本通道：qq-codex-bridge；通过 CDP 驱动 Codex Desktop

cc-connect 当前中文 README 同时列出 Codex 与这些渠道，是本次找到的、在多渠道用途上更接近 dsh-im 的候选。文档区分 QQ 官方机器人和 NapCat／OneBot 自建桥接，说明企微 Webhook 模式需要公网 URL；不能将“大多数无需公网 IP”推广到全部模式。渠道能力表是维护者归纳，本次没有验证每种 Codex × 渠道组合。⁹

codex-weixin 是微信专用入口。文档明确只管理该服务创建和使用的会话，不接管全部终端历史；微信端没有审批弹窗，App Server 使用 approvalPolicy: never，仍在已有 sandbox 权限内执行。这表示不会等待审批，不表示自动获得全部权限，权限与失败行为需要试验。¹⁰

qq-codex-bridge 直接面向桌面应用，和 CLI 桥接不同。README 说明 Codex 驱动依赖桌面 DOM 与 CDP 可见性，桌面端改版可能需要适配；能否控制当前安装版本应作为首个验证点。以上三款都是社区工具，本次没有安装或做安全审计。¹¹

中文 IM 用户无需因为 Slack 有官方支持就迁移沟通方式。先看多渠道 cc-connect，或按微信、QQ 的具体需求核对专用桥接，再比较安装条件、审批方式和恢复能力，更贴近实际工作。

已有评测怎样读：先看它评的是哪一版

搜索得到的材料并不都属于运行评测。有些是目录介绍，有些是固定源码审阅。两份较有用的中文资料都给出了证据边界。

52DSH 的 dsh-im 页面以 2026 年 9 月 8 日核验的 4.15.0 为安装目标，并补充 9 月 12 日对 4.20.0 的候选复核。它明确未运行真实渠道，关注工作区切换、重启恢复、权限和附件回传。阅读这份资料，可以借用其验收问题；不能把旧版兼容表直接套给今天的 4.37.0。¹²

W.ai 的 9 月 8 日生态观察把 @xmanrui/dsh-im 4.15.0 放在版本兼容与权限的背景中讨论。报告关注宿主升级、会话恢复和插件分发证据是否齐备，没有给出这款插件的生产容量实测。它的评级属于作者在当时的审查框架中的判断，本文不把它转成今天的推荐分数。¹³

这两份材料共同提示一个选型方法：锁定宿主和插件的具体组合，先验证会话、工作区、权限与交付。它们没有提供可直接与 Codex 横向比较的统一延迟、成功率或成本测试。本次也没有补做这些实验，所以无法写“哪款更快、更稳”。

聊天入口方便了，操作范围仍要自己核对

图 2：验收问题示意，AI 生成，不代表这些检查已经通过。

dsh-im 的当前说明中，有几项直接影响使用范围。

扫码新建的飞书和 QQ 机器人，默认允许所有用户在私聊和群聊中聊天及执行内置命令。Telegram 默认兼容模式允许私聊，安全模式只允许白名单用户私聊，并忽略全部群聊；空白名单拒绝全部输入。WhatsApp 默认自聊。这些默认值不同，不能用“只给自己用”的意图代替实际配置。¹¹⁴

文件回传也需要单独看：README 明确说，插件不额外限制文件的工作区边界，只要 Harness 可读且平台允许，就可以交给渠道发送。因此，将机器人绑定到一个工作区，并不自动建立文件系统隔离。具体可读目录、工具权限与文件收件人仍需检查。Matrix 的说明则承认设备验证、密钥备份和媒体加密等能力尚未完整实现，不能仅凭支持加密消息就推断完整端到端保障。¹

对于正在做 AI 应用、教育产品或 Web 项目的团队，适合先选一个不含秘密的测试目录，放入自己创建的 notes.txt，只连接一个测试机器人，再完成以下检查：

1. 从允许账号请求列出目录第一层文件，核对 IM 消息、Host Session 与最终回复是否对应同一次任务。
2. 从未授权账号发送相同请求，确认它没有进入 Agent 会话。
3. 在两个测试目录之间切换，确认下一条输入使用哪个工作区、哪个 Session；测试停止和补充指令的实际效果。/stop 保留未开始的排队消息，也要检查它们后续是否执行。
4. 模拟断线与重连，确认任务是否继续、结果是否重复；如要回传文件，再核对来源路径与实际收件人。

这是一份建议实验，不是本文已经完成的测试。安装入口可以参考仓库当前命令 dsh plugin --profile web add -w @xmanrui/dsh-im，但试验记录应写下最终解析到的插件版本、宿主版本和配置。不要让浮动安装目标掩盖了所测组合。¹

如果需求主要是微信、飞书和企微上的本机任务入口，dsh-im 值得进入隔离试验；如果团队已围绕 Slack 和共享云端仓库工作，先核对官方入口更直接；如果要接续本机 Codex，社区桥接更接近这一需求，同时也带来维护终端或 App Server 连接的责任。

下一步有价值的证据，是一条可以对照的任务记录：谁发的消息，进入哪个目录和会话，怎样批准，结果交给了谁。渠道列表说明入口有多少；这条记录才能说明入口是否适合你的工作。

---

资料核对：2026-10-07，北京时间。配图均为 AI 生成概念插画或结构示意。本文未安装插件、未运行真实机器人、未测性能与生产稳定性。