hermes - 💡(How to fix) Fix Feature request: per-turn composability for Codex runtime / plugin access from native Hermes sessions [1 participants]

Summary

The Codex app-server runtime (v0.14+) is a powerful addition, but its all-or-nothing session-level activation creates a frustrating trade-off: users must choose between (a) Codex's native sandbox, apply_patch, and growing plugin ecosystem (Gmail, Calendar, Linear, GitHub), or (b) Hermes' own richer toolkit (delegate_task, memory, session_search, todo, cronjob, browser automation, etc.).

This makes the Codex runtime impractical for users whose primary reason for choosing Hermes is persistent cross-session memory and subagent delegation. They can't cherry-pick Codex integrations (e.g. 'use Codex's Gmail plugin for this email') without surrendering the rest of their workflow.

Problem in detail

• /codex-runtime codex_app_server switches the entire agent loop for openai/* turns. There is no per-task or per-tool choice.
• On the Codex runtime, delegate_task is unavailable (needs Hermes agent loop context), as are memory, session_search, todo.
• Codex plugins (Gmail, Calendar, etc.) are only accessible inside the Codex runtime, so they are effectively locked away from native Hermes users.
• This pushes users toward either (a) running two separate Hermes sessions and manually coordinating between them, or (b) abandoning the Codex runtime entirely despite its genuine advantages.

Suggested approaches

Option A: Dual-session coordinator pattern

Allow a native Hermes session to spawn a sibling Codex-runtime session in the background and route specific requests to it. The native session retains memory, delegation, and the full Hermes toolkit; the Codex session handles native Codex tasks and reports back.

Practically, this could look like:

• A new config flag or slash command that spawns a persistent Codex-runtime sub-session
• A tool (e.g. codex_task) that sends a prompt to the Codex sub-session, awaits completion, and returns structured results to the native session
• The native session's memory and skills remain intact; Codex plugins become callable tools

Option B: MCP-style plugin bridge

Codex plugins are already TOML-configured. Hermes could discover installed Codex plugins and surface them as native Hermes tools when running in native mode, without requiring the full Codex runtime. This would give native Hermes users direct access to Gmail, Calendar, etc. while keeping the agent loop unchanged.

Option C: Per-model runtime routing

Instead of openai/* → Codex runtime for the whole session, allow a model alias or /model switch to activate the Codex runtime only for turns on that model, while the default model continues on the native runtime. A single session could alternate between models with different runtimes.

Why this matters

• Codex is building genuinely useful integrations (Gmail, Calendar, Canva, Linear, GitHub) that are hard to replicate in Hermes natively.
• Hermes' core differentiator is persistent memory and skills — losing it defeats the purpose of using Hermes over Codex directly.
• The composability gap will widen as both ecosystems grow. Users will drift toward whichever platform has the integrations they need, rather than the agent framework.

Related

• Persistent subagents (#5586)
• Per-task model overrides in delegate_task (#15789)
• Coordinator pattern (#11508)

Environment: Hermes v0.14.0+, Codex CLI 0.131.0, Linux ARM64 (Raspberry Pi 5). Issue surfaced while evaluating whether to enable the Codex runtime for daily use.