Hermes 的 Codex App-Server Runtime：把 Codex 的本地运行时接进 Hermes

Hermes Agent 的 Codex App-Server Runtime，本质上是一个可选的运行时切换功能。开启以后，Hermes 在处理 openai/* 和 openai-codex/* 这类回合时，不再用自己原本的工具循环来执行终端命令、文件编辑和补丁操作，而是把这一回合交给 codex app-server。Codex 负责实际的命令执行、文件修改、沙箱、审批和原生插件；Hermes 则继续保留外层能力：会话、斜杠命令、网关、记忆与技能复盘、kanban/cron 工作流，以及一部分通过 MCP 回调暴露给 Codex 的高级工具。

换句话说，它不是“用 Codex 替代 Hermes”，而是让 Hermes 在 OpenAI/Codex 模型场景下，把执行层交给 Codex，同时继续做长期工作台。

这个功能是干什么的

官方文档明确说明：这是一个只在用户主动开启后才生效的功能。默认情况下，Hermes 的行为不变。开启后，模型可以同时看到三类工具来源：

• Codex 自带工具：shell 用于终端、读写文件、搜索文件和运行测试；apply_patch 用于结构化多文件修改；update_plan 用于任务规划；view_image 用于查看本地图片；以及 Codex 自身配置好的 web_search。
• Codex 原生插件：已经通过 Codex 安装和授权的插件，例如 GitHub、Linear、Gmail、Google Calendar、Outlook、Canva 等，可以被 Hermes 发现并写入 Codex 配置，在 Hermes 会话中继续使用。
• Hermes 工具回调：Hermes 会把自己注册成一个 MCP server，Codex 可以通过回调调用 Hermes 里 Codex 不自带的工具，例如网页抽取、浏览器自动化、视觉分析、图片生成、技能读取和文本转语音。

因此，一个代码修改任务在开启该运行时后，执行链路会变成：Codex 用自己的 app-server 协议和沙箱完成 shell 或 patch 操作，Hermes 再把 Codex 的事件投影回自己的会话结构中，方便记录、展示和后续复盘。

它是怎么实现的

OpenAI 的 Codex app-server 文档说明，codex app-server 使用类似 JSON-RPC 的协议，可以通过 stdio、websocket 或 unix socket 通信。Hermes 当前走的是 stdio：启动或复用一个 Codex app-server 子进程，完成 initialize 握手，创建或恢复 thread，启动 turn，然后持续读取 item/* 和 turn/* 事件，直到这一回合完成。

Hermes 源码里的 agent/codex_runtime.py 也能看到这个核心设计：run_codex_app_server_turn 把完整回合交给 Codex 子进程执行，再把 Codex 返回的事件转成 Hermes 自己的消息列表。这个“投影”很关键，因为 Hermes 的 session 数据库、记忆复盘、技能复盘，都依赖类似普通工具调用的会话记录。

开启运行时时，Hermes 还会迁移配置：把 Hermes 里的 MCP server 转成 Codex 需要的 TOML 格式，写入 ~/.codex/config.toml 的 managed block；注册 Hermes 工具回调；并设置 default_permissions = ":workspace"，让工作区内的常规写入不至于每一步都弹审批。managed block 之外的用户配置会被保留。

初衷与逻辑

这个功能的初衷很现实：很多开发者同时在用 Hermes 和 Codex CLI。Hermes 强在长期智能体外壳、多平台网关、记忆、技能、任务调度和工具扩展；Codex CLI 强在 OpenAI 代码工作流里的本地执行层、ChatGPT 订阅认证、沙箱、patch、插件和 app-server 事件模型。用户不想每次做任务都在两套系统之间来回切换。

引入该功能的 GitHub PR 把它描述为一个“可选运行时”：OpenAI/Codex 模型可以走 Codex app-server，但默认行为不变。原因也很清楚：Hermes 是 provider-agnostic 的，不只服务 OpenAI；它自己的工具分发路径也有大量测试覆盖。最稳妥的逻辑，就是不破坏默认路径，同时给 Codex 重度用户一个更贴近 Codex 原生能力的执行层。

需求背景

这个功能背后的需求，来自真实的日常开发场景：

• 想使用 ChatGPT 订阅能力。OpenAI Codex README 建议用户使用 ChatGPT 登录，这样 Plus、Pro、Business、Edu、Enterprise 等计划可以用于 Codex。Hermes 接入 Codex app-server 后，OpenAI/Codex 回合可以走这条认证路径。
• 想要 Codex 的本地沙箱和 patch 能力。Codex app-server 暴露 thread、turn、item、sandbox、approval、command execution、MCP 和 plugin 等接口。Hermes 不需要重新实现所有 Codex 特性，而是把 Codex 当作执行层。
• 想保留 Hermes 的统一入口。很多人把 Hermes 放在终端、Feishu、Telegram 或其他网关里长期使用。这个运行时让同一个 Hermes 入口可以调用 Codex 的代码执行能力，而不用离开原来的会话和工作流。
• 想复用已经授权过的 Codex 插件。如果 GitHub、Linear、Calendar 等插件已经在 Codex 中安装和授权，Hermes 可以通过 Codex 的 plugin/list RPC 发现并启用，不必重复配置。

开发者如何开启

先安装并登录 Codex CLI：

npm i -g @openai/codex
codex --version
codex login

Hermes 官方文档中提到的最低示例是 Codex CLI 0.130.0 或更新版本；2026-05-20 查询 npm 元数据显示，@openai/codex 的 latest 版本为 0.132.0。完成 Codex 登录后，在 Hermes 会话里执行：

/codex-runtime codex_app_server

常用命令还有：

/codex-runtime        # 查看当前状态
/codex-runtime auto   # 回到 Hermes 默认运行时
/codex-runtime on     # codex_app_server 的同义命令
/codex-runtime off    # auto 的同义命令

也可以直接改 ~/.hermes/config.yaml：

model:
  openai_runtime: codex_app_server

切换会在下一次会话生效。这不是缺陷，而是为了避免在同一个缓存会话中途切换工具运行时，导致上下文和工具结构不稳定。

日常应该怎么用

假设你在一个项目里遇到测试失败，可以直接对 Hermes 说：

修复 checkout 测试失败的问题，顺便查看相关 GitHub issue，最后留下简短变更说明。

开启 Codex runtime 后，Codex 可以用 shell 跑测试、读文件、搜索代码；用 apply_patch 做多文件修改；如果 GitHub 插件已经安装和授权，它可以通过 Codex 插件查看 issue 或 PR；如果需要浏览器复现，它还能通过 MCP 回调调用 Hermes 的浏览器自动化。Hermes 则继续负责会话、网关、斜杠命令和长期复盘。

再比如你在 Feishu 或 Telegram 里远程驱动开发：让 Hermes 查看 Linear 任务、修改本地仓库、跑测试并汇报结果。真正的代码执行由 Codex 完成，Hermes 仍然是消息入口和工作流外壳。这种组合的便利在于：你不需要为了使用 Codex 插件和沙箱而离开 Hermes，也不需要为了使用 Hermes 的网关和记忆而放弃 Codex 的执行层。

适用场景

• OpenAI/Codex 重度代码开发：已经习惯让 Codex CLI 本地读写文件、跑测试、应用 patch 的项目。
• 订阅认证优先：希望通过 ChatGPT 计划使用 Codex，而不是每个代码回合都走单独 API key 的用户。
• 插件联动工作流：任务同时涉及代码、GitHub、Linear、Gmail、Calendar 或设计工具。
• 聊天网关中的开发任务：通过 Feishu、Telegram 等渠道驱动真实本地代码修改，同时保留 Hermes 的会话和命令体系。
• Kanban worker 分发：官方文档说明 kanban worker 可以运行在 Codex runtime 上，并通过 MCP 回调暴露完成、阻塞、评论和心跳等工具，让 worker 能回写任务板。

不适合什么场景

它不是 Hermes 默认运行时的完全替代品。官方文档明确列出，有四类 Hermes 工具在该运行时不可用：delegate_task、memory、session_search、Hermes 的 todo。原因是这些工具需要当前 AIAgent 循环里的上下文，而一个无状态的 MCP 回调无法驱动它们。Codex 有自己的 update_plan，但那不是 Hermes 的 todo store。

如果你的任务依赖子代理、跨会话搜索、直接写入 Hermes 记忆，或者需要 Hermes 自己的 todo 存储，就应该切回默认运行时：

/codex-runtime auto

Cron 任务也要谨慎。官方文档说它应当遵循相同的工具可用性规则，但该文档没有把 cron 标为已专门测试。如果无人值守任务依赖 Hermes-only 的 agent-loop 工具，最好用默认运行时的 profile。

审批与安全

Codex 在执行命令或应用 patch 前可能请求审批。Hermes 会把这些请求转成自己标准的危险命令提示：允许一次、允许本会话、拒绝。Codex 的权限 profile 仍然有效。Hermes 在开启该运行时时默认使用 workspace 权限，让工作区内写入更顺畅，同时保留沙箱边界。Codex 也有 read-only 和 no-sandbox 选项；后者不应该随意使用。

一句话总结

Codex App-Server Runtime 的核心价值，是把 Hermes 的长期智能体外壳和 Codex 的本地执行层接起来：Hermes 继续做统一入口、会话和工作流，Codex 则在 OpenAI/Codex 场景下负责更原生的命令、patch、插件、沙箱和 ChatGPT 认证。

资料来源

• Hermes Agent 官方文档：Codex App-Server Runtime
• NousResearch/hermes-agent PR #24182
• OpenAI Codex app-server 协议 README
• OpenAI Codex GitHub 仓库
• @openai/codex npm 包