Codex CLI

Statut

Provider IA first-party livré avec arka-deck. Runtime de chat via un sous-processus Codex CLI.

Champ	Valeur
Manifest id	`codex-cli`
Addon id	`codex_cli`
Maturité	beta
Authentification	géré par le binaire `codex` (cycle OAuth interne)

Surfaces

Surface	Détail
`ChatRuntime`	`providers/codex_cli/` (orchestration sous-processus)
Manifest catalogue	`composition/addons/provider-manifests.ts` (entrée `codex-cli`)
Internal modules	`providers/codex_cli/internal/`

Particularités

Le runtime Codex CLI s’exécute par sous-processus : arka-deck spawn le binaire codex, lui passe le tour via stdin/stdout, et collecte le résultat. Cela permet de bénéficier des capacités natives Codex sans réimplémenter l’orchestration côté arka-deck.

Propriété	Détail
Timeout par défaut	configurable selon le tour
Stderr séparé	jamais mélangé au stdout
Pas d’appel réseau direct	uniquement via le binaire `codex` qui gère son authentification

MCP runtime projet

Quand les tools runtime projet sont disponibles, arka-deck peut exposer arka_runtime à Codex. Le MCP donne à l’agent des tools scopés projet pour lire la squad active, le snapshot runtime, la liste/lecture ArkaDoc, les tasks, la mémoire et la flowmap Mission Control. C’est la surface privilégiée de contexte projet pour les agents ; l’inspection filesystem reste réservée au travail sur les sources, pas à la découverte de l’état runtime arka-deck.

arka_runtime est un MCP projet générique : il n’expose pas les tools write d’orchestration. Les commandes arkaStartSquadLeaderOrchestration et arkaSubmitSquadLeaderCommand passent par le MCP in-process arka_orchestration, lié à la session agent, et sont refusées côté système si l’agent courant n’est pas le leader de la squad active.

Pour aller plus loin

Tutoriel “écrire un provider” : ../extension/ecrire-un-provider (à venir)
Politique anti-SSRF : ADR 0006