Codex in the editor: the IDE extension bridges two worlds
There is one agent in the Codex stack, but it answers on three surfaces: terminal, editor, and cloud. The IDE extension is the surface I underestimated (right up until I paid attention to where my agent sessions actually spend their time). Not prompting. Reviewing.
What the editor surface buys
- Context without ceremony. The extension sees your open file and your selection, so "fix this" points at something concrete. In the terminal you name paths and paste snippets, the dance covered in the CLI quickstart.
- Review-as-you-go. Proposed changes arrive as real diffs in the editor's diff viewer: the same place you review humans, with syntax highlighting, jump-to-definition, and per-file accept or reject one keystroke away.
- Local-cloud handoff. Kick a bigger job to Codex cloud from the same panel, keep working, then pull the finished branch back and review it without switching windows.
The middle one is load-bearing. Terminal agents render diffs as colored text in a pager, and colored text in a pager gets skimmed. Editors were built for precisely this artifact.
An agent's output is a diff, and diffs belong where your diff tools live.
Where the CLI stays king
Scripting and automation. The CLI composes like a Unix tool: pipe a failing test log into it, run it non-interactively inside a pipeline, wire it into pre-merge checks. An editor extension cannot be a build step. The terminal also travels better. SSH sessions, containers, a teammate's machine: it runs anywhere with a shell, no window manager required.
And if your habits are terminal-first, the extension adds a window, not a capability. That is fine. The sharper contrast is with Junie, which bet everything on the IDE and bought deep project-model integration at the price of terminal illiteracy, a trade I unpack in Junie vs terminal agents. Codex refuses to choose a side, which is exactly what makes the handoff story work.
Two honest caveats. As of this writing the extension is a VS Code-family story: official support targets VS Code and its forks, so JetBrains users get a thinner path. And it is the same model underneath. The editor surface makes mistakes easier to catch, not rarer. If the agent was going to fumble your async code in the CLI, it will fumble it identically in the extension. You will just see it sooner.
So the real question is one agent, two surfaces, split by activity. Interactive work and diff review belong in the editor, where rejecting a bad hunk costs one keystroke. Automation, CI, and remote machines belong to the CLI. If you review agent diffs in a terminal pager today, run one week inside the extension and watch your rejection rate. Mine went up — which is the point. The diffs did not get worse. I finally started seeing them.