Codex App-Server 運行時
Hermes 可以選擇將 openai/* 和 openai-codex/* 的輪次交給 Codex CLI app-server 處理,而不是運行其自身的工具循環。啟用後,終端命令、文件編輯、沙箱隔離以及 MCP 工具調用均在 Codex 的運行時內執行——Hermes 成為其外殼(會話數據庫、斜槓命令、網關、記憶和技能審查)。
這僅作為可選功能。除非你切換該標誌,否則默認的 Hermes 行為保持不變。Hermes 絕不會自動將你路由到此運行時。
不使用 OpenAI Codex?hermes setup --portal 可一步配置使用 Claude/Gemini 等的非 Codex 後端。請參閱 Nous Portal。
原因
- 使用與 Codex CLI 相同的認證流程,針對你的 ChatGPT 訂閱運行 OpenAI agent 輪次(無需 API 密鑰)。
- 使用 Codex 自身的工具集和沙箱——用於終端讀取/寫入/搜索的
shell,用於結構化編輯的apply_patch,用於規劃的update_plan,所有操作均在 seatbelt/landlock 沙箱隔離中運行。 - 原生 Codex 插件——Linear、GitHub、Gmail、Calendar、Canva 等——通過
codex plugin安裝的插件會自動遷移並在你的 Hermes 會話中激活。 - Hermes 更豐富的工具隨之可用——web_search、web_extract、瀏覽器自動化、視覺、圖像生成、技能和 TTS 通過 MCP 回調工作。對於沒有內置的工具,Codex 會回調 Hermes。
- 記憶和技能提示繼續有效——Codex 的事件被投影到 Hermes 的消息結構中,因此自我改進循環看到的是看起來正常的轉錄內容。
模型實際擁有的工具
這是大多數用戶希望 upfront 瞭解的部分。當此運行時開啟時,運行你輪次的模型擁有三個獨立的工具來源:
1. Codex 的內置工具集(始終開啟)
這些隨 codex app-server 本身提供——無需 Hermes 參與,無需 MCP,無需插件。一旦運行時啟動,所有五個工具即可用:
shell——在沙箱內運行任意 shell 命令。模型通過此方式讀取文件(cat、head、tail)、寫入文件(echo > foo、heredocs)、搜索文件(find、rg、grep)、導航目錄(ls、cd)、運行構建、管理進程以及你在 bash 中會做的任何其他事情。apply_patch——以 Codex 的補丁格式應用結構化的多文件差異。模型使用此工具進行非平凡的代碼編輯(添加函數、跨文件重構);對於一次性寫入,shell heredocs 仍然可用。update_plan——codex 內部的 todo / 計劃跟蹤器。相當於 Hermes 的todo工具,但完全在 codex 的運行時內部管理。view_image——將本地圖片文件加載到對話中,以便模型查看。web_search——配置後,codex 擁有自己的內置網絡搜索。Hermes 還通過下面的回調暴露web_search(基於 Firecrawl);模型會選擇它偏好的任何一個。
因此,任何你通過終端做的事情——讀取/寫入/搜索/查找/運行——codex 都能原生完成。沙箱配置文件(啟用運行時後默認為 :workspace)控制可寫權限。
2. 原生 Codex 插件(從你的 codex plugin 安裝自動遷移)
當你啟用運行時,Hermes 會查詢 codex 的 plugin/list RPC,併為你安裝的每個插件寫入一個 [plugins."<name>@openai-curated"] 條目。插件本身由 codex 管理,並通過 codex 自身的 UI 進行一次授權。
示例(OpenClaw 線程中強調為“值得 YouTube 視頻展示”的那些):
- Linear——查找/更新問題
- GitHub——搜索代碼、查看 PR、評論
- Gmail——讀取/發送郵件
- Google Calendar——創建/查找事件
- Outlook calendar/email——通過 Microsoft 連接器實現相同功能
- Canva——設計生成
- ...以及其他任何你通過
codex plugin marketplace add openai-curated+codex plugin install ...安裝的內容
未遷移的內容:
- 你尚未安裝的插件——請先在 Codex 中安裝它們。
- ChatGPT 應用市場條目(
app/list)——由於你的賬戶認證,這些已在 codex 內部啟用。
3. Hermes 工具回調(MCP 服務器,在 ~/.codex/config.toml 中註冊)
Hermes 將自身註冊為 MCP 服務器,以便 codex 可以回調獲取 codex 未提供的工具。通過回調可用:
web_search/web_extract——基於 Firecrawl;對於結構化內容,往往比抓取更乾淨。browser_navigate/browser_click/browser_type/browser_press/browser_snapshot/browser_scroll/browser_back/browser_get_images/browser_console/browser_vision——通過 Camofox 或 Browserbase 實現完整的瀏覽器自動化。vision_analyze——調用單獨的視覺模型來檢查圖像(不同於 codex 的view_image,後者將其加載到對話中)。image_generate——通過 Hermes 的 image_gen 插件鏈進行圖像生成。skill_view/skills_list——從 Hermes 的技能庫中讀取。text_to_speech——通過 Hermes 配置的提供商進行 TTS。
當模型需要其中某項工具時,codex 會通過 stdio MCP 生成 hermes_tools_mcp_server 子進程,調用通過 model_tools.handle_function_call() 分發(與 Hermes 默認運行時相同的代碼路徑),結果像任何其他 MCP 響應一樣返回給 codex。
此運行時不可用的功能
以下四個 Hermes 工具需要正在運行的 AIAgent 上下文(循環中間狀態)才能分發,而無狀態的 MCP 回調無法驅動它們。當你需要使用其中任何一項時,請切換回默認運行時(/codex-runtime auto):
delegate_task— 生成子代理memory— Hermes 的持久化記憶存儲session_search— 跨會話搜索todo— Hermes 的待辦事項存儲(codex 的update_plan是運行時內的等效功能)
工作流功能(/goal、看板、定時任務)
/goal(Ralph 循環)
在此運行時上可用。 目標按會話 ID 鍵值持久存儲在 state_meta 中,續提示詞通過 run_conversation() 作為普通用戶消息反饋回來,codex 原生執行下一輪。目標評判器通過輔助客戶端運行(在 config.yaml 中通過 auxiliary.goal_judge 配置),獨立於當前激活的運行時。如果 codex 在審批上停滯,評判器的“受阻,需要用戶輸入”判定是一個乾淨的退出機制。
需要注意的一點: 每個續提示詞都是一個新的 codex 輪次,這意味著 codex 會從頭重新評估命令審批策略。如果你正在執行一個涉及大量寫入的長期目標,預計會比在單個會話任務中看到更多的審批提示。設置 default_permissions = ":workspace"(當你啟用該運行時,Hermes 會自動執行此操作),這樣簡單的工作區寫入就不需要提示審批。
看板(多代理工作樹分發)
在此運行時上可用,但有一個細微的依賴關係。 看板分發器將每個 worker 生成為單獨的 hermes chat -q 子進程,該進程讀取用戶的配置——這意味著如果全局設置了 model.openai_runtime: codex_app_server,worker 也會在 codex 運行時上啟動。
在 codex 運行時 worker 內部有效的功能:
- Codex 的完整工具集(shell、apply_patch、update_plan、view_image、web_search)—— worker 原生執行其實際任務工作
- 已遷移的 codex 插件——Linear、GitHub 等
- 用於 browser_*、vision、image_gen、skills、TTS 的 Hermes 工具回調
由於 MCP 回調暴露了以下功能,因此也有效:
kanban_complete/kanban_block/kanban_comment/kanban_heartbeat— worker 交接工具。這些工具從環境變量中讀取HERMES_KANBAN_TASK(由分發器設置),正確限制訪問權限,並寫入由HERMES_KANBAN_DB固定的每個看板的 SQLite 數據庫。如果回調中沒有這些工具,此運行時上的 worker 可以執行其任務,但無法報告回傳,導致掛起直到分發器超時。kanban_show/kanban_list— 供 worker 檢查自身上下文的只讀看板查詢。kanban_create/kanban_unblock/kanban_link— 僅限編排器操作。適用於需要在 codex 運行時上運行並分發新任務的編排器代理。
看板工具受分發器設置的環境變量 HERMES_KANBAN_TASK 限制——該變量傳播到 codex 子進程(codex 繼承環境變量),並由此傳播到生成的 hermes-tools MCP 服務器子進程。因此,工具能看到正確的任務 ID 並正確進行權限控制。對於 Codex app-server worker,當存在 HERMES_KANBAN_TASK 時,Hermes 還會傳遞狹窄的 app-server 沙箱覆蓋:保持 workspace-write 沙箱限制,添加看板數據庫目錄以及分發器固定的每個看板路徑作為額外的可寫根目錄(HERMES_KANBAN_WORKSPACES_ROOT、HERMES_KANBAN_WORKSPACE、遺留的 HERMES_KANBAN_ROOT——去重後,數據庫目錄優先),並默認保持網絡禁用。這避免了脆弱的 :danger-no-sandbox 變通方法,同時允許 kanban_complete / kanban_block 更新看板數據庫,並且允許 worker 在位於數據庫目錄之外的工作區掛載點下寫入報告/產物(例如單獨驅動器上的 /media/.../kanban-workspaces/... — issue #27941)。
定時任務 (Cron jobs)
未經過專門測試。 定時任務通過 cronjob → AIAgent.run_conversation 運行,這與 CLI 的代碼路徑相同。如果定時任務的配置中有 openai_runtime: codex_app_server,它將在 codex 上運行。相同的工具可用性規則適用——codex 內置工具 + 插件 + MCP 回調有效,代理循環工具(delegate_task、memory、session_search、todo)無效。如果你的定時任務依賴於這些工具,請將定時任務範圍限定為使用默認運行時的配置文件。
權衡
| Hermes 默認運行時 | Codex app-server(需手動啟用) | |
|---|---|---|
delegate_task 子代理 | 是 | 不可用 — 需要代理循環上下文 |
memory, session_search, todo | 是 | 不可用 — 需要代理循環上下文 |
web_search, web_extract | 是 | 是(通過 MCP 回調) |
| 瀏覽器自動化 (Camofox/Browserbase) | 是 | 是(通過 MCP 回調) |
vision_analyze, image_generate | 是 | 是(通過 MCP 回調) |
skill_view, skills_list | 是 | 是(通過 MCP 回調) |
text_to_speech | 是 | 是(通過 MCP 回調) |
Codex shell(終端/讀/寫/搜索/查找/運行) | — | 是(Codex 內置) |
Codex apply_patch(結構化多文件編輯) | — | 是(Codex 內置) |
Codex update_plan(運行時待辦事項) | — | 是(Codex 內置) |
Codex view_image(將圖像加載到對話中) | — | 是(Codex 內置) |
| Codex 沙箱 (seatbelt/landlock, profiles) | — | 是(Codex 內置) |
| ChatGPT 訂閱認證 | — | 是(通過 openai-codex 提供商) |
| 原生 Codex 插件 (Linear, GitHub 等) | — | 是(自動遷移) |
| 用戶 MCP 服務器 | 是 | 是(自動遷移至 codex) |
| 記憶 + 技能審查(後臺) | 是 | 是(通過項投影) |
| 多輪對話 | 是 | 是 |
/goal (Ralph 循環) | 是 | 是 |
| Kanban 工作器分發 | 是 | 是(通過回調) |
| Kanban 編排器工具 | 是 | 是(通過回調) |
| 所有網關平臺 | 是 | 是 |
| 非 OpenAI 提供商 | 是 | 不適用 — 僅限 OpenAI/Codex 範圍 |
前提條件
-
已安裝 Codex CLI:
npm i -g @openai/codex
codex --version # 0.130.0 or newer -
Codex OAuth 登錄。 codex 子進程讀取
~/.codex/auth.json。有兩種方式填充它:codex login # writes tokens to ~/.codex/auth.jsonHermes 自帶的
hermes auth login codex會寫入~/.hermes/auth.json— 這是一個獨立的會話。如果你尚未操作,請單獨運行codex login。 -
(可選)安裝你想要的 Codex 插件。 當你啟用該運行時,Hermes 會自動遷移你已通過 Codex CLI 安裝的任何精選插件:
codex plugin marketplace add openai-curated
# then via codex's TUI, install Linear / GitHub / Gmail / etc.Hermes 會發現它們並自動將
[plugins."<name>@openai-curated"]條目寫入~/.codex/config.toml。
啟用
在 Hermes 會話中:
/codex-runtime codex_app_server
該命令:
- 驗證
codexCLI 是否已安裝(如果未安裝,則阻止執行並提供安裝提示)。 - 將
model.openai_runtime: codex_app_server持久化保存到你的 config.yaml 中。 - 將用戶 MCP 服務器從
~/.hermes/config.yaml遷移到~/.codex/config.toml。 - 發現並遷移已安裝的原生 Codex 插件(Linear, GitHub, Gmail, Calendar, Canva 等),方法是查詢 Codex 的
plugin/listRPC。 - 將 Hermes 自帶的工具註冊為 MCP 服務器,以便 codex 子進程可以回調調用 codex 未附帶的工具。
- 寫入
default_permissions = ":workspace",這樣沙箱允許在工作區內進行寫入操作,而無需每次操作都提示確認。 - 告知你遷移了什麼內容。在下一個會話中生效 — 當前緩存的代理保留之前的運行時,以保持提示緩存有效。
同義詞:/codex-runtime on, /codex-runtime off, /codex-runtime auto。
要在不更改任何內容的情況下檢查當前狀態:
/codex-runtime
你也可以在 ~/.hermes/config.yaml 中手動設置:
model:
openai_runtime: codex_app_server # default is "auto" (= Hermes runtime)
自我改進循環(記憶 + 技能提示)
Hermes 的後臺自我改進功能會在達到計數器閾值時觸發:
- 每 10 個用戶提示 → 一個分叉的審查代理會查看對話,並決定是否應將任何內容保存到記憶中。
- 單輪對話中每 10 次工具迭代 → 思路相同,但針對技能(
skill_manage寫入)。
兩者在 codex 運行時上均保持正常工作。 codex 路徑將每個完成的 commandExecution / fileChange / mcpToolCall / dynamicToolCall 項投影為合成的 assistant tool_call + tool 結果消息,因此當審查運行時,它看到的結構與在默認 Hermes 運行時上看到的相同。
連接保持等效的方式:
| 默認運行時 | Codex 運行時 | |
|---|---|---|
_turns_since_memory 遞增 | 每個用戶提示,在 run_conversation 預循環中 | 相同的代碼路徑,在早期返回之前 |
_iters_since_skill 遞增 | chat-completions 循環中的每次工具迭代 | codex 輪次返回後,通過 turn.tool_iterations |
記憶觸發器 (_turns_since_memory >= _memory_nudge_interval) | 在預循環中計算,響應後觸發 | 在預循環中計算,傳遞給 codex 助手 |
技能觸發器 (_iters_since_skill >= _skill_nudge_interval) | 循環後計算 | codex 輪次後計算 |
_spawn_background_review(messages_snapshot=..., review_memory=..., review_skills=...) | 任一觸發器觸發時調用 | 任一觸發器觸發時以相同方式調用 |
一個細節:審查分叉(review fork)本身需要調用 Hermes 的 agent-loop 工具(memory、skill_manage),而這些工具需要 Hermes 自身的調度。因此,當父代理位於 codex_app_server 上時,審查分叉會降級為 codex_responses——使用相同的 OAuth 憑據和相同的 openai-codex 提供商,但直接與 OpenAI 的 Responses API 通信,以便 Hermes 擁有循環控制權,從而使 agent-loop 工具正常工作。這對用戶是不可見的。
最終效果:啟用 codex 運行時後,你的記憶(memory)和技能(skill)提示將繼續像往常一樣觸發。
審批工作方式
Codex 在執行命令或應用補丁之前會請求審批。這些請求會被轉換為 Hermes 標準的“危險命令”(Dangerous Command)提示:
╭───────────────────────────────────────╮
│ Dangerous Command │
│ │
│ /bin/bash -lc 'echo hello > foo.txt' │
│ │
│ ❯ 1. Allow once │
│ 2. Allow for this session │
│ 3. Deny │
│ │
│ Codex requests exec in /your/cwd │
╰───────────────────────────────────────╯
- 允許一次(Allow once)→ 批准此單個命令。
- 允許在此會話中(Allow for this session)→ Codex 不會就類似命令再次提示。
- 拒絕(Deny)→ 命令被拒絕;Codex 繼續在只讀模式下運行。
對於 apply_patch(文件編輯)審批,當 codex 通過相應的 fileChange 項提供數據時,Hermes 會顯示更改摘要(例如 1 add, 1 update: /tmp/new.py, /tmp/old.py)。
權限配置文件
Codex 有三個內置的權限配置文件:
:read-only— 禁止寫入;每個 shell 命令都需要審批:workspace— 允許在當前工作區內寫入而無需提示(啟用運行時時的 Hermes 默認設置):danger-no-sandbox— 完全無沙箱(除非你完全理解其含義,否則不要使用)
你可以在 Hermes 管理塊之外的 ~/.codex/config.toml 中覆蓋默認設置:
default_permissions = ":read-only"
(只要你的覆蓋內容位於 # managed by hermes-agent 標記之外,Hermes 將在重新遷移時保留你的覆蓋。)
輔助任務與 ChatGPT 訂閱令牌成本
當此運行時與 openai-codex 提供商一起啟用時,輔助任務(標題生成、上下文壓縮、視覺自動檢測、後臺自我改進審查分叉)默認也會通過你的 ChatGPT 訂閱進行計費,因為當沒有針對特定任務的覆蓋設置時,Hermes 的輔助客戶端會使用主提供商/模型。
這並非 codex_app_server 特有——現有的 codex_responses 路徑也是如此——但在這裡更為明顯,因為你明確選擇了訂閱計費。
要將特定的輔助任務路由到更便宜或不同的模型,請在 ~/.hermes/config.yaml 中設置顯式覆蓋:
auxiliary:
title_generation:
provider: openrouter
model: google/gemini-3-flash-preview
compression:
provider: openrouter
model: google/gemini-3-flash-preview
vision:
provider: openrouter
model: google/gemini-3-flash-preview
goal_judge:
provider: openrouter
model: google/gemini-3-flash-preview
自我改進審查分叉通過 _current_main_runtime() 繼承主運行時,並且 Hermes 會自動將其從 codex_app_server 降級為 codex_responses(以便分叉可以實際調用 memory 和 skill_manage——Hermes 自己的 agent-loop 工具)。除非你將輔助任務路由到其他位置,否則該分叉仍使用你的訂閱認證。
安全地編輯 ~/.codex/config.toml
Hermes 將其管理的所有內容包裹在兩個標記註釋之間:
# managed by hermes-agent — `hermes codex-runtime migrate` regenerates this section
default_permissions = ":workspace"
[mcp_servers.filesystem]
...
[plugins."github@openai-curated"]
...
# end hermes-agent managed section
該塊外部的任何內容都歸你所有。重新運行遷移(通過 /codex-runtime codex_app_server 或在切換運行時開啟時)會原地替換受管理塊,但原樣保留其上下的用戶內容。這意味著你可以:
- 添加 Hermes 不知道的自定義 MCP 服務器
- 將
default_permissions覆蓋為:read-only,如果你希望每次都收到提示 - 配置僅適用於 codex 的選項(模型、提供商、otel 等)
- 在
[permissions.<name>]表中添加用戶定義的權限配置文件
你在受管理塊內部添加的任何內容都會在下次遷移時被覆蓋。如果你需要進行必須編輯受管理塊的調整,請提交 issue,我們將添加相應的配置項。
多配置文件/多租戶設置
默認情況下,無論激活哪個 Hermes 配置文件,Hermes 都會將 codex 子進程指向 ~/.codex/。這意味著 hermes -p work 和 hermes -p personal 共享相同的 Codex 認證、插件和配置。對於大多數用戶來說,這是正確的行為——它與直接運行 codex CLI 的行為一致。
如果你希望每個配置文件具有獨立的 Codex 隔離環境(單獨的認證、單獨安裝的插件、單獨的配置),請為每個配置文件顯式設置 CODEX_HOME。最乾淨的方法是將其指向 HERMES_HOME 下的目錄:
# Inside the work profile, you might wrap hermes:
CODEX_HOME=~/.hermes/profiles/work/codex hermes chat
你需要在設置該 CODEX_HOME 的情況下重新運行一次 codex login,以便 OAuth 令牌存入配置文件作用域的位置。此後,hermes -p work 將在隔離的 Codex 狀態下運行。
我們不會自動執行此作用域劃分,因為移動現有用戶的 ~/.codex/ 會靜默使他們的 Codex CLI 認證失效——任何已經運行過 codex login 的用戶都必須重新認證。讓用戶主動選擇比讓他們感到意外更安全。
HOME 環境變量透傳
Hermes 在生成 codex app-server 子進程時不會重寫 HOME(我們使用 os.environ.copy() 並僅疊加 CODEX_HOME 和 RUST_LOG)。這意味著:
- Codex 通過其
shell工具運行的命令可以看到真實的用戶HOME,並正確找到~/.gitconfig、~/.gh/、~/.aws/、~/.npmrc等。 - Codex 的內部狀態通過
CODEX_HOME(默認指向~/.codex/)保持隔離。
這與 OpenClaw 在早期實驗後確定的邊界一致:隔離 Codex 的狀態,不觸碰用戶的主目錄。(參見 openclaw/openclaw#81562。)
MCP 服務器遷移
Hermes 的 mcp_servers 配置會自動轉換為 Codex 期望的 TOML 格式。每次啟用運行時都會執行遷移,且該操作是冪等的——重新運行會替換受管部分,但保留任何用戶編輯的 Codex 配置。
轉換內容如下:
Hermes (config.yaml) | Codex (config.toml) |
|---|---|
command + args + env | stdio 傳輸 |
url + headers | streamable_http 傳輸 |
timeout | tool_timeout_sec |
connect_timeout | startup_timeout_sec |
enabled: false | enabled = false |
未遷移的內容:
- Hermes 特有的鍵,如
sampling(Codex 的 MCP 客戶端沒有等效項——這些會被丟棄,並針對每個服務器發出警告)。
原生 Codex 插件遷移
通過 codex plugin 安裝的插件(Linear、GitHub、Gmail、Calendar、Canva 等)會通過 Codex 的 plugin/list RPC 被發現。對於每個 installed: true 的插件,Hermes 會在你的 Hermes 會話中寫入一個 [plugins."<name>@openai-curated"] 塊以啟用它。
這意味著:當你的朋友說“我在 Codex CLI 中設置了 Calendar 和 GitHub”,並且他們啟用了 Hermes 的 codex 運行時,Hermes 會自動激活這些插件。無需重新配置。
未遷移的內容:
- 你尚未安裝的插件——請先在 Codex 中安裝它們。
- Codex 報告
availability != AVAILABLE的插件(安裝損壞、OAuth 過期、從市場移除等)。這些會被跳過,以避免寫入在激活時會失敗的配置。 - ChatGPT 應用市場條目(每賬戶的
app/list結果——由於你的賬戶認證,這些已在 codex 內部啟用)。 - 插件 OAuth——你只需在 Codex 本身中授權每個插件一次;Hermes 不會觸碰憑證。
Hermes 工具回調(新的 MCP 服務器)
Codex 的內置工具集涵蓋 shell/文件操作/補丁,但不包含網絡搜索、瀏覽器自動化、視覺、圖像生成等功能。為了在 codex 輪次中保持這些功能的可用性,Hermes 會在 ~/.codex/config.toml 中將自身註冊為 MCP 服務器:
[mcp_servers.hermes-tools]
command = "/path/to/python"
args = ["-m", "agent.transports.hermes_tools_mcp_server"]
env = { HERMES_HOME = "/your/.hermes", PYTHONPATH = "...", HERMES_QUIET = "1" }
startup_timeout_sec = 30.0
tool_timeout_sec = 600.0
當模型調用 web_search(或其他暴露的 Hermes 工具)時,codex 通過 stdio 生成 hermes_tools_mcp_server 子進程,請求通過 model_tools.handle_function_call() 分發,結果像任何其他 MCP 響應一樣投影回 codex。
通過回調可用的工具: web_search、web_extract、browser_navigate、browser_click、browser_type、browser_press、browser_snapshot、browser_scroll、browser_back、browser_get_images、browser_console、browser_vision、vision_analyze、image_generate、skill_view、skills_list、text_to_speech。
不可用的工具: delegate_task、memory、session_search、todo。這些需要正在運行的 AIAgent 上下文來分發(循環中間狀態),而無狀態的 MCP 回調無法驅動它們。當你需要這些功能時,請使用默認的 Hermes 運行時(/codex-runtime auto)。
禁用
隨時切換回來:
/codex-runtime auto
在下一個會話中生效。Codex 受管塊保留在 ~/.codex/config.toml 中,以便你稍後可以重新啟用而不會丟失配置——或者如果你願意,也可以手動刪除它。
限制
此運行時為選擇加入的 beta 版本。截至 Hermes Agent 2026.5 + Codex CLI 0.130.0 正常工作:
- 多輪對話
- 通過 Hermes UI 批准
commandExecution和fileChange(apply_patch) - MCP 工具調用(已針對
@modelcontextprotocol/server-filesystem和新的hermes-tools回調進行驗證) - 原生 Codex 插件遷移(已針對 Linear / GitHub / Calendar 清單進行驗證)
- 拒絕/取消路徑
- 開啟/關閉切換週期
- 記憶和技能提示計數器(已通過集成測試實時驗證)
- 通過 codex 進行的 Hermes web_search(已實時驗證:“OpenAI Codex CLI – Getting Started”端到端返回)
已知限制:
- Hermes 認證和 codex 認證是獨立的會話。 你需要同時執行
codex login和hermes auth login codex以獲得最佳用戶體驗(運行時使用 codex 的會話進行 LLM 調用)。這是 Hermes 的_import_codex_cli_tokens中的 deliberate design choice(刻意設計選擇)——Hermes 不會與 codex CLI 共享 OAuth 狀態,以避免在令牌刷新時相互覆蓋。 - 在此運行時上無法使用
delegate_task、memory、session_search、todo。 它們需要正在運行的 AIAgent 上下文,而無狀態的 MCP 回調無法提供。當你需要這些功能時,請使用/codex-runtime auto。 - 當 codex 未跟蹤變更集時,批准提示中沒有內聯補丁預覽。 Codex 的
fileChange批准參數並不總是攜帶變更集。Hermes 會在可能時緩存來自相應item/started通知的數據,但如果批准在項目流式傳輸之前到達,提示將回退到 codex 提供的任何reason。 - 不保證亞秒級取消。 流式中斷(在 codex 響應時按 Ctrl+C)通過
turn/interrupt發送,但如果 codex 已經刷新了最終消息,你仍然會收到響應。
如果您發現 bug,請提交 issue 並附上 hermes logs --since 5m 的輸出。在標題中提及 codex-runtime,以便輕鬆進行分類處理。
架構
┌─── Hermes shell (CLI / TUI / gateway) ───┐
│ sessions DB · slash commands · memory │
│ & skill review · cron · session pickers │
└──┬──────────────────────────────────────┬┘
│ user_message final │
▼ text + │
┌──────────────────────────────────┐ projected │
│ AIAgent.run_conversation() │ messages │
│ if api_mode == codex_app_server │ │
│ → CodexAppServerSession │ │
│ else: chat_completions / codex_responses (default)
└────┬─────────────────────────────┘ │
│ JSON-RPC over stdio │
▼ │
┌──────────────────────────────────┐ │
│ codex app-server (subprocess) │──────────────┘
│ thread/start, turn/start │
│ item/* notifications │
│ shell + apply_patch + update_plan│
│ view_image + sandbox │
│ ┌─────────────────────────┐ │
│ │ MCP client │ │
│ │ ├─ user MCP servers │ │
│ │ ├─ native plugins │ │
│ │ │ (linear, github, │ │
│ │ │ gmail, calendar, │ │
│ │ │ canva, ...) │ │
│ │ └─ hermes-tools ───────┼─────────────────┐
│ │ (callback to │ │ │
│ │ Hermes' richer │ │ │
│ │ tools) │ │ │
│ └─────────────────────────┘ │ │
└──────────────────────────────────┘ │
│
▼
┌──────────────────────────────────────────────────────────┐
│ hermes_tools_mcp_server.py (subprocess on demand) │
│ web_search, web_extract, browser_*, vision_analyze, │
│ image_generate, skill_view, skills_list, text_to_speech│
└──────────────────────────────────────────────────────────┘
有關實現細節,請參閱 PR #24182 和 Codex app-server 協議 README。