Codex CLI

Codex CLI

Codex CLI is OpenAI's CLI coding agent. It runs as a process in its own Daintree terminal panel with full PTY emulation, like every other built-in agent.

Install & Authenticate

Install from npm: npm install -g @openai/codex. Run codex once to sign in. Codex stores its credentials in ~/.codex/auth.json, which is where Daintree looks; OPENAI_API_KEY counts as authenticated too. For details, see the Codex CLI repository.

How Daintree Launches It

Codex is one of the three agents that launch inline by default. Daintree passes --no-alt-screen, so Codex writes into Daintree's own scrollback instead of taking the alternate screen buffer — output stays scrollable and selectable with the native selection layer. Turn on "use alt-screen mode by default" globally, or flip the per-agent or per-preset override, and the flag is dropped.

Turning on permission bypass adds --dangerously-bypass-approvals-and-sandbox. Codex declares bypass support, so the global "skip permission prompts" switch reaches it as well as the per-agent toggle.

The $ picker

Codex is the agent that puts capabilities behind a $ trigger, and Daintree's unified input completes them with a category badge on each row so a skill and a plugin are distinguishable at a glance:

• Skills — directories containing a SKILL.md, read from Codex's bundled system skills, your own ~/.codex/skills, and the project's .agents/skills. Set CODEX_HOME and all three user-scoped paths follow it.
• Plugins — the enabled plugin entries in config.toml intersected with the manifests cached under plugins/cache, so only plugins that are both enabled and installed are offered.

A skill and a plugin can share a name; the skill wins the label. Codex Apps are modelled in the same picker but not yet discovered, because they resolve server-side with no local manifest to read.

The / trigger completes Codex's built-in commands, including /goal — shared with Claude Code, with Codex's own description covering its edit, pause, resume, and clear subcommands.

Subagents

Child threads a Codex session spawns appear in the panel header as a count you can open and read. Daintree gets them over Codex's own app-server protocol rather than scraping the terminal or parsing rollout files: a short-lived codex app-server per lookup, restricted by a method allowlist to reads only, so nothing here can start a thread or mark a project trusted in your config.toml.

Codex is the provider that can say a child is Waiting for approval or Waiting for input, because the protocol reports it; it never says Done, because a thread it declined to load has no finish to observe. Attribution is its weak point: Daintree only learns a Codex session ID once the session ends, so a running terminal is matched to its thread by folder plus liveness. Two live Codex sessions in one worktree can't be told apart, and Daintree shows nothing rather than the wrong one's children. The full mechanism is on Subagents in the Header.

Resuming Sessions

Daintree captures Codex's session ID during graceful shutdown and resumes with codex resume <session-id>. Daintree now sends Ctrl+C and sends a second press only if Codex displays its “again to quit” prompt. It does not inject /quit, which can become a queued chat message during a busy turn. If no ID is captured during shutdown, cold restore first asks Codex which conversation resume --last would select in that folder. When it resolves an exact ID, Daintree resumes that ID and records it on the pane immediately. A missing CLI, failed lookup or tied latest sessions leaves codex resume --last as the fallback. Sibling-pane ownership checks can withhold either resume path to avoid reopening the same conversation twice. Codex keys its sessions by UUID rather than by path, so a conversation is resumable from any folder — moving or renaming a project preserves it. For the resume mechanics across all agents, see Session Resume. If a fresh session starts instead, the restore banner offers Find session to choose another Codex conversation.

Integration reference

This guide describes Daintree's checked-in integration. Its agent definition records the launch command, install guidance, authentication probes, rendering capabilities, and resume support. Authentication badges report local evidence; the CLI still owns sign-in and provider access. After changing an installation, use Re-check in Settings > CLI Agents; restart Daintree if its inherited PATH has changed.