hermes - 💡(How to fix) Fix [Feature]: codex_app_server runtime should expose sandbox_mode / ask_for_approval via Hermes config

Summary

When model.openai_runtime: codex_app_server, Codex launches with its default sandbox (read-only, no network). This blocks all writes — including git checkout, git merge, file edits, and any command that touches .git or the workspace. There is currently no Hermes-level configuration to set sandbox_mode or ask_for_approval for the spawned codex app-server subprocess.

The only workaround is to manually edit ~/.codex/config.toml, which changes the default for all Codex sessions globally — not just Hermes. This is a bad user experience: many users have different permission expectations between interactive Codex App/CLI usage and background Hermes-driven Codex usage.

Environment

• Hermes: current main (post-#26533, post-#25857 TOML placement fix)
• Codex CLI: 0.133.0 (npm global install via nvm on WSL)
• Config: model.openai_runtime: codex_app_server, model.provider: openai-codex
• OS: WSL2 (Ubuntu), Windows host

Discovery / Investigation

1. Symptom: Asked Hermes to "switch to our dev branch and update upstream code". All git operations failed — sandbox was read-only. The session system message confirmed sandbox_mode: read-only. Approval escalation requests returned rejected by user with no UI prompt appearing.

2. First suspect — thread/start permissions: Checked agent/transports/codex_app_server_session.py. The code explicitly chooses not to pass permissions in thread/start (experimental API gated on this Codex version, requires a matching [permissions] table in ~/.codex/config.toml, fragile). So this path was intentionally abandoned upstream.

3. Second suspect — migration: The Hermes migration (hermes_cli/codex_runtime_plugin_migration.py) writes default_permissions = ":workspace" to ~/.codex/config.toml. But:

   • This uses the v1 Codex config key, not sandbox_mode
   • Our ~/.codex/config.toml did not have this key written (possibly due to a TOML placement issue, or because the migration pass was skipped)
   • Even if it had, default_permissions = ":workspace" maps to Codex v1 profiles, not the current sandbox_mode = "workspace-write"

4. What works — manual ~/.codex/config.toml edit: Adding sandbox_mode = "danger-full-access" and ask_for_approval = "on-request" to ~/.codex/config.toml makes Codex app-server start with the desired permissions. But this changes the default for all Codex sessions — Hermes, Codex App, Codex CLI — because they all read the same config file.

5. What should work — codex app-server CLI args: Codex officially supports -c key=value overrides on the codex app-server command line:

   codex app-server -c 'sandbox_mode="danger-full-access"' -c 'ask_for_approval="on-request"'

   agent/transports/codex_app_server.py already has an extra_args parameter on CodexAppServerClient.__init__(). But there is no Hermes config key that populates this parameter.

6. Why not just edit ~/.codex/config.toml?: As discussed in #27616, manual edits to ~/.codex/config.toml can be overwritten by migration passes. More importantly for our use case: the user wants Codex App (interactive) and Hermes Codex (background/gateway) to have different permission profiles. Codex App should keep its current high-permission behavior; Hermes should independently get danger-full-access via runtime config.

Proposed Solution

Add a structured config block under model that maps to Codex -c overrides when spawning codex app-server:

model:
  openai_runtime: codex_app_server
  codex_app_server:
    sandbox_mode: danger-full-access      # read-only | workspace-write | danger-full-access
    ask_for_approval: on-request          # on-request | never | untrusted
    network_access: true                  # only meaningful when sandbox_mode != danger-full-access

Or, as a simpler pass-through (less structured but more future-proof against Codex config evolution):

model:
  openai_runtime: codex_app_server
  codex_app_server_args:
    - "-c"
    - "sandbox_mode=danger-full-access"
    - "-c"
    - "ask_for_approval=on-request"

The structured approach is preferable because:

• It validates values against Codex's documented set
• It prevents config drift between sandbox_mode and ask_for_approval
• It can handle the network_access nuance for workspace-write mode

Affected Code Paths

1. Config schema — hermes_cli/config.py (add model.codex_app_server.sandbox_mode / ask_for_approval / network_access)
2. Runtime launch — agent/transports/codex_app_server.py:CodexAppServerClient.__init__() (accept or derive extra_args from config)
3. Session setup — run_agent.py:_dispatch_codex_app_server_turn() or wherever the client is constructed (pass config→args)
4. Migration — hermes_cli/codex_runtime_plugin_migration.py (optionally write the new keys instead of / in addition to default_permissions)

Relationship to Existing Issues

• #27616 — complementary: that issue asks for migration to not nuke manual config; this issue asks for a config key so users don't need to manually edit at all
• #26533 — different scope: that fixed gateway approval routing; this is about the sandbox level at which Codex starts, before any approval flow
• #24182 — the original codex_app_server feature PR; this fills a configuration gap in that feature

Workaround (for users hitting this today)

Add to ~/.codex/config.toml:

sandbox_mode = "danger-full-access"
ask_for_approval = "on-request"

Caveat: This changes the default for ALL Codex sessions, not just Hermes.