Persistent Codex processes

AgentX normally starts codex exec for every request. To retain a Codex app-server between requests, enable the following on a codex-cli agent:

{
  "tier": "codex-cli",
  "persistentProcess": true
}

Restart the AgentX daemon after changing this setting, once active work has drained. The first request starts the process; subsequent requests to the same conversation reuse it. Model inference and context processing still take time. This setting does not change the selected model or enable a cheaper fallback model.

Requirements and configuration

Install and authenticate Codex first (codex login). Your installation must support codex app-server with initialize, thread/start, thread/resume and turn/start. See the official app-server documentation. An older CLI or failed initialization falls back to the existing codex exec path before any turn is submitted. Codex itself must still be installed for that fallback.

Configuration difference: app-server loads the operator's Codex configuration; it does not support the exec path's --ignore-user-config flag. Review your Codex configuration (including additional MCP servers) before opting in. AgentX explicitly sets the workspace, configured model, AgentX MCP connection, sandbox and approval policy for each thread. Interactive approval requests are rejected. Default agents use workspace-write; only bypassPermissions agents use danger-full-access.

Lifecycle and isolation

• Each agent/channel/chat combination has its own process and MCP environment.
• Workspace, model, permission or environment changes replace the idle process.
• A fresh session replaces the process. Otherwise, only a supplied session ID is resumed; requests without a session ID start a new thread.
• The pool retains at most eight processes and closes idle processes after five minutes. At capacity it evicts an idle process or uses the CLI fallback.
• Cancellation, process crashes and turn deadlines close the affected process. Requests are never automatically replayed after turn/start is sent.
• Daemon shutdown closes the pool after draining work.

These Codex limits are currently fixed; the processPool configuration and agentx process commands manage the separate Claude pool. OpenCode can also reuse a dedicated server; see persistent OpenCode processes.

Measuring startup

Execution events include codex.ready (reused, startupMs) and codex.first_output (elapsedMs, reused). Compare cold and reused requests in execution logs. Ready time includes initialization and thread start/resume; first-output time also includes model latency. No production speedup is assumed without these measurements.

Check it worked

1. Send the agent two short messages in the same chat.
2. Browser: open each run's Task page from Live or Activity and read its live output.
3. The first run shows . codex started ready=…ms. The second shows . codex reused ready=…ms: the process was kept between requests.

If something is wrong

• Nothing changed after editing the setting: the daemon only reads persistentProcess when it starts. Restart it once running tasks have finished (see Restart without losing work).
• Every request shows . codex using CLI fallback: …: the reason follows the colon. Usually the installed Codex is too old for codex app-server, or it isn't signed in. Update Codex, run codex login, then restart the daemon.
• A reused process behaves differently from codex exec: app-server loads your own Codex configuration (see Configuration difference above). Review it, or turn persistentProcess off and restart the daemon.