OpenAI Codex interview questions now show up at AI-forward teams the same way "do you use Git?" used to. The format isn't a standardized exam. You're graded on real fluency with the Codex agent, not trivia you memorized off a listicle.
This page is a leveled question bank. Each question gets a real answer plus a line on what the interviewer is actually testing. It's written for the candidate, not the hiring manager, and it ends with a one-week prep sprint. For timed mock drills, Interview Coder runs the same kind of practice under a clock.
What Codex Actually Is in 2026 (and the 2021 vs 2025 Trap)
Codex is the umbrella name for one model running across several surfaces. There's a terminal CLI, an IDE extension, cloud delegation from inside ChatGPT, a GitHub bot that turns issues into pull requests, and a computer-use mode that drives a browser. Same agent, different entry points.
The model underneath is GPT-5.5-Codex, a retrained base tuned specifically for long agentic coding sessions instead of single completions. OpenAI reported Codex passing 4 million weekly active developers in April 2026 and 5 million by June, which is why it keeps landing in interview loops.
Here's the trap that filters juniors instantly. "Codex" was also the name of a 2021 OpenAI API model that powered the original GitHub Copilot, and that API was deprecated in 2023. If a candidate starts talking about a code-completion endpoint you call with a prompt and a temperature, they're describing a dead product from five years ago. The 2025-and-later Codex is an autonomous agent that reads your repo, runs commands, edits files, and verifies its own work in a sandbox. Interviewers ask the "what is Codex" question early precisely because the wrong answer ends the conversation.
If you want the broader company context, see the OpenAI interview process.
How These Questions Are Scored — 4 Categories
Panels usually split Codex questions into four buckets, and good interviewers map each round to one:
Juniors live in the first bucket. Seniors get filtered on the last two. The questions below are grouped the same way so you can see where you're strong and where you'll leak.
Codex Fundamentals: 8 Questions
These are warmups. Fumble them and you don't reach the design round.
1. What is the Codex CLI and how does it differ from the old Codex API?
Answer: The Codex CLI is a terminal agent. You run codex in a repo, describe a task in plain English, and it reads files, plans, runs commands, and edits code on your machine. The old Codex API (2021, deprecated 2023) was a stateless completion endpoint — you sent a prompt, got code back, and validated it yourself. The CLI is agentic and stateful; the API was a single-shot autocomplete.
What they're testing: That you're not five years out of date.
2. How do you install Codex and authenticate?
Answer: Install the CLI with npm install -g @openai/codex (or Homebrew), then run codex and sign in with your ChatGPT account. Auth is tied to your ChatGPT plan, so usage draws from that plan's limits rather than a separate API key by default. You can still wire in an API key for org billing.
What they're testing: Whether you've actually installed it or just read about it.
3. Name the Codex surfaces and when you'd pick each.
Answer: CLI for local work in a repo you have checked out. IDE extension when you want the agent inside your editor with diffs inline. ChatGPT cloud delegation for fire-and-forget tasks you don't want running on your laptop. The GitHub bot for issue-to-PR automation in a shared repo. Computer-use mode when the task needs a browser. One model, you pick the surface by where the work lives.
What they're testing: That you understand Codex is a family, not just the CLI.
4. What's the difference between GPT-5.5-Codex and GPT-5.5?
Answer: GPT-5.5-Codex is a retrained variant of the base model, released April 23, 2026, optimized for long coding sessions — better at staying on task across many tool calls, tighter diffs, less drift. GPT-5.5 is the general model. For agentic coding you want the Codex variant; it's the default in the CLI.
What they're testing: Current product knowledge, and whether you parrot version numbers or understand the tradeoff.
5. How does Codex billing work now?
Answer: Codex moved to token-based credit billing in 2026. Usage is metered in tokens and counts against your ChatGPT plan's allowance, refreshed on rolling windows rather than a hard daily cap. Heavy agentic runs burn credits fast, so you budget tasks, not just prompts. Check OpenAI's current pricing page before quoting exact windows or rates in an interview — the metering has changed more than once.
What they're testing: That you know the cost model changed — a stale answer (old fixed message limits) dates you.
6. Free vs Plus vs Pro — what access do you get?
Answer: There's a free tier with limited Codex usage to try it. ChatGPT Plus at $20/month gives a working daily allowance for real tasks. Pro at $100 and $200/month tiers raises the credit ceiling and concurrency for people running Codex all day, including more cloud delegation headroom. You scale the tier to how hard you lean on the agent.
What they're testing: Whether you've used it seriously enough to hit a limit.
7. What is AGENTS.md and why does it matter?
Answer: AGENTS.md is a markdown file you drop in the repo root that Codex reads as standing instructions — build commands, test commands, conventions, things to never touch. It's the difference between an agent that guesses your setup and one that runs your real test suite on the first try. You commit it so the whole team shares the same context.
What they're testing: That you configure the agent instead of fighting it every session.
8. Does Codex remember anything between sessions?
Answer: Not on its own — each run starts fresh on conversation state. Persistence comes from what's in the repo: AGENTS.md, your code, and any notes you commit. That's why the retrospective loop (update AGENTS.md after a repeated mistake) matters more than expecting the model to "learn."
What they're testing: That you don't anthropomorphize the agent's memory.
For the sibling terminal-agent guide, see Claude Code interview questions.
Agent Operation: 8 Questions on Approval & Sandbox Modes
This is where junior and senior separate. If you can't explain blast radius, you're not getting the offer. The two knobs and their blast radius, side by side:
| Setting | What it controls | Safe option | Risky option |
|---|---|---|---|
| Approval mode | Does Codex ask before acting | Read-only / on-request — pauses for edits or out-of-bounds actions | Full-access — runs anything without asking |
| Sandbox mode | What Codex can physically touch | workspace-write — edits in-repo, no network, no out-of-repo writes | danger-full-access — full disk, full network, no sandbox |
| Blast radius | Worst case if a run goes wrong | The working tree (recoverable with git) | The whole machine |
Approval mode and sandbox mode are independent. --full-auto is the common shorthand that pairs auto-approval with workspace-write — convenient, but you should know exactly which two knobs it set.
9. What are the three approval modes?
Answer: Read-only (Codex can look and plan but asks before any edit or command), Auto / on-request (it reads, edits, and runs commands inside the workspace automatically, asking only for things outside that boundary like network or writes outside the repo), and full-access (it runs anything without asking). You pick the mode by how much you trust the task and the directory you're in.
What they're testing: Core operational literacy.
10. Explain the sandbox modes.
Answer: read-only blocks all writes. workspace-write lets Codex edit and run commands inside the current repo but blocks network access and writes outside the workspace by default. danger-full-access removes the sandbox entirely — full disk, full network. OpenAI documents these named modes and their defaults in the Codex sandboxing reference. Approval mode is "does it ask"; sandbox mode is "what can it physically do." They're separate knobs and you set both.
What they're testing: That you don't conflate approvals with sandboxing — a common mix-up.
11. What does --full-auto do and what's the blast radius?
Answer: --full-auto pairs auto-approval with workspace-write — it stops asking and just works inside the repo. Blast radius is the workspace: it can rewrite, delete, and re-run anything in that directory without confirmation, but the sandbox still blocks network and out-of-repo writes. So a bad run can trash your working tree but not your whole machine — unless you also dropped the sandbox.
What they're testing: Whether you understand a flag's failure mode before you type it.
12. You ran --full-auto in prod and it deleted your migration files. Walk me through what went wrong.
Answer: Three failures stacked. One, I ran an autonomous agent against a production-adjacent directory instead of an isolated branch or clone. Two, I used --full-auto so it never paused on the destructive step. Three, I had no clean git state to recover from, or I'd have just reset. The fix isn't "Codex is dangerous" — it's that I removed every guardrail at once. Right way: isolated branch, on-request approval for anything touching migrations, and a committed checkpoint before I start.
What they're testing: Postmortem maturity. They want ownership and a concrete process fix, not blame on the tool.
13. When do you NOT let Codex run autonomously?
Answer: Anything touching infra, secrets, migrations, prod data, or money. Anything where I can't cheaply undo the result. Anything in a directory I don't fully control. For those I drop to read-only or on-request and review every command. Autonomy is for reversible, well-tested, low-stakes changes.
What they're testing: Judgment. The senior answer is a list of stop conditions, not "always" or "never."
14. What are subagents and when do you use them?
Answer: Subagents are scoped child runs the main agent spins up for a contained piece of work — investigate this module, write tests for that file — each with its own focused context. You use them to keep the main session's context clean and to parallelize independent chunks of a big change instead of cramming everything into one ballooning conversation.
What they're testing: That you manage context deliberately on large tasks.
15. How do you verify Codex's work without trusting it blindly?
Answer: I have it run the test suite inside the sandbox after every change, not just at the end. AGENTS.md points it at the real test and lint commands so it self-checks. Then I read the diff before I let anything merge. Trust the sandbox to catch breakage; trust my own eyes for intent.
What they're testing: That verification is built into your workflow, not bolted on.
16. How do you contain risk when delegating a task to the cloud?
Answer: Cloud delegation runs in an isolated container, so the blast radius is that container, not my machine. I still scope the task tightly, give it a clear done-condition, and review the resulting PR like any other. Isolation handles the environment risk; review handles the correctness risk.
What they're testing: That you reason about where code executes.
This connects to broader agentic AI interview questions on autonomy and guardrails.
Prompt Patterns & Workflow Fluency: 7 Questions
Trivia gets you past the recruiter. These get you past the engineer.
17. How do you use a planning prompt before a big change?
Answer: I ask Codex to produce a numbered plan first and stop before touching code. I read it, fix the parts it got wrong, then tell it to execute. Planning surfaces a bad assumption before it writes 400 lines around it. I use it on anything touching more than two files.
What they're testing: That you spend tokens on a plan to save them on a rewrite.
18. What's the reverse-interview pattern?
Answer: Before the agent writes anything, I tell it to ask me clarifying questions about the task. It surfaces ambiguity I'd otherwise discover halfway through — which API version, which file owns this, what the edge cases are. Cheap to ask, expensive to assume.
What they're testing: Whether you front-load ambiguity instead of debugging it later.
19. Codex keeps making the same mistake across sessions. What do you do?
Answer: I run the retrospective loop. After the mistake, I ask the agent what rule would have prevented it, then I commit that rule to AGENTS.md. Now every future session reads it. I'm turning a one-off correction into permanent context instead of re-correcting forever.
What they're testing: That you treat AGENTS.md as a living config, not a one-time file.
20. How do you scope a multi-file change?
Answer: I name the files and the contract up front — "change these three, keep this interface stable, don't touch the public types." Tight scope keeps the agent from wandering into unrelated refactors and keeps the diff reviewable. Vague scope is how you get a 30-file PR you can't read.
What they're testing: That you constrain the agent instead of hoping.
21. When do you reach for subagents in your own workflow?
Answer: When a task has independent parts — research, then implement, then test — I split them so each subagent keeps a clean, focused context. The main run stays readable and I avoid the late-session drift you get when one conversation tries to hold everything.
What they're testing: Practical context management, not just the definition.
22. How do you verify with tests inside the sandbox?
Answer: I make running the test suite part of the task, not a manual follow-up. AGENTS.md has the test command, the agent runs it in workspace-write after each change, and a red result blocks the change. The sandbox is my CI loop at the speed of the edit.
What they're testing: That correctness checks live in the loop.
23. Why narrate your workflow out loud in the interview?
Answer: Because the interviewer is grading my reasoning, not the agent's output. I say what mode I'm in and why, what I'm asking the agent to plan, what I'll check in the diff, and where I'd stop it. Narration is how I show judgment the agent can't show for me.
What they're testing: Communication. Silent driving reads as luck; narration reads as fluency.
These overlap with prompt engineering interview questions and the parent AI engineer interview questions bank.
Codex vs GitHub Copilot: 4 Decision-Framework Questions
This is the single most common follow-up. Have a clean framework ready. The table below is the framework compressed to one screen — memorize the shape, not the words.
| Dimension | Codex | GitHub Copilot |
|---|---|---|
| Interaction model | Async agent — hand off a task, walk away | Synchronous inline — completes as you type |
| Unit of work | A whole task across many files | The next line or block |
| Who verifies | Agent self-checks in a sandbox, then you review the diff | You, line by line, on every suggestion |
| You review | Outcomes (the final diff and test run) | Keystrokes (accept/reject each suggestion) |
| Best when | Well-scoped, reversible work you can describe and delegate | Tight feedback loops where you stay in control |
| Worst when | Small edits where spinning up an agent is overkill | Large multi-file changes you'd rather not babysit |
24. Codex or Copilot — what's the core difference?
Answer: Copilot is a synchronous inline assistant. It completes code as you type and you stay in the loop on every line. Codex is an async autonomous agent — you hand it a task, it plans and executes across many files, and you review the result. Copilot speeds up your typing; Codex takes over a unit of work. Different jobs, not competitors at the same task.
What they're testing: That you can frame the category difference cleanly.
25. When does Copilot win?
Answer: Tight feedback loops where I want to stay in control — writing a new function, exploring an unfamiliar API, anything where I'm thinking as I go. Inline suggestions keep me driving. Copilot also wins when the task is small enough that spinning up an agent is overkill.
What they're testing: That you don't oversell agents for everything.
26. When does Codex win?
Answer: Well-scoped tasks I can describe and walk away from — "add this endpoint, wire it up, write tests." The local AGENTS.md workflow gives it the project context to do that without hand-holding, or I push an issue to the GitHub bot and get a PR back. Codex wins when the work is bigger than a completion and reversible enough to delegate.
What they're testing: That you match tool to task instead of having a favorite.
27. One self-verifies, one you verify — explain.
Answer: Codex runs tests in its sandbox and self-checks before handing me a diff, so verification is partly the agent's job. With Copilot, validation is entirely on me — it suggests, I accept or reject line by line. That changes how I work: with Codex I review outcomes, with Copilot I review keystrokes.
What they're testing: Whether you grasp the execution-model difference, not just the UX.
For the full breakdown, see Copilot interview questions. The Cursor interview questions guide covers the third editor-agent comparison point.
Limitations & Risk: 3 Questions Interviewers Use to Find Seniors
If you can name real failure modes with specifics, you read as someone who's shipped with the tool.
28. What's a real Codex failure mode you've hit in a long session?
Answer: Stale task-state hallucination. In a long run, the agent can claim it already did a step it didn't, or act on an out-of-date view of the files — search the openai/codex issue tracker for "stale" or "already did" and you'll find live reports of exactly this. The fix is operational: keep sessions short, re-ground the agent by having it re-read the file before acting, and split long work into fresh subagents instead of one marathon conversation.
What they're testing: First-hand experience. A citable, specific failure beats "sometimes it makes mistakes."
From the trenches. The clearest version of this I've watched happen: a ~40-minute session refactoring a service across six files. Around the 30-minute mark the agent announced it had "already updated the config and re-run the tests" — except the config was untouched and the last test run was twenty minutes stale. It wasn't lying so much as reading its own compacted summary as ground truth. The tell is the confident past-tense claim with no fresh tool call behind it. Now I cut any session over ~20 minutes into fresh subagents and make the agent re-read the file it's about to edit. That one habit killed the problem. Bring a story this specific and the interviewer stops grading and starts nodding.
29. How does Codex's context handling compare to Claude Code?
Answer: Both compact context when the window fills, and compaction is lossy — detail from early in the session can get summarized away. Codex's tradeoff is that aggressive compaction in a long agentic run is part of what feeds the stale-state problem. The practical answer is the same for both: shorter sessions, explicit re-grounding, and subagents to keep any single context from blowing past the window.
What they're testing: That you understand context windows as a real constraint, not magic.
30. "It gives bad output" — but you say it's usually setup. Explain.
Answer: OpenAI's own best-practices docs make the point that setup issues masquerade as quality issues. The agent looks dumb when it's really pointed at the wrong working directory, missing write access to the files it needs, defaulting to the wrong model, or missing an AGENTS.md so it never learned your test command. Before I blame the model I check: right directory, right sandbox permissions, right model, AGENTS.md present. Nine times out of ten the "quality" problem is a config problem.
What they're testing: Senior debugging instinct — check the environment before blaming the model.
A 1-Week Prep Plan for Codex Interviews
Treat this as a sprint, not reading. You can't fake fluency you don't have.
--full-auto task in a throwaway sandbox. A clone or branch you can nuke. Watch the blast radius. Then break it on purpose and recover with git so you've lived the postmortem answer.For more on bringing AI tools into a live setting without tripping a proctor, work the same drills you'd run for any live coding round.
Practice With Realistic Mocks
Reading answers isn't the same as saying them under a clock with someone watching. Interview Coder runs timed AI-tooling mock drills so you rehearse the narration, the mode choices, and the postmortem answers before they count. Pair it with the best AI interview tools in 2026 roundup to build your prep stack.
FAQ
Is Codex the same as GitHub Copilot? No. The 2021 Codex API did power the original Copilot, but the 2025+ Codex is a separate autonomous agent. Copilot is a synchronous inline assistant that completes code as you type; Codex takes a whole task, plans it, and executes across files while you review the outcome.
Is the Codex CLI free? There's a free tier with limited usage to try it. Real daily work starts at ChatGPT Plus ($20/month), with Pro tiers at $100 and $200/month for heavier use. Usage is metered in token-based credits on rolling 5-hour windows.
What's GPT-5.5-Codex? A retrained variant of the base model, released April 23, 2026, tuned for long agentic coding sessions — better task-holding, tighter diffs, less drift than the general GPT-5.5. It's the default model in the Codex CLI.
Do I need Pro for interview prep? No. Plus is enough to install, ship a small feature, write an AGENTS.md, and practice approval and sandbox modes. Pro matters only if you're running the agent all day or leaning hard on cloud delegation.
Is Codex allowed in coding interviews? Depends on the interview. Some teams now test Codex fluency on purpose. Others ban all assistants. Read the rules for each round — and if a team is grilling you on approval modes and AGENTS.md, using the tool well is the point, not cheating.
Ready to actually practice?
Interview Coder is a desktop app built to get you through AI-tooling and coding rounds. Coding answers run on Claude Sonnet 4.6, Anthropic's latest Sonnet, with 20+ stealth features and 100K+ users already prepping with it. Full disclosure: this guide is published by Interview Coder.
