hermes - 💡(How to fix) Fix codex-runtime migration should preserve full-access Codex permissions

Summary

When Hermes is using model.openai_runtime: codex_app_server, the Codex runtime permissions are controlled through ~/.codex/config.toml. The migration currently writes a managed default_permissions = ":workspace" by default, but there does not appear to be a user-facing way for a gateway/iMessage user to persist :danger-no-sandbox / full-access behavior for Codex runtime.

This creates a footgun: a user can manually fix ~/.codex/config.toml so Codex app-server starts with full access, but a later /codex-runtime on / setup / migration pass can rewrite the managed block back to :workspace, causing global update/install tasks to fail with sandbox approval errors again.

Observed locally

A user's ~/.codex/config.toml had a Hermes-managed default_permissions written after existing TOML tables. Codex treated it as scoped under the previous table rather than a top-level key, so codex debug prompt-input still showed:

sandbox_mode: workspace-write
Network access: restricted

Moving the permissions to true top-level fixed it:

sandbox_mode = "danger-full-access"
approval_policy = "never"
default_permissions = ":danger-no-sandbox"

After that, codex debug prompt-input showed:

sandbox_mode: danger-full-access
Network access: enabled
Approval policy: never

I noticed current main already contains a fix for the TOML root-key placement issue (fix(codex-runtime): keep migrated root keys top-level / PR #25857), so this report is about the remaining persistence/overwrite behavior rather than re-reporting that fixed bug.

Why this matters

In gateway/iMessage contexts there is often no interactive place to approve Codex sandbox escalations. If Codex runtime is left at :workspace, requests like updating the globally installed Codex CLI or touching files outside the current workspace fail or get surfaced as rejected approval requests.

For users intentionally running a personal Hermes gateway with full local access, the desired state is:

sandbox_mode = "danger-full-access"
approval_policy = "never"
default_permissions = ":danger-no-sandbox"

That state should be stable across Hermes migration/update flows, or at least there should be a clear supported knob to request it.

Suggested fixes

Any of these would solve the footgun:

1. Preserve an existing top-level default_permissions, sandbox_mode, and approval_policy when regenerating the Hermes-managed Codex config block.
2. Add a Hermes config setting / slash command option for Codex runtime permissions, e.g. codex_runtime.permissions: danger-no-sandbox or /codex-runtime permissions full-access.
3. If approvals.mode: off, /yolo, or an equivalent terminal security setting is active, have the migration write :danger-no-sandbox instead of hard-coding :workspace.
4. During migration, heal old misplaced default_permissions entries and avoid creating duplicate top-level keys when a user has manually repaired their config.

Related issues / PRs

• #26530 covers codex app-server approvals failing closed in gateway contexts.
• #26529 covers migration being skipped when openai_runtime is already set.
• PR #25857 / commit 274217316 appears to fix the original root-key insertion bug, but not the full-access preference persistence problem.