Codex CLI arrives as a repo-versioned pipeline step

A pipeline slot for the coding agent

The first time I saw a coding agent used well in CI, it was somebody's Friday afternoon experiment: a shell action that curled a prompt into an API and hoped for the best. It worked. It also stored the API key in a plain repo variable, ran with full container write access, and lived in a script nobody wanted to touch. That is the whole reason I paid attention to this week's news: OpenAI's Codex CLI now ships as a proper first-party pipeline action, with a model choice, a sandbox mode and prompts committed alongside the rest of the pipeline. That last part is what stuck with me.

What actually shipped

An OpenAI platform integration holds the API key as an encrypted secret. A new Codex CLI action consumes it. In the YAML you pick a model from the Codex family, choose a sandbox mode, and point at one or more prompts. The prompts can be inline, but the interesting shape is when they live as files in the repo. That means the prompt is a reviewable, versioned artifact next to the code it operates on. Change the prompt, open a PR. Roll it back, git revert.

The sandbox modes are the safety knob. WORKSPACE_WRITE is the default and lets the agent read and write inside the pipeline filesystem. READ_ONLY confines it to a look-but-do-not-touch role, good for review or triage prompts. FULL_ACCESS opens the whole container.

A minimal step, in the shape the announcement uses:

- action: Codex review
  type: CODEX_CLI
  integration: openai
  model: gpt-5-codex
  sandbox_mode: READ_ONLY
  prompts:
    - file: codex-prompt.md

That is small on the page and large in what it changes about your pipeline. The agent run is now a versioned step with the same review path as any other change.

What I actually like about it

Prompts as files, in the repo, is the win. Anyone who has tried to reconstruct why an agent behaved differently last Tuesday knows how quickly a chat-based workflow becomes irreproducible. Making the prompt an artifact you can diff turns a black box into a testable input.

The default sandbox mode is more permissive than I would have picked. If you accept WORKSPACE_WRITE without thinking, an agent step can rewrite files inside the runner immediately. That is fine when the run itself is scoped and ephemeral, less fine when the same pipeline pushes a branch or opens a PR right after. Start with READ_ONLY while you tune the prompt, then step up. The announcement itself gives the same advice, which I appreciated.

The model choice is a real one. You pick from a Codex family plus the general gpt-5 model, so you pin a specific behaviour instead of inheriting whatever your provider defaults to that week. For CI, that is more valuable than the raw quality delta between models. Reproducibility beats vibes.

How other CI tools handle coding agents in the pipeline

The interesting question is how each tool wires a stateful, credentialed, sometimes destructive command into a job. The shapes are more different than they look.

• GitHub Actions. The mature answer is a marketplace action plus repo or org secrets. Anthropic ships an official Claude Code action; community actions cover other providers. The strong point is OIDC federation: a workflow can mint a short-lived token to a cloud IAM role without a long-lived key sitting anywhere. If your governance story leans on OIDC and audit logs at scale, this is still the deepest option, and it is the better fit if your organisation already lives inside GitHub's identity envelope.
• GitLab CI. CI/CD variables plus a job template. Nothing agent-specific out of the box, but the template pattern is cheap and works with any CLI you can install. Job-level ID tokens give you the same short-lived credential shape as Actions' OIDC. For teams already all-in on GitLab this is usually simpler than adding a new tool, and it keeps the agent step in the same review and approvals flow as the rest of your pipeline.
• CircleCI. Orbs are the packaging layer, and the SDK-flavoured ones keep multiplying. The strong point is contexts: they scope secrets to specific projects or environments. If you want a coding agent that can only see production credentials in a manual-approval job, contexts do that cleanly.
• Jenkins. Plugins and shell steps. It is the flexible end of the spectrum: nothing is out of reach, but nothing is done for you. Teams with a lot of in-house Groovy will keep it, and there is a fair argument that Jenkins remains the better fit when the pipeline needs to talk to on-prem systems the SaaS options do not reach.
• Buddy. This week's news. The Codex CLI action packages the model choice, the sandbox mode and the prompt-as-file convention into a single YAML block. The concrete reason to reach for it: the sandbox knob and the prompt-file shape reduce the amount of glue you have to write yourself when the goal is a repeatable, reviewable agent step. The OpenAI Codex CLI action announcement walks through the fuller shape.

None of these are wrong. The pattern is what matters: an agent step needs a credential boundary, a filesystem boundary and a versioned prompt. Whichever tool gets you those three fastest is the right one for your team.

What I am watching next

Two things. First, whether the sandbox default drifts to read-only across the ecosystem as teams learn what a write-capable agent does to a cache directory. A permissive default is a reasonable Day One choice and a nervous Day Ninety one. Second, whether prompt-as-file becomes the norm or dies as a habit. Everything about CI/CD works better when the config is in the repo, and prompts are just another kind of config now. If a year from now most teams are still pasting prompts into web UIs, the ergonomics lost.