Enables a WorkBuddy WeChat assistant to list, select, and continue local Codex chats from personal WeChat. Users can view a selected chat’s status, send messages to the same Codex chat ID, and read text replies through WeChat.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@codex-wechat-bridge But let me list my recent Codex chats first"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
通过 WorkBuddy 已连接的「微信助理」，在个人微信里列出、选择并继续本机现有的 Codex 聊天。桥接器是一个本地 MCP stdio 服务；它不直接登录微信，也不读取微信凭证。
列出最近 20 条 Codex 聊天，按编号选择其中一条。
查看所选聊天的状态，向同一个聊天 ID提交消息并读取文字回复。
当另一进程占用该聊天的写入权时，明确返回 writer_busy；不会改发其他聊天或创建副本。
目前不能主动向个人微信推送后台事件。Codex 的权限请求也可能需要在桌面端处理。WorkBuddy 的助理模型可能改写用户消息，因此发送重要指令后应核对实际提交内容。
Related MCP server: WeChat MCP Server
Windows 上的 WorkBuddy「微信助理」已由用户自行连接，并支持自定义 MCP 服务。
本机可运行、已登录的 Codex CLI（支持 codex app-server）。
Python 3.10 或更新版本；桥接器仅使用标准库。
电脑和 WorkBuddy 保持运行及联网。
克隆或下载此仓库，在 WorkBuddy 的自定义 MCP 配置中添加一个 stdio 服务。Windows 示例（将路径换成你自己的安装位置）：
{
"mcpServers": {
"codex-wechat-bridge": {
"type": "stdio",
"command": "py",
"args": ["C:/path/to/codex-workbuddy-wechat-bridge/src/codex_wechat_bridge.py"],
"description": "在微信助理中列出、选择和继续本机 Codex 聊天",
"disabled": false
}
}
}如果 codex 不在 PATH，设置环境变量 CODEX_BRIDGE_CODEX_EXE 为 codex.exe 的绝对路径。若 Codex 使用非默认数据目录，设置 CODEX_HOME。配置后在 WorkBuddy 中启用这四个工具：codex_list_tasks、codex_select_task、codex_task_status、codex_send_task。
在微信助理中发送「Codex任务」，收到编号列表后回复编号，再明确说明「发给 Codex：……」。桥接器只接收 WorkBuddy 调用工具时传入的消息。
选中的聊天 ID 保存在用户级状态目录中：Windows 的 %LOCALAPPDATA%/codex-workbuddy-wechat-bridge/state.json，其他系统的 $XDG_STATE_HOME/codex-workbuddy-wechat-bridge/state.json（未设置时为 ~/.local/state/...）。可用 CODEX_WECHAT_BRIDGE_STATE_DIR 改变位置。不要把此状态文件、WorkBuddy 配置、Codex 会话文件、日志或微信凭证提交到公开仓库。
本仓库采用文件白名单式 .gitignore，只允许公开的源码和文档进入 Git。发布前还应检查待提交文件和提交作者元数据。GitHub 的 secret scanning 主要识别凭证，不能代替姓名、邮箱、聊天标题和本机路径的人工审查。
py -m unittest discover -s tests -v 验证 MCP 握手与工具清单，不向任何 Codex 聊天发送消息。完整微信链路需在自己的设备上使用无敏感内容的测试消息验证。
MIT。见 LICENSE。
列出本机 Codex 聊天任务，给微信用户展示编号和标题。用户说‘Codex任务’或‘列出Codex聊天’时调用。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds useful scope ('本机') and output information ('编号和标题'), but does not disclose permissions, side effects, pagination, or other operational traits beyond what listing implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose followed by invocation trigger. Every sentence earns its place and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description covers scope and output content ('编号和标题') as well as the trigger. It is largely complete for a simple list tool, though it omits possible return details such as ordering or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to document. The baseline for a no-parameter tool is 4, and the description appropriately does not need to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('列出') and resource ('本机 Codex 聊天任务'), and clarifies output ('展示编号和标题'). The purpose is clear against siblings that select, check status, or send tasks, but it does not explicitly differentiate itself from those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger phrases: call when the user says 'Codex任务' or '列出Codex聊天'. It provides clear context for when to use the tool, but does not state when not to use it or name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按刚列出的编号选择一个 Codex 聊天任务，后续消息进入该任务。仅按用户明确指定的编号调用。
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose a meaningful stateful effect: subsequent messages go into the selected task. However, it says nothing about whether the selection persists across sessions, what happens with an out-of-range number, or what a successful call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the action and the follow-on state effect front-loaded before the invocation constraint. Nothing needs trimming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-integer selector with no output schema and no annotations, the description covers the essential semantics: what it selects, where the number comes from, and what happens after. Only error/edge-case behavior is left unstated, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (schema only says integer >= 1), so the description must add meaning. It does: the number refers to the index from the just-listed task set, which is the key semantic the bare schema lacks. It could still clarify whether numbering is 1-based and stable after listing, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (select) and resource (Codex chat task) plus the selection key (the number just listed). It implicitly ties to the preceding listing rather than naming a sibling like codex_list_tasks, so it is clear but not fully differentiated from siblings by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear invocation condition: only call with the number the user explicitly specified, and notes it must follow a listed set of numbers. It does not explicitly name codex_list_tasks or state what to do if no list exists, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
将微信用户明确写给当前选中 Codex 任务的原文发送到 Codex，等待最多90秒返回结果。不要自行改写、添加指令或自动批准权限。
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two real behavioral traits: a bounded 90-second wait for the result and a prohibition on auto-approving permissions. It stops short of describing what happens on timeout, whether the call is a mutating write, or any auth/rate-limit constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded: the action and scope come first, the behavioral constraints second. No filler, no restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no annotations and no output schema, the description covers purpose, timing, and content constraints adequately. It leaves the return value shape and timeout failure behavior unstated, which is a minor gap given there is no output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (the lone 'message' string is undocumented), so the description must compensate, and it does: it defines the parameter's content as the user's explicitly written verbatim text and forbids rewriting or injecting extra instructions. That is genuine semantic guidance the schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: send the user's verbatim text to the currently selected Codex task and wait up to 90s for a result. The 'currently selected Codex 任务' scope cleanly separates it from codex_list_tasks, codex_select_task, and codex_task_status without needing to open any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implicitly tells the agent what content to pass (the user's explicit original text) and forbids rewriting or auto-approving permissions, which is useful invocation guidance. However, it never says when to call this versus the sibling tools or what prerequisite (a task must already be selected) exists, and there are no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取当前选中 Codex 任务的最新运行状态。用户说‘查状态’时调用。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. '读取' implies a read-only, side-effect-free operation, but it does not state what happens when no task is selected, whether the call blocks, or how errors surface. For a trivial no-parameter read, this bare minimum is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste: the action/resource is front-loaded and the trigger condition follows immediately. Nothing is padded or repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no output schema and no annotations, the description is nearly sufficient. The remaining gap is that it never frames the 'currently selected task' dependency or the shape of the status it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics for the description to add or omit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (读取/read) and resource (the latest run status of the currently selected Codex task), which is clearly distinct from the list/select/send siblings. It does not explicitly name those siblings, so differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit invocation trigger ('用户说查状态时调用'), which is real routing guidance rather than a restatement. However it names no alternatives and omits the prerequisite that a task must already be selected via codex_select_task before this returns anything meaningful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0codex_list_taskscodex_select_taskcodex_send_taskcodex_task_statusScored across 4 tools
Each tool targets a distinct action in the workflow: list tasks, select a task, check status, send a message. There is no overlap in purpose, and the descriptions clearly indicate when to use each.
All tools share the codex_ prefix and snake_case, with mostly verb_noun patterns (list_tasks, select_task, send_task). Only codex_task_status deviates slightly by leading with the noun rather than a verb.
Four tools is well-scoped for a lightweight WeChat-to-Codex bridge; each tool corresponds to a discrete step and none feels redundant or missing.
The surface covers the core lifecycle: discover tasks, bind to one, monitor status, and send input. Minor gaps exist (e.g. no way to cancel, close, or create a new task), but the essential bridge workflow is intact.
Your WhatsApp Business inbox in Claude or ChatGPT: who's waiting, follow-ups and replies.
Read and act on your Workchats messages, tasks, meetings and files. You approve every send.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Your own WhatsApp in Claude and ChatGPT: read chats, draft replies, send messages you approve.