把 Hermes 装进 Codex：社区扩展让两个 Agent 共用一扇窗

你的白天大概是这样过的：在 Codex 里改一个模块，改到一半想起「上次 Hermes 那个定时任务今天跑没跑」「昨天那个会话它到底读了哪些文件」，于是切回终端敲 hermes --continue，或者干脆开第二个窗口。两个 Agent、两套界面、两份上下文，来回切的时候，最容易丢掉的就是你正想接着问的那句话。

社区项目 hermes-chatgpt-extension 想解决的就是这个来回切的问题：它把 Hermes 作为一个嵌入面板放进 Codex（以及 ChatGPT 的 Codex 桌面端）里——聊天、profile、模型选择、定时任务都能在 Codex 的侧栏里看和用。

它是什么，不是什么

它是一个 MCP 插件：在本地跑一个 stdio MCP server（桥接进程），把 Hermes 的桌面 JSON-RPC/WebSocket 接口和 REST 管理接口包成 Codex 能识别的插件界面。项目用 TypeScript 写的，MIT 许可，9 月 30 日建仓，10 月 1 日还在更新。

这里要划清三条边界，免得你期待错方向：

  • 它不是把 Hermes 变成 Codex 的一个工具。 界面遵循 Codex 的聊天与侧栏惯例，但 Hermes 照旧自己跑它的 agent、工具、记忆和调度器；外面那层 Codex 对话和 Hermes 的会话是分开的。
  • 它不提供托管 MCP 端点。 包里的 server 是本地 stdio 的，所以这是「在 Codex 桌面端里用 Hermes」，不是「在 ChatGPT 云端访问你的 Hermes」。
  • 它不接管你的凭据。 上游 provider 的凭据留在本地桥接进程里，嵌进去的界面拿到的是连接标签和聊天数据，而不是 token 或 API Key。

装：两种方式，都只要 Node 22+

前置条件有三条：Node.js 22 或更高（Codex 要能在 PATH 里找到 node）、一个支持本地插件与 MCP Apps 的 Codex 桌面版本、以及一个已经装好并配置过的 Hermes 后端（需要桌面 JSON-RPC/WebSocket API 与 REST 管理路由）。

用官方预编译 ZIP（不需要 npm install / build）：

# 从 releases 页下载 hermes-chatgpt-extension-VERSION.zip 并解压
cd <解压后的目录>
node scripts/verify-plugin.mjs

ZIP 里已经带了编译好的 server 和自包含 UI，同时还提供 -source.zip 和 SHA256SUMS，可以校验两个包。注意 GitHub 自动生成的 Source code 压缩包是需要自己 build 的源码，不是这个预编译包。

从源码构建：

git clone https://github.com/intellectronica/hermes-chatgpt-extension.git
cd hermes-chatgpt-extension
npm ci
npm run build
node scripts/verify-plugin.mjs

然后走安装脚本注册进 Codex 的本地 marketplace：

node scripts/install-plugin.mjs

它会把这个插件复制到 ~/.codex/plugins/hermes-chatgpt-extension，并在 ~/.agents/plugins/marketplace.json 里加一条记录（保留已有的 marketplace 名字和其他条目）。装完在 Codex 里打开插件详情页点 Enable——脚本本身不会替你启用，也不会重启 Codex。更新时用 --replace --dry-run 先看一遍，再 --replace --apply。

配：一个 connections 数组，四种接法

配置文件放在插件目录外面（这样更新不会冲掉它），默认路径是 ~/.config/hermes-chatgpt-extension/hermes.config.json：

mkdir -p "$HOME/.config/hermes-chatgpt-extension"
cp examples/config.ssh.json "$HOME/.config/hermes-chatgpt-extension/hermes.config.json"

配置的读取顺序是：--config 参数 → HERMES_EXTENSION_CONFIG 环境变量 → 桥接进程工作目录下的 hermes.config.json → $XDG_CONFIG_HOME/hermes-chatgpt-extension/hermes.config.json（或 ~/.config/...）。有个值得注意的设计：指定的配置文件缺失或格式错误会直接报错，而不是悄悄跳过——这样你不会以为自己连上了某个 profile，其实连的是另一个。

一个 connections 数组可以同时放多个 Hermes 实例，界面底部的选择器负责切换。支持四种连接方式：

模式 适用场景 关键字段
Managed SSH Hermes 装在远端，让扩展自己拉一个临时后端 ssh.mode: "managed"、ssh.host
Attach over SSH 远端已经有一个跑着的兼容后端，只连上去 ssh.mode: "attach"、remotePort、tokenFile
HTTP 兼容的 hermes serve 桌面后端 baseUrl、tokenEnv
HTTPS 公网/反向代理后的网关 同上，远端必须走 HTTPS

Managed SSH 模式会自己起一个带 token 保护的 loopback 后端（随机端口）并接管这条 SSH 隧道，桥接关闭时后端一起退出；它用的是你已有的 Hermes 安装，不装软件、不改 profile、不重启服务。也正因为凭据是它自己生成的，这个模式不允许你指定 tokenEnv、tokenFile、remoteHost、remotePort。

Attach 和 HTTP/HTTPS 模式各需要恰好一个凭据来源：tokenEnv（环境变量名）或 tokenFile（一个本地小文件）。POSIX 上这个文件必须属于当前用户且只有本人可读：

chmod 600 /path/to/hermes.token

这里有个常踩的坑值得单独说：桌面应用不一定继承你在交互 shell 里 export 的环境变量。 如果插件是由 Codex 拉起来的，tokenEnv 很可能读不到值——用一个权限收紧的 tokenFile 更稳。另外，远端 URL 必须 HTTPS，明文 HTTP 只接受 loopback 主机（如 http://127.0.0.1:9119）。

能做什么

装好并启用后，在 Codex 里打开 Explore → Hermes：

  • 聊天：流式回复、Markdown 与代码渲染、工具活动可见，支持 Stop、审批（approvals）和澄清问题（clarification）；
  • 按 profile 分组：每个连接下的会话按 profile 折叠分组，草稿跟着它所属的实例和 profile 走，不会串台；
  • 模型与推理档位：用的是每个 profile 真实的模型目录和默认值，带模型选择器和 Power 控件（对应推理强度）；
  • 调度视图：按单个 profile 或全部 profile 查看定时任务与已记录的运行，排程时间、执行状态、投递状态分开显示——这一点比只给一个「成功/失败」有用得多；
  • 归档：走 Hermes 自己的归档，并给一个短暂的 Undo，归档保留已存的消息。

默认情况下 Hermes 标记为自动化的会话是藏起来的，想看得在配置里加 "sidebar": { "showAutomatedChats": true }；Hermes 自己的子 agent 可见性设置仍然生效。

什么时候适合用

如果你的工作流是「Codex 写代码 + Hermes 管自动化」，这个扩展省掉的是窗口切换和上下文丢失，代价是你要接受一个本地 marketplace 安装的第三方 MCP 插件——所以请按对待任何本地插件的方式对待它：读一遍安装脚本，把配置和 token 文件放在源码管理和分发包之外，远端连接一律走 HTTPS 或 SSH。

还在纠结远程 OAuth 怎么过的问题，可以先看OAuth over SSH 那篇；想把 Hermes 的会话和调度数据摸清楚，成本追踪指南和定时任务时区与夏令时是两份好补充。对 MCP 侧的机制，MCP 服务器接入指南更系统。

小结

把两个 Agent 放进同一扇窗，真正的价值不是省一次切换，而是让你在写代码的当下就能看到自动化那一侧的实况：任务跑了没、会话里发生了什么、这个 profile 用的哪个模型。这个扩展做的是接线，不是重造——它没有替你改 Hermes 的行为，只是把已经存在的接口搬到 Codex 眼前。对多实例、多 profile 的用户，它把「我到底连的是谁」这件事也一并显式化了：每个连接一条、每个 profile 一组，看得见的隔离比记忆里的约定可靠。