Codex

What you have on its own

Codex is OpenAI's coding CLI, and it's built to run without a human watching each step: point it at a task and it plans, edits, and reports back on its own. That's exactly the shape CodeHerder needs for a stage nobody is sitting in front of.

It's a capable agent in its own right. CodeHerder doesn't replace it: it gives it a task, an isolated worktree, and a place on the dashboard, then gets out of the way. The one tradeoff to know about is how it runs, covered below.

What changes when a herd runs it

On its own, Codex has none of this either. Put it inside a herd, and:

• One dashboard for every agent, on every machine, instead of a terminal per machine.
• Atomic task claims, so two agents can never grab the same piece of work.
• An enforced plan, code, review, merge, verify, done workflow on every task.
• Cost tracked per task, not just a total bill you see once a month.

How CodeHerder launches it

CodeHerder launches Codex through its own non-interactive exec mode, which skips the approval prompts it normally shows before each command and file write. Codex runs with fewer of its own guardrails turned on, and it does so inside a single throwaway git worktree, on a device you own, with no other task's work anywhere nearby. See security for what's actually locked down at the machine and worktree layer.

Set it up once with ch agent config set <agent-id> --harness codex --cap model:sonnet. Codex has no --session-id flag of its own: it mints its own thread id inside the CLI, so CodeHerder can't hand it one before the process starts the way it can for Claude. The device can discover that id after a run and resume it through Codex's own exec resume subcommand, but that path is a device-side opt-in, off by default: a fresh install resumes nothing until an operator turns it on. Once it's on, a fresh stage still never falls back to Codex's own --last shortcut, since one worktree persists across every stage of a task and --last would silently resume whichever stage most recently ran Codex there.

Skills load from .agents/skills, the location OpenAI's own docs specify for a repo-scoped skill. Cost is tailed from the same rollout file the resume lookup already reads.

What works today, and what doesn't

Resume

Opt-in. No --session-id flag. CodeHerder can discover the thread id after a run and resume it through codex's own exec resume subcommand, but a device operator has to turn codex-native resume on first (CH_CODEX_RESUME, off by default).

Cost tracking

Tracked. Cost is tailed from ~/.codex/sessions, where the CLI writes its own rollout JSONL.

Skills

Delivered via .agents/skills.

Sign-in check

Confirmed. A read of ~/.codex/auth.json. No network call.

Getting it onto a device

Routing is gated on the bin:codex capability token, so tasks only land on a device that actually has the binary installed. Auth is confirmed by reading the local Codex credentials file, no network call required.

See capabilities for how routing works, and adding a device for the connection walkthrough.

Mixed herds

An agent can carry an ordered list of launch configs, each with its own harness. A common pairing: Claude Code plans and reviews, Codex writes the code, each its own config in the same agent's ordered list. Reorder or disable either one without touching the workflow itself, so swapping which CLI writes the code is a config change, not a migration. Reorder or disable any config in that list without touching the workflow itself.