Push9 的 Codex Runner 实现方案，解决了本地 Codex CLI 长时间代码任务的痛点，支持网页端下发指令、本机后台跑任务、任务完成推送通知，并且用户点开通知之后，可以直接接续原来的会话继续下发指令，不用重新复制上下文，整套架构把任务执行链路和消息通知链路做了解耦，依靠幂等领取、本地会话快照、独立通知队列、会话 ID 定向恢复这几个核心机制保证稳定，就算中途网络断线、推送投递失败，也不会出现重复执行代码、误改项目文件这类风险，整套方案不需要本机暴露公网端口，Runner 客户端主动向外拉取任务，同时做沙箱权限隔离，只开放预先登记好的项目目录，兼顾易用性和安全性。下面从角色分工、初始化流程、任务流转、会话恢复、异常处理、故障排查清单完整拆开说明。
一、整套架构四大角色
| 角色 | 职责说明 |
|---|---|
| 网页控制台 | 选择设备、项目，提交自然语言指令，查看任务摘要、打开通知继续会话 |
| 后端服务 | 持久化任务、校验账号与设备权限、维护任务状态、接收结果回传、调度通知队列 |
| Codex Runner（Go 客户端） | 常驻本机，主动拉取任务，调用本地 Codex CLI，监听执行事件，回传结构化摘要 |
| 消息通知 Topic | 独立通道，只推送任务结果摘要，通知链路失败不会影响主任务状态 |
重点区分：推送通知只是附加能力，就算不配置消息 Topic，整套任务下发、执行、结果查看流程照样可以跑；推送 Token 本身没有远程执行任务的权限，不能单独用来下发代码指令。
二、本机初始化绑定步骤
- 在网页端新建一台 Runner 设备，拿到一次性绑定码，绑定码有效期 10 分钟，只能使用一次。
- 在本地电脑运行 Push9 Runner 程序，输入绑定码完成设备登记，同时录入允许访问的项目目录。
- 配置沙箱模式，只有两种可选：read-only 只读模式、workspace-write 允许修改工作区文件。
- 本机单独安装并登录 Codex CLI，Runner 只是调用子进程，内部不封装模型能力。
示例配置命令：
.\push9-runner.exe setup --server https://push9.top --project "D:\work\example-project" --sandbox read-only
三、任务下发、领取、执行的幂等机制
网页提交任务接口
提交任务时带上 requestKey，作为幂等标识，网络超时重试时使用同一个 key，后端不会重复新建任务。
POST /api/runner-tasks
Authorization: Bearer
{
"runnerId": "",
"projectId": "",
"prompt": "只读取项目并介绍目录结构，不修改文件。",
"requestKey": "随机字符串"
}
Runner 领取任务幂等
Runner 本地先生成 claimId 写入本地日志，再去后端申领任务；领取响应丢包时复用同一个 claimId，后端依靠设备锁、租约机制保证一台设备同一时间只跑一个任务。
Codex 子进程事件监听
Runner 不是直接抓取终端文本，而是监听 Codex JSONL 结构化事件，用来更新任务状态：
| 事件 | Runner 动作 |
|---|---|
| thread.started | 记录本次会话唯一 sessionId |
| agent_message 类型 item.completed | 截取摘要，上限 4000 字符 |
| turn.completed | 标记本轮执行完成 |
| turn.failed / error | 标记失败，必要时等待本机人工确认 |
Runner 通过 stdin 传入指令，不会拼接字符串直接跑 shell，规避注入风险。如果 Codex 需要人工审批，任务状态标记为 WAITING_CONFIRMATION，需要回到本机操作。
四、断线恢复逻辑：区分 “没跑” 和 “跑完没回包”
Runner 在本地维护三段状态日志，用来防止重复执行：
- claim：已经拿到任务，但还没启动 Codex；
- executing：Codex 已经开始跑；
- report：执行结束，正在上传结果。
- 如果已经跑完、上传结果时断网：重启后继续回传结果，不会重跑；
- 如果停留在 executing：上报 INTERRUPTED，不会自动重试，让人工核对本地文件改动；
- 不提供严格 “恰好一次” 的外部副作用保障，文件修改、接口调用一旦执行，无法自动回滚。
五、通知投递与会话接续核心逻辑
任务在后端标记为 COMPLETED 之后，才进入独立的通知发件箱，通知状态单独维护：
- 任务 COMPLETED、通知 FAILED：任务结果已经保存，只排查推送渠道，不重跑 Codex；
- 通知成功投递，仅代表消息平台接收，不等于用户已经看到；
- 通知里附带会话入口，调用接口基于 messageId 继续任务。
继续会话接口：
POST /api/runner-tasks/from-message/{messageId}
Authorization: Bearer
X-Message-Key:
{"prompt":"继续检查测试入口，先说明计划，不修改文件。"}
会话恢复有硬性约束：
- 依靠原始 sessionId 执行 exec resume，不会自动匹配最近会话；
- 本机必须保留原会话文件、相同系统用户、项目目录和 Codex 环境；
- 一条通知只能提交一次续跑指令；续跑任务完成，才会生成新一轮通知入口；
- 同时校验账号登录权限 + 消息查看密钥，只持有分享链接无法下发指令。
六、常见故障排查清单
| 故障现象 | 优先排查项 |
|---|---|
| 网页任务一直排队 | Runner 是否常驻运行、设备在线状态、项目目录是否登记启用 |
| 提示等待本机确认 | Codex CLI 是否安装、登录完成，是否触发审批弹窗 |
| 任务完成收不到推送 | 是否绑定通知 Topic、通知队列重试记录、消息渠道投递回执 |
| 无法继续会话 | 本机 session 文件、CODEX_HOME、项目路径、登录用户是否和原始任务一致 |
| Runner 重启显示中断 | 优先核对本地代码文件变更，不要直接重发原任务 |
同时明确这套方案的边界：Runner 需要保持后台运行，不自带开机自启；云端只存摘要，不会同步完整本地会话日志，也没有网页端远程审批、实时终端功能。
【相关 FAQ】
问题 1：Push9 Codex Runner 消息通知和继续会话的实现，推送通知本身能不能直接下发代码任务？
回答 1：Push9 Codex Runner 消息通知和继续会话的实现里，通知 Topic 只负责推送结果摘要，推送 Token 没有执行权限，不能单独用来下发任务；想要继续会话，需要账号登录搭配消息查看密钥，通过专门接口创建接续任务。
问题 2：Push9 Codex Runner 消息通知和继续会话的实现，断线之后会不会自动重复执行 Codex 任务？
回答 2：Push9 Codex Runner 消息通知和继续会话的实现设计了三段本地状态日志，如果已经进入 executing 阶段中断，只会标记中断，不会自动重跑；只有结果上传失败的场景，才会重试回传结果，不会重新启动 Codex。
问题 3：Push9 Codex Runner 消息通知和继续会话的实现，继续会话是不是只要点链接就能恢复上下文？
回答 3：不是，Push9 Codex Runner 消息通知和继续会话的实现依靠固定 sessionId 调用 resume，除了前端入口，本机还必须保留原始会话文件、项目目录、Codex 运行环境，环境变动就无法接续会话。
问题 4：Push9 Codex Runner 消息通知和继续会话的实现，本机是否需要开放公网端口？
回答 4：不需要，Push9 Codex Runner 消息通知和继续会话的实现采用客户端主动出站拉取任务，本机不用监听公网入站端口，降低暴露风险，任务调度由客户端主动向服务端申领。
问题 5：Push9 Codex Runner 消息通知和继续会话的实现，沙箱模式有哪几种？
回答 5：Push9 Codex Runner 消息通知和继续会话的实现只提供两种沙箱：read-only 只读模式，只能读取项目；workspace-write 模式，允许修改登记好的工作区文件，不能随意访问本机其他目录。
【参考资料】
[2026-11-13]（从消息通知到继续会话：Push9 的 Codex Runner 实现）阿里云开发者社区
[2026-11-13]（从消息通知到继续会话：Push9 的 Codex Runner 实现）腾讯云开发者社区
[2026-11-13]（Push9 Runner 官方接入文档）push9.top
[2026-02-04]（解锁 Codex 的运作机制：我们如何打造 App Server）OpenAI
【免责声明】
本文为 Push9 Codex Runner 公开技术文章资讯整理，不构成生产环境落地、安全部署建议；该方案基于当前 Runner 0.6.0 版本实现，后续版本接口、状态逻辑、权限规则可能变更；Codex 本地执行代码存在文件修改、命令执行风险，沙箱策略、设备绑定、通知权限需要开发者自行加固；所有接口、执行逻辑以 Push9 官方文档和源码为准。
本文来自作者[晶链广播]投稿，不代表环球科技潮立场，如若转载，请注明出处：https://www.zennew.com/rgzn/202611/1128.html
评论列表（4条）
我是环球科技潮的签约作者“晶链广播”！
希望本篇文章《Push9 Codex Runner 实现方案打通消息通知到会话续跑能力》能对你有所帮助！
本站[环球科技潮]内容主要涵盖：科技,科技新闻,黑科技
本文概览：Push9 的 Codex Runner 实现方案，解决了本地 Codex CLI 长时间代码任务的痛点，支持网页端下发指令、本机后台跑任务、任务完成推送通知，并且用户点开通知之后，可以直接接续原来的会话继续下发指令，不用重新复制上下文，整套架构把任务执行链路和消息通知链路做了解耦，依靠幂等领取、本地会话快照、独立通知队列、会话 ID 定向恢复这几个核心机制保证稳定，就算中途网络断线、推送投递失败，也不会出现重复执行代码、误改项目文件这类风险，整套方案不需要本机暴露公网端口，Runner 客户端主动向外拉取任务，同时做沙箱权限隔离，只开放预先登记好的项目目录，兼顾易用性和安全性。下面从角色分工、初始化流程、任务流转、会话恢复、异常处理、故障排查清单完整拆开说明。