我把 Codex 接进了微信

聊天框成了给本机 Codex 派活的入口。

原文 https://aifellow.ai/articles/tc01
国内 https://aifellow.cc/articles/tc01

这个项目受了《在微信里使用 Claude Code，刚刚在 GitHub 上开源了这个 Skill。》的启发。但我这次要做的，不是复刻一遍 Claude，而是想把 Codex 做成一个真正顺手、能长期跑的微信入口。

项目开源 →

## 微信里给本机 Codex 派活

- 直接在微信里给本机 Codex 派活，不用远程桌面，不用先回到终端。

- 支持多轮上下文，消息会按 thread_id 接回同一条会话。

- 支持图片分析，不只是“提示收到”，而是真的下载、解密、交给 Codex 处理。

- 支持 /status、/clear、/cwd、/model、/mode 等命令。

- macOS 上可以用 launchd 常驻，重启以后还能继续跑。

## 这件事为什么值得做

我一直对“把入口做薄”这件事很有兴趣。

不是为了炫一个“微信里也能跑 AI”，而是为了把一个本来只能坐在电脑前完成的动作，改成你在路上也能随手触发的动作。

你突然想到一个需求，发条微信过去；本机上的 Codex 开始执行；等你回到电脑前，结果可能已经在那儿了。

这和远程控制电脑不是一回事。

我想做的，是把 Codex 本身变成一个低摩擦入口，而微信只是那个几乎没有学习成本的壳。

## 我怎么把它做出来

我这次选的方案很直接：

微信 -> 微信协议层 -> 本地 daemon -> Codex CLI -> 微信

没有接 Gateway，没有配公网 IP，也没有折腾域名。

原因很简单。对个人开发者来说，链路越短，越容易稳定，越容易长期维护。

只要扫码绑定、长轮询、消息解析、媒体下载这些底层链路跑通，后面的执行器就只是一个可以替换的模块。这次我把它换成了 Codex CLI。

所以这个项目最后收敛成了几块很实用的东西：

- 微信协议层

- 本地守护进程

- Codex 桥接层

- 会话持久化

- 图片处理

- 命令系统

我没有故意把它做得很花。我更关心的是三件事：能不能持续跑，出问题能不能定位，真实消息来了会不会露馅。

## 真正难的，不是接通，而是把坑踩完

这类桥接项目最容易出现一种假象：演示能跑，一上真实消息就开始失真。

我这次最典型的两个坑，刚好都说明了这一点。

第一个坑，是第一条消息能回，后面就没反应。

最后查出来不是微信协议坏了，而是 codex exec resume 被我放在轮询线程里同步等待了。只要 Codex 忙一点，后面的消息就全部堵住。

这个问题后来被我拆掉了：

- Codex 执行改成后台异步

- 增加子进程超时保护

- daemon 启动时清理遗留的 processing 状态

第二个坑，是图片其实收到了，但下载和解密链路错了。

我最初按旧结构读图片字段，真实线上消息却是另一套 payload。结果用户看到的是“图片已收到，但下载或解密失败”，本质上不是没收到，而是协议适配层判断错了。

我把真实图片链路重新对齐以后，这条能力才算真正闭环：

- 按真实结构读取 image_item.media

- 优先使用正确的图片密钥

- 修正微信图片 CDN 下载地址

我不太喜欢那种“看起来能用，但真实场景一来就开始胡说”的工具。所以这部分我宁愿多花时间，也要把它收干净。

## 现在 WeChatCodex 已经到了什么程度

它现在已经不是一个演示用 demo 了，而是一套能在我机器上稳定跑的本地服务。

目前已经支持：

- 微信文字消息接入本机 Codex

- 基于 thread_id 的多轮上下文

- 图片消息交给 Codex 分析

- 常用 slash 命令控制运行状态

- launchd 常驻运行

- 本地保存账号、配置、日志和会话

对我来说，一个项目值不值得继续做，不看它“概念上新不新”，而看它有没有把一条真实工作流补完整。

WeChatCodex 做到的，正是这一点。

## 先把真实链路打通

如果你也想把本机上的 Codex 接到微信里，可以直接看这个项目：

https://github.com/DrDavidDa/WeChatCodex

我一直很看重一类项目：先把真实链路打通，再把工程慢慢打磨到别人也能复用。

WeChatCodex 现在只是一个开始，期待后续微信端能有更多玩法。