Using the Codex CLI Inside a VS Code Terminal

Running the Codex CLI inside VS Code's integrated terminal rather than a separate terminal window is the setup most people land on without deciding it deliberately — and it's worth knowing what that choice actually buys you, and where it falls short of a dedicated editor integration.

Why the integrated terminal is a reasonable default

Keeping Codex in the same window as the code it's editing removes the context-switching cost of alt-tabbing to a separate application every time you want to check a session's progress or give it a new instruction. File changes Codex makes on disk show up in VS Code's own file explorer and editor tabs immediately, since it's editing the same working tree VS Code has open — there's no sync step, no separate checkout, just one shared filesystem view from two different tools looking at it.

What you don't get compared to a dedicated integration

The integrated terminal is still a terminal — Codex's output is text, not rendered UI, and there's no special affordance for reviewing a proposed diff beyond what a plain terminal renders (which is often a real, readable diff, just not one with click-to-accept controls). If you want inline diff review, gutter annotations, or a dedicated panel showing session state separate from raw terminal output, that's a different category of integration than the terminal approach provides, and it's worth checking whether a dedicated extension for your editor exists before assuming the terminal is the only option.

Split terminals for a genuinely useful pattern

Running Codex in one terminal pane and keeping a second pane free for your own commands — running the test suite yourself to double-check, tailing a log, checking git status — is a small setup cost that pays off constantly during a real session. It means you're never waiting on Codex to finish before you can check something yourself, and you can verify a claim it just made ("the tests pass now") independently rather than only trusting its own report.

Multiple Codex sessions in multiple terminal tabs

VS Code's terminal supports multiple tabs and split panes, which makes running more than one Codex session at once — against different parts of a project, or against entirely different projects — a natural extension of the same setup rather than something requiring separate tooling. The main thing worth watching here is making sure you know which tab is working on which task before giving an instruction, since it's easy to type into the wrong pane once several sessions are running in parallel and lose track of which one is which.

Reviewing changes through VS Code's own diff view

Even without a dedicated Codex extension, VS Code's built-in source control panel shows exactly what Codex has changed on disk, the same way it would show any other uncommitted change — a genuinely useful way to review a session's output with syntax highlighting and a proper side-by-side diff, rather than reading a raw text diff in the terminal itself. This is worth using as your primary review surface even in a terminal-only setup; the terminal is where you talk to Codex, the source control panel is where you check what it actually did.

Keeping the terminal's working directory correct

A VS Code integrated terminal opens rooted at the currently open folder by default, which usually means Codex starts with the correct project as its working directory automatically — but in a multi-root workspace or a monorepo with several nested projects open together, it's worth explicitly confirming which directory a new terminal actually opened into before starting a session, since a session started in the wrong subdirectory will apply Codex's default trust and sandbox behavior to a directory that isn't the one you meant to work in.

Where this fits against other workflow choices covered elsewhere

This site covers running Codex inside tmux or another terminal multiplexer as a separate pattern, and the two aren't mutually exclusive — running a multiplexer session inside VS Code's own integrated terminal combines the editor's file-view convenience with a multiplexer's session persistence, which is worth considering if you've found yourself wanting both. For most day-to-day work, though, the plain integrated terminal, used deliberately with split panes and the built-in diff view, covers the large majority of what a VS Code-based workflow actually needs.

Keyboard workflow between the terminal and the editor pane

Learning your editor's shortcut for jumping focus between the terminal and the main editing pane — rather than reaching for the mouse every time — is a small habit that compounds over a long session with a lot of back-and-forth between giving Codex an instruction and reading the file it just changed. It's a minor efficiency on its own, but across dozens of round trips in a real working session, it's the kind of friction that's worth eliminating once rather than tolerating indefinitely.

Terminal scrollback as an informal session log

The integrated terminal's scrollback is, in effect, a running transcript of everything a session has done and said, which is worth remembering when you want to check what happened several turns ago without asking Codex to re-summarize it — scrolling up is often faster and more reliable than asking the model to recall its own earlier reasoning, especially in a long session where recall of early turns has already started to degrade. It's also worth knowing that scrollback is finite and configurable; a very long session can outlast your terminal's default history buffer, which is worth checking and extending if you regularly run sessions that go on for a while.

Restarting the terminal without losing your place

If VS Code or the underlying shell needs restarting mid-session — a crash, a needed environment change — the Codex session itself doesn't survive that restart the way a codex resume-based workflow would if invoked deliberately; a fresh integrated terminal is a fresh shell with no memory of what came before. Knowing whether your workflow depends on session continuity across restarts is worth deciding upfront, and pairing the integrated-terminal approach with codex resume where that continuity matters, rather than assuming the terminal itself preserves anything beyond its own scrollback text.