Codex 一开就是四十分钟。我一边等它跑，一边刷手机；等到觉得该好了，切回电脑一看——它十分钟前就跑完了，静静地在那儿等我 review。
这种"等得心焦、走开又错过"的循环，AI Coder 圈子里已经变成日经吐槽。之前解法五花八门：Tampermonkey 脚本挂网页轮询、跑完打开钉钉机器人、拉个 systray 图标闪红——都属于"补丁思路"，绕开了 Windows 本身已经在推系统通知这件事。
小众软件 09-06 挖到的开源项目 WinToastRelay，直接把这层壳撕了：Windows 那个右下角冒出来的 toast，原封不动转发到你手机。开发者 @RavelloH，MIT 协议，微软商店和 GitHub 双渠道。
TL;DR
- WinToastRelay 用 Windows 原生
UserNotificationListener监听所有 toast，事件驱动，不轮询、不装钩子驱动，任务栏托盘常驻内存约 14 MB- 接收端支持 Bark（iOS 首选）、WxPusher（Android 首选）、以及任意 Webhook；密钥存 Credential Manager，不落 JSON
- Codex / Claude Code / GitHub Desktop / Docker Desktop 只要能弹 Windows 通知，都能被中继
- 内置应用白名单：可以只放行 Codex，屏蔽掉 Teams 每三分钟提醒你开会
- Bark 那端配自建服务器，从触发到 iPhone 弹推送我实测 1.2 - 1.8 秒，全链路 HTTPS
为什么 AI Coder 特别需要"通知转发"？
传统 IDE 时代，编译顶多 30 秒，你根本没时间走开。AI Coding 完全不同：
- Claude Code 跑一个多文件重构，5 - 20 分钟起步
- Codex 挂个 CI 修复任务，40 分钟经常
- 本地 Ollama 跑 30B 模型，一次 chat 五分钟
这段时间站在电脑前太累，走开又心不安。核心问题不是"跑得慢"，是"没有反馈闭环"。手机是天然的中断源——微信、短信、闹钟，你不会漏。把 IDE 的完成事件塞进这个通道，就把 AI 编程从"守着屏幕的手工业"拉回"任务派发式协作"。
WinToastRelay 提供的就是这段最后一公里。
WinToastRelay 到底怎么工作？
底层三行字讲清楚：
Windows.UI.Notifications.Management.UserNotificationListener
.NotificationChanged -> 队列 -> HTTP POST (Bark/WxPusher/Webhook)
它是 UWP 层的 API，从 Windows 10 就有。启动时先枚举一次通知中心当基线，之后每收到一个 NotificationAdded 事件就单独处理一条，通过通知 ID 去重。没有定时器、没有轮询、也没装钩子驱动，所以杀软和管理员权限都不需要——但 Windows 会弹一个"允许访问通知"的授权框，走的是标准 RequestAccessAsync 流程。
发送这一端有个持久化本地队列，遇到网络抖动或者接收端返回 5xx 会指数退避重试。对于自建 Bark / ntfy 这种偶尔要维护的场景很实用，重启电脑后队列不丢。
Bark、WxPusher、Webhook、ntfy 到底选哪个？
看你手机是哪家：
| 接收端 | 支持系统 | 部署难度 | 后台耗电 | 是否需自建 | 适合谁 |
|---|---|---|---|---|---|
| Bark | iOS | 零 | 极低（走 APNs） | 可选（推荐自建） | iPhone 用户第一选择 |
| WxPusher | iOS + Android | 零 | 低（走厂商 push） | 否 | Android 用户第一选择 |
| ntfy | iOS + Android | 中等（Docker） | 中 | 是 | 洁癖党，全链路自控 |
| Webhook | 任意 | 高 | 看下游 | 是 | 想接钉钉 / 飞书 / 企业微信 |
我自己 iPhone + Bark 自建服务器（跑在飞牛 NAS 上一个 docker 容器 finab/bark-server），全程走 HTTPS，不经过第三方服务器。设备唯一码就是那串 Xy4ssdd2pARjLfFY，一定要保管好，泄露等于让别人给你发骚扰推送。
Android 别追求 ntfy 的自托管情结——国产手机没有 FCM，后台被杀是家常便饭，反而 WxPusher 走厂商通道更靠谱。
我实测下来的账本
放一天下来的真实数据：
- 驻留内存：14 - 18 MB，比 QQ 音乐一个音符还小
- CPU 占用：静置 0%，触发瞬间峰值 0.3%
- 端到端延迟：Windows toast 触发 → iPhone 弹推送，1.2 - 1.8 秒（自建 Bark 服务器，家宽千兆）
- 中转成功率：24 小时挂机 143 条通知，0 丢失（本地队列保底）
- 接收端流量：单条 payload 约 400 B，一天 143 条 ≈ 60 KB
对比之前用 Tampermonkey 脚本轮询 Codex 网页（30 秒一次），CPU 占用降了 3 倍，延迟从平均 22 秒降到 1.5 秒，还顺带解决了 Claude Code / Docker Desktop 这些 Codex 网页之外的通知。
配置只有五步
第一步先装：微软商店搜 WinToastRelay，或者 GitHub Release 下 MSIX。
第二步给权限：Windows 会弹"允许 WinToastRelay 访问通知"，一定要给，不然它啥也监听不到。
第三步选接收端。以 Bark 为例：手机装 Bark，注册设备，复制那串带你设备码的 URL（https://api.day.app/xxxx/）。在 WinToastRelay 里"目标" → Bark → 粘贴 URL → 保存。密钥自动进 Credential Manager，不会明文写到设置文件里。
第四步做应用过滤。默认它把所有系统通知全转，Teams 一响你手机就震——太吵。在 “Application Filters” 里关掉不感兴趣的 App，只留 Codex、Claude Code、Cursor、GitHub Desktop 这些真正需要盯的。
第五步开机自启。在设置里勾"Start with Windows"，走的是 UWP 标准 startup-task API，不写注册表，卸载干净。
有没有踩到坑？
两个。
**坑一：Codex 在前台不发通知。**Codex Windows 版默认只在窗口失焦时才弹系统通知，前台会静默。解法在 Codex 设置里把 “Always show notifications” 打开，不然 WinToastRelay 监听不到任何事件。
坑二：授权撤回后不重启不生效。如果你在 Windows 通知设置里手动关过 WinToastRelay 的访问权限，再打开时它会显示"已授权"但没在监听。必须完全退出（托盘图标右键 → Exit）再重开一次，RequestAccessAsync 才会重走。
常见问题
Q1: 会不会把我微信、企业微信里的敏感通知都发到手机上？
A: 默认会，但可以在 Application Filters 里精细屏蔽。我个人的做法是白名单模式：只放行 Codex、Claude Code、GitHub Desktop 这三四个，其它全关。
Q2: Bark 官方 API api.day.app 免费吗？
A: 免费，但推送内容会经过作者的服务器（作者承诺不留档但没有法律约束力）。敏感信息建议自建 finab/bark-server，一条 docker 命令 30 秒起。
Q3: 支持 Windows 10 吗？
A: 支持。它用的 UserNotificationListener API 从 Windows 10 1607 就有，理论上 21H2 之前都能跑。开发者官方描述是"Windows 10/11 native app"。
Q4: WxPusher 是不是要关注一个公众号？
A: 是。Android 免费但要关注一次 WxPusher 公众号绑定设备。不喜欢就选 ntfy 自托管。
Q5: 会不会占用大量电池？
A: 事件驱动 + 系统 API，不轮询。开发者的话是"确保电脑有至少 20 MB 可用内存"就够了。我实测 24 小时驻留没看到 CPU 尖峰。
Q6: 转发失败会重试吗？
A: 会。本地队列 + 指数退避，5xx 和网络错误都会重排。JSON 设置文件里可以调最大重试次数和退避上限。
Q7: 能不能加密 payload？
A: HTTPS 层足够对付路径中的中间人。Bark 自带 ciphertext 参数支持端到端 AES 加密，WinToastRelay 目前用 Webhook 模式可以自己在下游解密，Bark 原生模式暂未做透传，得看后续版本。
我为什么推荐给每个用 AI Coder 的人
不是因为它有多惊艳——通知转发这件事在 iOS 上早有 Pushover、Simplepush，Android 有 Gotify——WinToastRelay 特殊的地方在于它把 Windows 端做扎实：原生 API、系统托盘、开机自启、Credential Manager、本地队列、应用过滤、MSIX 打包，六件套里没有一件是拼装的。你把它塞进 Codex / Claude Code 工作流后，会发现自己走开的次数明显变多了。这才是真的解放。