[开源] Patch Courier： Email 进来， Codex 在你的 Mac 上干活

返回 🚀 分享创造

[开源] Patch Courier： Email 进来， Codex 在你的 Mac 上干活

mitsuko 0

2026-04-27 01:28 · 2 次浏览 · 0 条评论 · 0 cool

最近在做一个本地优先的小工具 Patch Courier ，想解决一个很具体的问题：

人不在电脑前时，能不能继续把任务发给自己 Mac 上的 Codex 去跑，但仓库、凭据、审批和执行策略都留在本地。

TL;DR：这是一个 Email -> 本机 Codex -> Email 的 macOS daemon + console 。

现在的做法是：

收到可信发件人的邮件后，把一个 mail thread 尽量映射到一个 Codex thread
真正执行还是走本机 codex app-server
审批、补充信息、完成结果继续通过邮件往返
macOS app 负责看 threads / turns / approvals / mailbox health
状态持久化到 SQLite ，邮箱密码放 Keychain
我为什么做这个，而不是直接上云端 Agent：

有些代码库和 provider 凭据我不想交给第三方服务
Email 很适合做异步审批、结果通知和审计留痕
daemon 持有状态，UI 重启后线程和 approval 不会丢
当前已经跑通：

IMAP / SMTP mailbox loop
approval request / completion / failure 的邮件回发
durable turn recovery
sender policy / workspace scope / mailbox health
最近补的是 v0.2 的可靠性和恢复能力：重启恢复、重复 approval 邮件抑制、mailbox replay 去重、poll failure 持久化。

现在还是 pre-1.0 的 macOS 原型，更适合愿意折腾的开发者：

需要 macOS + Xcode CLT
需要本机装好 Codex CLI
onboarding 还在继续补
仓库： https://github.com/owenshen0907/patch-courier

README （中文）： https://github.com/owenshen0907/patch-courier/blob/main/README.md

如果你对这些方向有经验，想听听反馈：

“邮件驱动本地 agent” 这个交互模型有没有价值
approval / safety / sender policy 该怎么设计更合理
这类工具更应该先做邮件，还是先做 Slack / Matrix / 本地 Web inbox
如果方向对你有帮助，欢迎拍砖、提 issue 、提 PR 。

原创

0 cool

暂无评论，来说两句吧

登录后评论

系统节点

兴趣节点全部

[开源] Patch Courier： Email 进来， Codex 在你的 Mac 上干活

评论 (0)

系统节点

兴趣节点 全部

[开源] Patch Courier： Email 进来， Codex 在你的 Mac 上干活

评论 (0)

兴趣节点全部