Codex — Part 1 — What It Is and Why It Matters for IT Engineers
Codex is OpenAI’s terminal-based coding agent, built to read, edit, and run commands inside a real project rather than answer questions in a chat window, and that difference matters just as much for infrastructure work as it does for application code.
Runs as a CLI inside your project folder, the same shape of tool as the Claude Code series already covered on this site.
Reads files, edits them, and runs real commands to finish a task instead of only describing one.
Runs inside a sandbox with configurable write access, a different safety model to review before trusting it on real infrastructure.
Introduction
This site already has a foundations series for Claude Code. Codex is OpenAI’s answer to the same category of tool, an agentic coding assistant that lives in a terminal rather than a browser tab, and it is different enough in its details, AGENTS.md instead of CLAUDE.md, approval modes instead of permission rules, that it earns its own series rather than a single comparison post.
This first post covers what Codex actually is and why it is worth an IT engineer’s time before installing anything. The rest of the series walks through setup, configuration, and the same daily-ops territory the Claude Code series covers.
What Is Codex?
Codex is an agentic coding tool built by OpenAI that inspects, edits, and runs code from your terminal while you stay in interactive control of what happens. It is one surface of a broader platform: the same underlying agent also runs as an IDE extension, inside a desktop app for coordinating projects, and in the cloud for tasks you want to kick off and check back on later.
Think of it the same way as the terminal colleague analogy from the Claude Code series: instead of describing a problem to a chat window and copying the answer out by hand, you describe a task to a tool that is already sitting in your project directory and can act on it directly.
How This Differs From a Chatbot
The same distinction that matters for Claude Code applies here: what the tool is actually allowed to touch, not how well it writes.
| Capability | Typical browser-based AI chat | Codex |
|---|---|---|
| Reads your files directly | No, you paste content in manually | Yes, reads the project directory itself |
| Edits files | No, gives you text to copy out | Yes, writes changes directly inside a sandbox |
| Runs commands | No | Yes, subject to the active approval mode and sandbox setting |
| Keeps project-specific context | Limited to the current chat, re-pasted every time | Persists via an AGENTS.md file read at the start of every run |
| Extends with custom procedures | No | Yes, through Skills, MCP servers, and delegated subagents |
Where It Runs
The Codex ecosystem spans four surfaces built on the same underlying agent: the CLI, an IDE extension, a desktop app for coordinating several tasks, and Codex cloud for running work in a parallel environment you check back on later. For IT and ops work, the CLI is the natural starting point, the same reason the Claude Code series opened there.
Why an IT Engineer Would Want This
The pitch is the same one made for Claude Code, applied to a different vendor’s tool: reading real files and running real commands maps directly onto scripting, log triage, and documentation work, not just application development. Writing and debugging PowerShell or Bash is faster when the tool can see the actual script and read the actual error rather than working from a copy-pasted summary of it.
Where Codex earns a separate series rather than a paragraph in the Claude Code one is in the details: a different configuration file, a different approval and sandbox model, and its own take on skills, subagents, and MCP. An engineer who has to support both tools, or who is choosing between them, needs those details covered on their own terms.
What’s Coming in This Series
This post is Part 1. The rest of the series mirrors the shape of the Claude Code foundations series, with the specifics that are actually different between the two tools.
| Part | Topic |
|---|---|
| Part 2 | Installing Codex CLI, and fixing the install issues you are most likely to hit |
| Part 3 | Creating and navigating your first project |
| Part 4 | Understanding and writing AGENTS.md |
| Part 5 | Creating a custom Skill |
| Part 6 | Subagents in Codex |
| Part 7 | Approval modes, sandboxing, and config.toml |
| Part 8 | Common Codex issues and fixes, a standing reference |
| Part 9 | Connecting external tools with MCP |
Final Thoughts
Codex is worth the setup time for the same reason Claude Code was: it does not stay a side conversation. It reads what is actually in front of it and acts on it directly, inside a sandbox you control.
The rest of this series exists to get you from a cold install to using Codex comfortably on real scripts and real infrastructure work, covering the parts that are genuinely different from Claude Code rather than repeating what the earlier series already established.
Next, we install it: the native installer, npm, Homebrew, and Windows options, the account it needs, and the install-time errors engineers hit most often.