Codex CLI
Status
Section titled “Status”First-party AI provider shipped with arka-deck. Chat runtime via a Codex CLI subprocess.
| Field | Value |
|---|---|
| Manifest id | codex-cli |
| Addon id | codex_cli |
| Maturity | beta |
| Authentication | managed by the codex binary (internal OAuth cycle) |
Surfaces
Section titled “Surfaces”| Surface | Detail |
|---|---|
ChatRuntime | providers/codex_cli/ (subprocess orchestration) |
| Catalogue manifest | composition/addons/provider-manifests.ts (entry codex-cli) |
| Internal modules | providers/codex_cli/internal/ |
Specifics
Section titled “Specifics”The Codex CLI runtime executes by subprocess: arka-deck spawns the codex binary, sends the turn via stdin/stdout, and collects the result. This allows leveraging Codex native capabilities without reimplementing orchestration on the arka-deck side.
| Property | Detail |
|---|---|
| Default timeout | configurable per turn |
| Separated stderr | never mixed with stdout |
| No direct network call | only through the codex binary which manages its authentication |
Project runtime MCP
Section titled “Project runtime MCP”When project runtime tools are available, arka-deck can expose arka_runtime to Codex. The MCP gives the agent project-scoped tools for active squad lookup, runtime snapshot, ArkaDoc list/read, task list, memory and Mission Control flowmap. It is the preferred project context surface for agents; filesystem inspection remains for source work, not for discovering arka-deck runtime state.
arka_runtime is a generic project MCP: it does not expose orchestration write tools. arkaStartSquadLeaderOrchestration and arkaSubmitSquadLeaderCommand go through the in-process arka_orchestration MCP, bound to the agent session, and are rejected by the system unless the current agent is the active squad leader.
Going further
Section titled “Going further”- “Write a provider” tutorial: ../extension/ecrire-un-provider (coming)
- Anti-SSRF policy: ADR 0006