CLI WeChat Bridge
把微信、企业微信、Telegram 接到本地 Codex、Claude Code、OpenCode 和 Pi，出门也能远程操控终端会话。
- Star 数
- ★ 538
- 最近更新
- 1 天前
- License
- AGPL-3.0
- 主语言
- TypeScript
- FA 评分
- 58/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 兼容但需适配Codex · Claude CodeChatGPT（部分支持）
- 费用
- 软件免费，模型调用费用自付
- 上手难度
- 中 · 需要几步配置
- 开始前需要
- 典型场景
- 主力开发者在本地终端跑 Codex 或 Claude Code，出门后想用微信继续给同一会话下任务并收结果。
- 不适合
- 希望完全脱离本地终端、把聊天窗口当主界面的团队
- 只想在 macOS 上开箱即用、不愿编译 node-pty 原生模块的用户
- 需要使用 ChatGPT.app 内置私有可执行文件的用户
- 源码审查
- 58/100 · 缺口较多
这个 Agent 能做什么，适合哪些场景？
CLI WeChat Bridge 是一个 Node.js（>= 22.13.0）命令行工具，把微信、企业微信、Telegram 的消息桥接到本机运行的 Codex、Claude Code、OpenCode 和 Pi，并把本地输出、审批请求与运行状态同步回聊天通道。它提供 wechat-setup / wecom-setup / telegram-setup 完成登录或配对，wechat-codex、wecom-claude、telegram-pi 等直接启动命令，以及 wechat-daemon / wecom-daemon / telegram-daemon 常驻模式管理多个 CLI 槽位。设计核心是保留原生终端体验：你继续在本地用原生 CLI 和启动参数工作，聊天工具只作为远程入口。会话一致性以本地为中心，支持多会话桥接、/codex、/claude、/opencode、/pi 切换、/confirm 审批、文件传输和 Codex 0.162+ 的 --attach-current-session 接管当前会话。代码采用 AGPL-3.0-or-later 与商业许可双协议，通过 npm 包 cli-wechat-bridge 分发。
桥接进程读取微信、企业微信或 Telegram 的消息，转发给本地 Codex（WebSocket RPC）、Claude Code（经 node-pty 的 PTY 交互）、OpenCode（@opencode-ai/sdk 会话 API）或 Pi（原生 TUI extension），再把 CLI 输出、审批提示和状态发回对应通道。wechat-setup 走扫码登录，wecom-setup 经 @wecom/aibot-node-sdk 建立长连接并输入 Bot ID/Secret，telegram-setup 使用 Bot API 长轮询并输入 Bot Token，后两者需在聊天里发送 /pair <code> 完成操作者配对。daemon 模式下支持 /codex、/claude、/opencode、/pi 切换 CLI，/all 同时下发，/status 查看状态，/model、/plan、/stop、/reset、/new、/resume 控制会话，/confirm、/deny、/answer 处理审批和结构化问答，/lang 切换中英文。文件双向传输：远程图片和文件保存到本地并把路径追加进 prompt，本地文件也可回传；Telegram 附件落到 ~/.cli-bridge/telegram/inbound-attachments/。daemon 还开放带 token 的本地 IPC 接口，供网页面板或脚本以与聊天完全一致的规则下发文本。
- 主力开发者在本地终端跑 Codex 或 Claude Code，出门后想用微信继续给同一会话下任务并收结果。
- 需要企业合规通道的团队，用企业微信智能机器人的 WebSocket 长连接远程接入本地 CLI，无需公网回调地址。
- 用 Telegram 做远程入口的海外用户，通过 @BotFather 建 Bot 后以 telegram-codex 操控本机项目。
- 同时用多个 CLI 的人，在微信里发 /codex、/claude 或 /opencode 在同一个 daemon 绑定的工作目录间切换。
- 想给自建网页面板或脚本接入的人，通过 daemon 的本地 IPC 接口把文本按聊天语义注入 CLI。
- 用 Pi 的人，通过原生 TUI extension 让微信、企业微信或 Telegram 接管同一个 Pi session。
如何安装或部署这个 Agent？
环境要求：Node.js >= 22.13.0，PATH 中至少已安装 Codex、Claude Code、OpenCode 或 Pi 之一，并准备好微信、企业微信或 Telegram 之一作为远程通道。
全局安装：
npm install -g cli-wechat-bridge@latestLinux 需要原生模块编译工具，且新版 npm 会阻止 install scripts，需显式允许：
sudo apt install build-essential python3
npm uninstall -g cli-wechat-bridge
npm install -g cli-wechat-bridge@latest --allow-scripts=cli-wechat-bridge,node-ptymacOS 若编译失败执行 xcode-select --install；Windows 需 Windows 10 1809 以上，node-pty 加载失败时运行 npm rebuild node-pty 并安装 Visual C++ Redistributable。旧包名 @unlinearity/cli-wechat-bridge 仍同步发布，可继续升级。安装后可用 wechat-daemon --doctor 检查环境。
如何使用这个 Agent？
先完成对应通道的登录或配对。微信扫码：
wechat-setup企业微信在“工作台 → 智能机器人”创建 API 模式机器人并选择长连接，取得 Bot ID 与 Secret 后输入：
wecom-setupTelegram 在 @BotFather 用 /newbot 建机器人取得 Bot Token 后输入，并在 10 分钟内于点开私聊发送 /pair <六位配对码>：
telegram-setup
telegram-setup --check进入项目目录后用直接启动命令拉起对应 CLI：
cd D:\work\your-project
wechat-codex
wecom-claude
telegram-opencode需要长期在线并切换多个 CLI 时改用 daemon：
wechat-daemon --adapter codex
wecom-daemon --adapter claude --profile work
telegram-daemon --adapter codex把当前 Codex 会话接入（需 Codex >= 0.162，不打开可见 CLI）：
telegram-codex --attach-current-session
telegram-codex --attach-current-session --codex-thread-id <id>随后在微信、企业微信或 Telegram 里发送普通文本即可下发任务；daemon 下可用 /codex、/claude、/opencode、/pi 切换，/status 查看状态，/confirm 或 /deny 处理审批，/daemon-stop 停止。建议首次启动后先从微信发一条消息，让 bridge 拿到最新的 context_token。
这个 Agent 有哪些优点和局限？
- 以本地 CLI 为主界面，保留原生终端与高级启动参数，聊天工具只作为远程入口。
- 单个 daemon 可在 Codex、Claude Code、OpenCode、Pi 之间用 /codex、/claude、/opencode、/pi 远程切换，并自动打开或复用可见终端。
- 审批与结构化输入可远程处理：/confirm、/deny 逐项审批，/answer 支持单题与多题（如 /answer 1=Yes;2=2）作答。
- 文件双向传输，远程图片和文件保存到本地并把路径注入 prompt，Telegram 还支持视频、语音和音频。
- daemon 开放带 token 的本地 IPC 接口，外部脚本或网页面板可按聊天同等规则注入文本。
- Claude Code 适配器依赖 node-pty 的 PTY 交互模式，node-pty 不可用时回退兼容模式可能导致 Claude Code 无法正常桥接。
- daemon 绑定启动时的工作目录，官方说明暂不支持从远程通道切换工作目录。
- 仅调用 PATH 中的独立 CLI，不会发现或调用 ChatGPT.app 等桌面应用捆绑的私有可执行文件。
- Codex 的 --attach-current-session 需要 Codex >= 0.162 共享 daemon 会话，Pi 0.85.0 及以上要求 Node.js >= 22.19.0，版本门槛较多。
- 微信冷启动或长期闲置后直接从本地终端先发消息，回发可能因 context_token 失效而失败，需先从微信发一条消息。
这个 Agent 与同类方案有什么区别？
README 提到的早期参考项目是 openclaw-weixin（早期 WeChat / Claude Code Channel 参考项目）以及腾讯微信团队发布的 @tencent-weixin/openclaw-weixin npm 包。与这些仅面向单一通道的参考不同，本项目同时覆盖 Codex、Claude Code、OpenCode 和 Pi，并统一支持微信、企业微信、Telegram 三个远程入口。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| CLI WeChat Bridge 当前 | 58 · 缺口较多 | 命令行工具免费 + 模型费 | ★ 538 | 1 天前 | TypeScript | Codex · Claude Code |
| Alethe 多智能体编码工作台 | 65 · 存在缺口 | 桌面应用免费 + 模型费 | ★ 927 | 1 天前 | TypeScript | Codex · Claude Code |
| Plannotator | 78 · 表现良好 | 命令行工具免费版 + 付费版 | ★ 9.5k | 今天 | TypeScript | Codex · Claude Code |
| NeuroSquad 终端控制台 | 76 · 表现良好 | 命令行工具免费 + 模型费 | ★ 53 | 5 天前 | TypeScript | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示：README 明确 Pi 以全权限本地代理运行、传入 --approve 且不增加工具审批层；Claude 默认注入 WebFetch(domain:*) 放行规则（可用 CLI_BRIDGE_STRICT_APPROVAL=1 关闭）；--yolo / --dangerously-skip-permissions 会透传给底层 CLI。审批队列有较细的测试（approval-queues.test.ts 覆盖逐项确认、失败保留、子会话归属），因此 user_confirmation 给 2。但 least_privilege 仅 1：默认放行网络抓取、Pi 无审批层、daemon 开放带 token 的本地 IPC 且可代通道发消息，权限面偏宽且未见最小权限设计说明。data_flow_transparency 与 sensitive_data_handling 各 1：README 说明凭据保存到 ~/.cli-bridge/telegram/account.json 等路径，但未系统说明消息内容、附件、上下文 token 的流向、留存与清理策略，也未说明日志是否脱敏。dependency_security 给 2：package.json 有 overrides 固定 hono、qs、path-to-regexp 等传递依赖版本，CI 用 --frozen-lockfile，属正向证据；但未提供审计报告或漏洞处置记录。external_effects 与 rollback 各 1：daemon 会自动接管并清理旧 bridge 进程、失效 lock 与旧 endpoint，属有副作用的自动行为，回滚仅靠 /daemon-stop 与重装，未见明确恢复流程。source_attribution 给 2：源文件带 SPDX 头与版权/来源声明，README 列出主要依赖与参考项目，但未逐项标注第三方代码来源。
self_consistency 给 2：README 的命令表、参数表与 package.json 的 bin 入口（wechat-*/wecom-*/telegram-* 共 21 个）基本一致，测试文件与源码路径对应。dependency_availability 仅 1：依赖 node-pty 原生模块，需编译工具链与 npm allow-scripts 放行，README 承认 Claude 适配器在 PTY 不可用时可能无法正常桥接；同时依赖外部 CLI（Codex/Claude/OpenCode/Pi）的具体版本区间，版本漂移风险由 README 自述而非机制保证。failure_messages 给 2：测试断言了明确的失败文案（如 'Send /model again'、'outside the displayed range'、'another session'、'expired'、'Restart'），README 也描述 context_token 失效、hook 超时等失败表现；但未见统一的错误码或诊断分级。
audience_and_scenarios 给 2：README 明确目标用户是坚持本地终端工作流、需要远程入口的开发者，并说明不把聊天工具当主界面。capability_boundaries 给 2：逐适配器列出状态与限制（Pi 无远程审批、Claude 需空闲提示符、OpenCode 依赖 server 回读、Codex attach 需 0.162+）。trigger_precision 给 2：指令表区分 daemon 与直接启动的适用范围，表情绑定要求出现在消息开头，/model 列表 5 分钟有效；但表情绑定与普通文本的边界仍可能误触发。environment_fit 给 2：覆盖 Windows/macOS/Linux 与 Node >=22.13.0，CI 三平台矩阵；但 Pi 需 Node >=22.19.0、Windows 需 1809+，环境约束较多。
information_architecture 给 3：README 有文档导航、分章命令表、参数表与适配器矩阵，结构清晰。install_notes 给 3：安装、更新、node-pty 编译依赖、allow-scripts 写法、各平台前置条件与 --doctor 自检均有具体命令。naming_stability 给 2：README 说明 1.1.5 移除 wechat-*-start 别名与 wechat-bridge* 命令，旧包名 @unlinearity/cli-wechat-bridge 继续同步发布，属有记录的迁移；但历史命名变更较多。examples_and_faq 给 2：有截图、命令示例与 troubleshooting 链接，但仓库内未提供 FAQ 正文。known_limitations 给 2：README 列出 daemon 不支持远程切换工作目录、不自动 OCR/抽取 PDF、Pi 全权限、Claude 需重启等限制。license 给 3：LICENSE.txt 为完整 AGPL-3.0 文本，package.json 声明 AGPL-3.0-or-later，README 说明双协议与商业授权路径。versioning_changelog 仅 1：package.json 版本 1.2.3，README 指向 docs/releases/README.md，但本次证据未包含变更日志内容。maintenance_responsibility 仅 1：作者与联系方式（GitHub @UNLINEARITY）可见，但发布者身份未经 FollowAgents 验证，无维护承诺、响应时限或安全披露渠道说明。
output_usability 给 2：远程侧输出带 [codex]/[claude] 等标签、支持 /status、/model、/resume 与文件回传，长消息按通道限制拆分；但输出仍以终端文本为主，结构化程度有限。marginal_value 给 2：把本地 CLI 会话桥接到微信/企业微信/Telegram 并保留原生终端体验，对特定工作流有实际增量；但同类桥接项目存在，差异化主要在多适配器与审批同步。cost_benefit 仅 1：需常驻 daemon、原生模块编译、外部 CLI 版本对齐与凭据管理，运维成本不低，而收益集中在离开电脑时的远程接入场景。
claim_traceability 给 2：README 的功能声明多能对应到 package.json 的 bin/scripts 与测试文件名（adapter-control、approval-queues、claude-resume），但未逐条给出实现位置。cross_source_corroboration 给 2：README、package.json、CI 工作流与测试文件在命令入口、质量门禁、平台矩阵上互相印证；但 CI 是否真正阻断合并取决于分支保护设置，README 未确认。fact_inference_separation 给 2：README 区分了已验证版本区间与实验性功能（如 Codex attach 标注实验性），但部分能力描述（如各适配器同步语义）缺少可核对的边界说明。本次为静态源码审查，未执行任何命令，置信度低。
- Pi 适配器以全权限本地代理运行并传入 --approve，bridge 不提供逐项工具审批；远程消息可触发本地文件读写与命令执行，请仅在受控目录与可信操作者下使用。
- Claude 适配器默认注入 WebFetch(domain:*) 放行规则；如需严格审批须显式设置 CLI_BRIDGE_STRICT_APPROVAL=1，否则常规联网请求会直接通过。
- daemon 在本地开放带 token 认证的 IPC，外部程序可代通道下发文本或发送消息；请确认该端口的暴露范围与 token 保管方式。
- README 未系统说明消息内容、附件与 context_token 的流向、留存期限与日志脱敏策略；凭据保存在 ~/.cli-bridge 下，请自行评估数据敏感度。
- daemon 启动会自动接管并清理旧 bridge 进程、失效 lock 与旧 endpoint，属有副作用的自动行为；回滚手段有限，建议先在非关键环境验证。
- 依赖 node-pty 原生模块与外部 CLI 的特定版本区间，安装需编译工具链与 npm allow-scripts 放行，升级后需重启 bridge/daemon/可见 CLI。
- 发布者身份未经 FollowAgents 验证，且本次证据未包含变更日志正文与安全披露渠道；生产采用前请自行核对版本与来源。
最近版本
来自该项目 GitHub Releases 的最新发布记录，说明为上游原文摘录，未经本站改写或测试。
-
发布说明摘录
版本 1.2.3 发布日期： 2026 年 10 月 13 日 概述 1.2.3 新增第三个消息信道 Telegram，并支持将消息信道附加到已经运行的 Codex TUI 会话。本版本修复独立 bridge 与 attach 模式下 Telegram 最终回复无法回传的问题，使启动提示显示实际信道，并提供完整中英文 README 与语言切换导航。 新功能 Telegram Bot API 信道 Telegram 沿用微信、企业微信的直接启动和 daemon 工作流，支持 Codex、Claude Code、OpenCode 与 Pi。信道使用官方 Bot API 长轮询，不需要公网回调地址。 1. 在 @BotFather 中发送 /newbot 创建机器人并取得 Bot Token。 2. 在本地运行 telegram-setup，输入 token。 3. 打开机器人的私聊，点击 Start，在 10 分钟内发送终端显示的 /pair <code>。 4. 进入项目目录，运行 telegram-daemon --adapter codex，或使用对应的直接启动命令。 | 用途 | 命令 | | --- | --- | | 操作者配对 | telegram-setup | …在 GitHub 查看 ↗ -
发布说明摘录
版本 1.2.2 发布日期： 2026 年 10 月 12 日 概述 1.2.2 进一步完善微信、企业微信与本地 CLI 之间的交互：新增 /lang 实时语言切换，支持远程回答 Claude Code 的结构化问题，并将审批统一为逐项处理。本版本同时修复 OpenCode 和 Codex 的子代理事件干扰父任务、OpenCode 2 表单答案提交错误，以及 Pi 错误信息丢失和中断状态不准确等问题。 新功能 通过 /lang 切换提示语言 微信和企业微信的直接启动模式与 daemon 模式均支持以下指令；本地测试通道沿用相同的命令规则： | 指令 | 功能 | | --- | --- | | /lang | 查看当前语言及切换方式 | | /lang zh | 切换为中文 | | /lang en | 切换为英文 | - /language 是 /lang 的别名；语言参数也接受 chinese、english、中文 和 英文。无效参数会返回使用说明，不会作为 prompt 发送给模型。 …在 GitHub 查看 ↗ -
发布说明摘录
版本 1.2.1 发布日期： 2026 年 9 月 28 日 概述 版本 1.2.1 在保留 OpenCode 1.18 支持的同时接入 OpenCode 2，让微信路由与可见 Codex 会话保持一致，并完成 Claude Code 切换模型时的二次确认。同时将 Codex CLI 已验证范围扩展至 0.157，并恢复已安装命令入口的可执行权限。 支持 OpenCode 2 bridge 现在同时支持 OpenCode 2 与 1.18。wechat-opencode、wecom-opencode 和 daemon 管理的 OpenCode 会根据已安装的 CLI 版本选用相应连接。可见终端会话、远程模型与计划模式控制、审批与提问、会话恢复、最终回复，以及在本地 TUI 中提交的提示词继续与远程通道连接。OpenCode 2 会转发已提交的本地提示词；其 TUI 不再发布草稿更新事件，因此输入中的草稿不会同步。每周 CLI 兼容性检查分别覆盖两条受支持的版本线。 可见会话与模型切换 …在 GitHub 查看 ↗