我把 Claude Code 塞进了微信，从此可以躺在床上写代码

昨晚已经躺下了，突然想起白天那个 hook 还有个小 bug 没改。爬起来开电脑？太累了。手机上没法跑 Claude Code，又不想专门为这点事走到桌前。

最后我做了件事：直接在微信里给一个叫”微信 ClawBot”的好友发了一句话，让它替我去 Mac 上跑 Claude Code，把改完的 diff 贴回来给我。

我躺在被窝里看完了 diff，回了一句”提交”，它在我桌面那台休眠前的 Mac 上把代码 commit 了。然后我关灯睡觉。

 微信里和 Claude Code 对话——和在终端里没什么两样

一、它是什么

一句话：一个把微信和你本机 claude CLI 连起来的桥。

微信消息 → 微信 ClawBot 协议（iLink 长轮询）
       → 这个桥（在你 Mac 上常驻）
       → subprocess: claude -p "你的话" --resume <session>
       → 回复回微信

不用 API key，走的是你已经付了的 Claude Max 订阅。每个微信联系人独立工作目录、独立会话——你在 A 群的对话和 B 朋友的对话互不干扰。支持 /cd、/new、/history、/resume 这些 slash 命令，行为和你在终端里用 Claude Code 几乎一致。

ClawBot 是腾讯官方放出来的一个个人号 AI 协议（iLink），原本是给开发者接 AI 助手用的。我把它接到了 Claude Code 上。

二、用起来是什么感觉

场景一：地铁上。

我：”看下我们昨天那篇文章发布之后公众号后台的阅读数据。”

Claude：（在我 Mac 上跑了一段脚本，回了一段总结）

我没带电脑。但 Mac 在家开着，Claude Code 在 Mac 上跑，微信在我手机上。三件事被这个桥串了起来。

场景二：和家人吃饭，朋友突然问我一个技术问题，关于他正在调的一个 Python 脚本。

我（在微信群里）：@微信ClawBot 这个报错怎么解 ……

Claude：（直接给出诊断 + 修改建议）

我连手机都不用切 app。

场景三：晚上躺床上，想起来某个 commit message 写错了。一句话让它在 Mac 上 amend 一下，push。这种事，开机的成本比修复本身高十倍。 桥让”修复”的成本降到了发一条微信。

三、为什么是微信，不是别的

我知道 Claude Code 已经有手机 app 了，也有 Web 版了。但它们都在云端跑，不在我的 Mac 上跑。

我想要的是：让 Claude 在我自己的电脑里、我自己的代码里、我自己的环境里干活——MCP 配置是我的、登录态是我的、.env 是我的、Chrome 是我的。任何在云端 Claude 上做不了的事（比如调用本地 Chrome、读本地文件、跑本地服务），桥都能做。

而入口必须是微信，因为我已经在微信里了。我不用专门切到一个新 app、不用记新密码、不用学新交互。微信群里 @ 一下就能用。最低门槛的入口，比任何专门设计的 app 都强。

四、关于安全

这是我最警惕的部分。一个能在我 Mac 上随便跑命令的微信 bot——听起来就像一个等着被滥用的后门。

我的红线：

• • 默认工作目录不是 $HOME，而是 ~/cc-wx-sessions/{chat_id}/。每个微信对话被关在自己的沙盒里，碰不到我的 .ssh、.aws、.env
• • /cd 出去要主动——你不指它，它绝不会自己跑到你的源码目录里乱翻
• • 没有任何对外端口——这个桥只主动对腾讯长轮询，外面打不进来
• • 未来的 M3 会加 --disallowedTools 基线——比如禁掉 Bash(rm*)、禁掉 Bash(git push --force*) 之类的破坏性命令

风险还是有的：一旦微信账号被盗，攻击者就拿到了你 Mac 上一个能跑 Claude 的入口。所以这个东西我只推荐给：把微信账号当生命线、并且能接受沙盒外目录授权风险的人。我自己用，是因为我对自己的微信账号安全有信心，并且我从不让它 /cd 到我没看过的目录。

五、踩了几个坑

完整都在仓库 README 的”Protocol gotchas”里，挑两个最离奇的说说。

坑一：iLink 协议返回的 qrcode 字段不是二维码内容，而是个 opaque id。真正的登录 URL 在叫 qrcode_img_content 的字段里——名字叫”图片内容”，里面塞的却是个 URL 字符串。腾讯的协议文档里没写。我是去翻一个早期 demo 的源码才发现的。

坑二：sendmessage 接口如果不带 from_user_id: "" 和 client_id: <uuid>，服务端会 200 返回 {} 假装成功——但只要回复超过 1 秒就静默丢弃。我最早调通的时候，echo bot 工作得很好，一接上 Claude（响应几秒）就全部消息消失。我以为是 Claude 的问题，查了两小时，最后发现是这个。

这两个坑教我的事是一样的：协议文档可以骗你，但 demo 源码不会。任何写桥接的人，第一件事应该是去 GitHub 上找一个跑通了的最小 demo，逐字段比对。

六、想试的话

仓库地址：

https://github.com/andyleimc-source/wx-cc-bridge

git clone https://github.com/andyleimc-source/wx-cc-bridge.git
cd wx-cc-bridge
make sync
make run         # 第一次跑，扫码登录

第一次启动会在终端打印一个二维码，用你想当 bot 的那个微信号扫一下——之后这个号就是你的私人 Claude Code 入口。登录态存在 ~/.wx-cc-bridge/token.json，下次直接后台跑。

后台常驻（macOS launchd）：

make install-service
make logs

前置要求：

• • macOS + Python 3.11+ + uv^[1]
• • 本机已装 claude CLI 并登录了 Max 订阅（不能配成走 API，否则会被收双倍费）
• • 一个能注册成 ClawBot 的微信号——这是腾讯那边的事，不是每个号都能注册

七、为什么要做这个

老实说，做这个东西的原始动机很简单：我懒。我不想为了一个小修改专门走到桌前坐下、打开 IDE、找到那个文件、输入命令。

但做完之后我意识到一件更大的事：入口在哪里，使用频率就在哪里。同样一个 Claude Code，放在终端里我一天用十次，挂到微信里我一天用五十次——因为微信本来就开着。

桥本身没什么技术含量，三个文件搞定。但它把一个”专业工具”变成了”日常工具”，把一个”工作场景的能力”变成了”任何场景都能用的能力”。这种变化，比工具本身强大与否更重要。

致谢：x1ah/wechat-ilink-demo^[2] 的作者，他那个 bot.mjs 是我能跑通 iLink 协议的唯一原因。腾讯的官方文档对此严重欠缺。

引用链接

[1] `uv`: https://github.com/astral-sh/uv
[2] x1ah/wechat-ilink-demo: https://github.com/x1ah/wechat-ilink-demo