skip to content
Stephen Van Tran
Table of Contents

I’ve been waiting for a release like this—not because I crave a new benchmark screenshot, but because I crave a cleaner inner loop. GPT‑5.2 Codex arriving inside Codex CLI feels like OpenAI sharpening the thing I actually use: a terminal-native teammate that can read a repo, propose a plan, patch a file, run a command, and tell me what happened without turning my workflow into a Rube Goldberg machine.

If you’ve been following the “coding agents” arms race, you’ve seen a curious split. On one side: bigger models, more tools, more “capabilities.” On the other: a quiet fight over the medium. Is this whole wave becoming a tangle of pre-built scripts—skills, slash commands, agents, subagents, plugin marketplaces—where “talking to the model” is merely the wrapper around a growing pile of automation? Or are we heading toward something simpler: conversation as the primary interface, with structure and safety underneath, not bolted on top?

My own take is unapologetically chat-first. I’m hopeful GPT‑5.2 Codex will outclass Opus 4.5 for day-to-day engineering work not because “OpenAI good, Anthropic bad,” but because Codex models have consistently felt more aligned with the original contract: tell the model what you need in plain language, and let it do the messy translation into diffs, tests, and shell commands. I don’t want a second shell language made of /commands and “skills.” I want one language: English. The terminal is just the place where English turns into a patch.

Codex CLI itself is explicit about this stance: it’s “a coding agent from OpenAI that runs locally on your computer,” meant to be driven by prompts and guarded execution, with an interactive TUI (codex) and an automation surface (codex exec). (See the Codex CLI README: https://raw.githubusercontent.com/openai/codex/main/README.md.)

The story of GPT‑5.2 Codex is not “the model got smarter.” The story is “the loop got tighter.”

The medium is conversation, not a command palette

There’s a reason the best agent sessions still feel like a good pairing session: intent first, mechanics second. When “agent products” drift, they drift in the same direction: they start asking the human to become a workflow designer.

You can see the gravitational pull in the broader ecosystem. Claude Code, for example, introduces itself as an “agentic coding tool that lives in your terminal” and immediately expands the perimeter: “Use it in your terminal, IDE, or tag @claude on Github,” plus plugins “that extend functionality with custom commands and agents.” (Claude Code README: https://raw.githubusercontent.com/anthropics/claude-code/main/README.md.) The changelog reads like a product org finding its center of gravity: plugins, a plugin discover screen, slash-command aliases, model switching hotkeys, permission UIs, “Claude in Chrome,” and continuous UX work to keep the complexity navigable. (Claude Code changelog: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md.)

None of that is inherently wrong. Sometimes those surfaces are exactly what you need. But there is a cost: every new mode is another chance to stop thinking in terms of “what do I want?” and start thinking in terms of “which mechanism do I pull?”

I prefer the opposite. I want the CLI to be the thinnest possible layer between my intent and the repo:

  • I describe the work.
  • The agent reads what it needs.
  • It proposes the smallest credible plan.
  • It changes as little as possible.
  • It runs only the commands that move the task forward.
  • It returns artifacts a human can review.

That flow is precisely what Codex’s “getting started” guide emphasizes: the tool is prompt-driven (codex "fix lint errors"), it can be resumed, and it has a non-interactive mode explicitly framed as automation (codex exec). (Codex getting started: https://raw.githubusercontent.com/openai/codex/main/docs/getting-started.md.)

This is also why I keep coming back to Codex’s AGENTS.md story. Codex doesn’t ask you to re-learn a new mini-language of “skills.” It asks you to write down your constraints, conventions, and expectations in plain text, in files the agent knows how to discover and merge. (AGENTS.md discovery in the Codex docs: https://raw.githubusercontent.com/openai/codex/main/docs/getting-started.md.)

And yes, the irony is delicious: both ecosystems now have “skills,” but the difference is where they sit. In Codex CLI, skills is explicitly an experimental feature flag in config. (Codex config docs, feature flags: https://raw.githubusercontent.com/openai/codex/main/docs/config.md.) That reads like a team trying to keep the product honest: skills are allowed, but they are not the default worldview.

Here’s the core fork in the road, in one small ASCII table:

Design choiceConversation-first agentScript-first agent
Primary interfaceNatural languageSlash commands, skills, templates
Human’s jobState intent and reviewPick modes and wire workflows
Failure modeMisunderstood intentTool sprawl, brittle automation

GPT‑5.2 Codex matters because it pushes the conversation-first path forward without pretending we can skip safety, tooling, or structure. It’s a model release that is really a product philosophy test.

One more practical observation: the command-palette approach often optimizes for “discoverability,” but discoverability is not the same as fluency. A palette helps you find a feature you didn’t know existed; it does not help you express a messy, real-world desire like “make this migration safe, minimal, and reviewable.” Conversation is fluent by default. It’s the interface you already have mastery over. The job of the product is to translate that fluency into execution—without demanding you become a part-time orchestrator.

That’s why “chat in the terminal” is not a gimmick. It’s a reclaiming. The shell is where we already think in systems: inputs, outputs, exit codes, diffs. When the model speaks chat and the shell speaks reality, you get a loop that can be simultaneously high-level and brutally verifiable.

What’s new in GPT‑5.2 Codex (and why it feels different)

The cleanest “what changed” signal is hidden in an unglamorous place: release notes.

Codex CLI release 0.74.0 introduces “gpt-5.2-codex,” framed as “our latest frontier model with improvements across knowledge, reasoning and coding,” and pairs it with a new /experimental slash command “for trying out experimental features.” (Codex CLI release 0.74.0: https://github.com/openai/codex/releases/tag/rust-v0.74.0.)

That pairing is not accidental. It’s the whole story:

  • A model with higher ceilings (knowledge, reasoning, coding).
  • A UI affordance that quarantines complexity (“experimental” is explicitly labeled).

There’s a second signal in the release cadence itself. Codex CLI is shipping like a tool that lives in the inner loop: frequent stable releases plus alpha trains when a change needs fast iteration. You don’t need to romanticize velocity, but you should notice what it implies: someone is instrumenting the workflow and sanding down the papercuts that only show up after thousands of real sessions. (Codex CLI releases feed: https://github.com/openai/codex/releases.)

You can see the same philosophy in Codex’s config surface. The config docs list gpt-5.2 as a supported model and add a higher reasoning knob—model_reasoning_effort = "xhigh"—available on gpt-5.2. (Codex config docs, model selection: https://raw.githubusercontent.com/openai/codex/main/docs/config.md.) That’s the kind of lever that matters in real work because it lets you “buy thinking” for the step that deserves it: the migration plan, the architecture decision, the security review. Then you drop back down for the mechanical edits.

It also makes the model feel more “operator-shaped.” One of the hardest skills in production engineering is deciding where to spend attention: not every file deserves a dissertation, and not every incident deserves an agent to run wild. A single config knob that can change how aggressively the model thinks is an ergonomic proxy for a deeper truth: sometimes your best move is to slow down on purpose.

The second, subtler change is about honesty under tools. Any model can be smart in a vacuum. The question is whether it stays truthful when it can act.

OpenAI’s GPT‑5.2 system card spends real attention on tool-related failure modes: prompt injection in tool outputs, agentic failures, and the risk of fabricating tool traces. (GPT‑5.2 system card PDF: https://cdn.openai.com/pdf/3a4153c8-c748-4b71-8e31-aecbde944f8d/oai_5_2_system-card.pdf.) That framing matters because it matches what CLI users actually experience: the most expensive bug is not “the model was wrong.” The most expensive bug is “the model was wrong and looked right”—a confident narrative stapled to phantom commands.

GPT‑5.2 Codex, in practice, feels like a bet that this can improve: fewer hallucinated steps, fewer runaway loops, fewer “I ran the tests” claims that don’t match the terminal reality. You can’t prove that from a marketing paragraph, but you can infer it from the way the safety documentation centers tool behavior as a first-class risk. If the system card is investing in the “act safely” problem, the Codex line is where that investment becomes a product.

The third signal is community gravity. The Codex CLI repo is not a side project; it’s one of the most-watched implementations of “agentic dev tooling” on GitHub. As of today, openai/codex shows 54k stars, while anthropics/claude-code sits at 47k. (GitHub repo pages: https://github.com/openai/codex and https://github.com/anthropics/claude-code.)

Here’s an original, operator-friendly way to read that: normalize stars by age. openai/codex was created in April 2025 and has accumulated ~54k stars in about 8.2 months—roughly 6.6k stars/month. anthropics/claude-code was created in February 2025 and has accumulated ~47k stars in about 9.9 months—roughly 4.8k stars/month. The point is not “stars equal truth.” The point is that conversation-first terminal agents are not a niche taste; they are rapidly becoming a default expectation. When the developer commons moves that quickly, the winning products are the ones that preserve the medium while upgrading the engine.

Finally, there’s the pragmatic shift from “agent as demo” to “agent as automation surface.” Codex’s docs make codex exec a first-class mode: non-interactive runs, prompt-in / logs-out, meant to be scripted and replayed. (Codex getting started: https://raw.githubusercontent.com/openai/codex/main/docs/getting-started.md.) This is where GPT‑5.2 Codex has leverage: when you can run a bounded instruction repeatedly, small gains in reliability compound into real throughput.

To be clear, automation is not the endgame. It’s the test. When you ask a model to do the same bounded task ten times—upgrade a package, fix a lint rule, migrate a config schema—you learn what you can’t learn from a charismatic one-off demo: does it respect the contract under repetition? Does it drift? Does it start “helping” by rewriting more than you asked? GPT‑5.2 Codex is exciting precisely because it raises the odds that repetition produces consistency, not entropy.

To make that compounding concrete, stitch two external datapoints:

If you believe those two signals are even directionally true, the operator takeaway is startling: once assistants are commonplace, a modest reliability upgrade has workforce-scale implications. If 76% of a team adopts an assistant and that assistant reduces time-to-task by 55% on the tasks where it applies, the naive throughput uplift is ~42% (0.76 × 0.55) before you account for review savings and context switching. GPT‑5.2 Codex’s job is to make that uplift feel less like a gamble and more like a habit.

This is why I called it a tighter loop. A model upgrade that only improves “answers” is a nice-to-have. A model upgrade that improves the sequence—plan, patch, verify, narrate—is the kind of thing that changes how you build.

If you want more context on the broader GPT‑5.2 series framing, I wrote a separate operator take on /posts/2025-12-12-gpt-5-2-launch/. If you want the CLI-versus-CLI trench comparison, see /posts/2025-11-12-claude-code-vs-codex-cli-gpt5-vs-claude45/.

What could break this thesis (and why the “skills” temptation is dangerous)

Let’s be honest about the failure mode: every agent product wants to become an operating system.

Some of that is healthy evolution. Developers ask for shortcuts, persistent memory, reusable workflows, safer execution, faster navigation. Those features arrive as slash commands, plugins, hooks, templates, skill files—whatever branding the vendor chooses. Claude Code’s changelog is transparent about this direction: it adds plugin discovery, search, permission screens, a Chrome control surface, model switching hotkeys, and plan-mode UX improvements. (Claude Code changelog: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md.)

Codex CLI is not immune. The config docs explicitly include an experimental skills feature flag: “Enable discovery and injection of skills.” (Codex config docs, feature flags: https://raw.githubusercontent.com/openai/codex/main/docs/config.md.) And Codex’s README includes a first-class docs link for “Slash Commands.” (Codex README: https://raw.githubusercontent.com/openai/codex/main/README.md.)

So what’s the difference? It’s not the existence of commands. It’s whether commands become the center of gravity.

When commands become the center, two things happen:

  1. You stop practicing intent. You start practicing invocation. The model becomes a shell for pre-shaped routines, and your “skill” becomes memorizing the right incantation.

  2. You outsource understanding to automation. If the agent runs a command because it’s “the workflow,” you may approve it without re-reading what it does. That’s how brittle systems get brittle audits.

This is also why GPT‑5.2’s system card emphasis on tool behavior matters. Models with tools introduce a new category of failure: not just “wrong,” but “wrong while acting.” (GPT‑5.2 system card PDF: https://cdn.openai.com/pdf/3a4153c8-c748-4b71-8e31-aecbde944f8d/oai_5_2_system-card.pdf.) If skills encourage more action, then skills increase the importance of tool honesty and permissioning.

At a practical level, the “skills creep” risk is easiest to spot when your CLI starts accumulating:

  • dozens of commands you only vaguely remember,
  • hidden default behaviors that run before you type,
  • and an approval model that becomes background noise.

Codex’s docs explicitly call out an “ask for approval” flag (--ask-for-approval/-a) and present codex exec as automation mode. (Codex getting started: https://raw.githubusercontent.com/openai/codex/main/docs/getting-started.md.) That’s good—and it’s also a reminder: the better the model gets, the more you must treat execution as a privilege boundary, not a convenience.

There’s one more counterpoint worth stating plainly: GPT‑5.2 Codex won’t save you from vague work.

Conversation-first doesn’t mean “no structure.” It means “structure as a contract between humans,” expressed in normal language. If you ask for “make this better,” you get a model that tries to be helpful—and helpfulness is the enemy of precision. The quality ceiling comes from your constraints: what not to change, what to preserve, what “done” means, what tests to run, what risks to avoid. Codex can ingest those constraints via AGENTS.md, but you still have to write them down. (Codex getting started, AGENTS.md discovery: https://raw.githubusercontent.com/openai/codex/main/docs/getting-started.md.)

The thesis, then, is conditional: GPT‑5.2 Codex shines when you pair it with crisp intent, tight permissioning, and a culture of review. If you treat it as magic, it will behave like magic: impressive, unreliable, and occasionally cursed.

Outlook: try Codex like an operator (and keep the magic)

The best way to evaluate GPT‑5.2 Codex is not “does it wow me?” It will. The best way is: “does it reduce the cost of finishing?”

Here’s a practical, low-drama way to try it that keeps the medium intact and the risk bounded.

First, install Codex CLI the boring way and run it on a repo you actually care about. Codex’s README suggests npm i -g @openai/codex or brew install --cask codex, then codex to start. (Codex CLI README: https://raw.githubusercontent.com/openai/codex/main/README.md.) Don’t start with a greenfield toy project; start with your actual pain: a flaky build, a dependency upgrade, a refactor you’ve postponed because it’s annoying.

Second, write down your constraints as if you’re onboarding a smart contractor. This is where chat-first becomes powerful: you can stop inventing prompts and start inventing policy. Put repo-local guidance in AGENTS.md (style, conventions, commands to run, boundaries). Then watch how much faster the model becomes when it doesn’t have to guess your taste. (Codex getting started, AGENTS.md: https://raw.githubusercontent.com/openai/codex/main/docs/getting-started.md.)

Third, use GPT‑5.2 Codex for the steps that deserve the higher ceiling, and be explicit about your budget. The Codex config surface supports selecting gpt-5.2, and it documents a higher model_reasoning_effort = "xhigh" available on gpt-5.2. (Codex config docs: https://raw.githubusercontent.com/openai/codex/main/docs/config.md.) My workflow is simple:

  • Spend “xhigh” on reconnaissance and planning.
  • Spend “medium” on implementation.
  • Spend “low” on rote edits and cleanup.

Fourth, keep skills quarantined until you earn them. Yes, you can explore /experimental, and yes, skills exist. But if you care about the chat medium, you should treat every new automation surface like adding a dependency: it must pay rent. (Codex CLI 0.74.0 release notes: https://github.com/openai/codex/releases/tag/rust-v0.74.0.)

Finally, measure the only thing that matters: do you ship more, with less dread?

Here’s a simple operator checklist you can run in a single afternoon, without turning your setup into a second job:

  • Pick one bounded task (dependency bump, lint fix, refactor one module).
  • Add an AGENTS.md that states constraints in plain language (what not to touch, formatting rules, commands to run).
  • Start with codex (interactive) and ask for a plan before changes; approve only after the plan reads sane.
  • Prefer small patches: “limit changes to files” and “do not rename public APIs.”
  • Require one verification step: run the project’s test or build command and report exit codes.
  • When the task is genuinely hard, temporarily raise model_reasoning_effort to "xhigh" for planning, then drop it.
  • Keep /experimental and skills off until you can explain what they do and why you need them.
  • Use codex exec only after the interactive path produces a patch you’d merge by hand.
  • Log what worked and what didn’t; treat prompt patterns like infrastructure, not vibes.

My bet—and my hope—is that GPT‑5.2 Codex pushes us toward a calmer style of engineering assistance: fewer rituals, fewer meta-workflows, fewer “agent frameworks,” more plain-language intent that turns into correct diffs. If that’s true, the next year of developer tooling won’t be defined by who has the biggest agent marketplace. It’ll be defined by who keeps the medium pure: conversation in, software out.

If you’ve been waiting for a reason to try Codex, this is the moment. Pick one annoying task you’re avoiding. Open the terminal. Write the prompt you’d write to a teammate you respect. Then let GPT‑5.2 Codex show you what it feels like when the loop finally tightens.