Running Codex Alongside a Language Server

Your editor's language server and Codex are both reasoning about the same code at the same time, from genuinely different vantage points — one from a real, structural understanding of the language via parsing and type-checking, the other from reading the code as text alongside whatever context you've given it. Understanding the difference is what makes the two actually complementary rather than a source of confusing, conflicting signals.

What a language server sees that Codex doesn't automatically

Type errors, unresolved imports, unused variables, and structural issues a language server catches through real static analysis are things Codex may or may not notice from reading the same code as plain text, depending on how carefully it's reasoning about it in a given turn. A language server's red squiggly underline is a hard, structural fact about the code; Codex's own assessment of whether code "looks right" is a different kind of judgment, informed by pattern-matching against a huge amount of code it's seen, not by actually type-checking your specific project the way the language server does.

Why this makes them worth running together, not choosing between

The strongest workflow uses both: let Codex propose and make changes, and let the language server's live diagnostics catch the class of structural mistake Codex might not surface on its own — an unresolved import in a new file, a type mismatch introduced by a signature change that touched more call sites than were actually updated. Checking your editor's diagnostics panel after a Codex session, not just reading the diff, is a cheap, fast way to catch a category of error that a diff review focused purely on "does this look reasonable" can miss.

Telling Codex about errors the language server already caught

Rather than describing a type error in your own words, copying the language server's actual error message and location into your instruction to Codex is usually more effective — it's the precise, structural information the language server already derived, handed directly to Codex instead of Codex having to re-derive the same thing from reading the code as text. This is a small habit that measurably improves how quickly a session fixes a real structural issue, since it skips a step Codex would otherwise have to do itself.

Performance interactions on a large project

A language server doing full project analysis and an agentic coding session both reading and writing files at once can compete for the same machine's resources on a genuinely large codebase, and a heavy language server re-indexing after every file write can make an editor feel sluggish exactly while a Codex session is making rapid changes. If this becomes a real friction point, checking whether your language server supports a lighter-weight or on-demand indexing mode is worth doing, rather than assuming the slowdown is Codex's fault when it's really the language server catching up to a burst of file changes.

Autocomplete and Codex are solving different problems

It's worth being clear that a language server's autocomplete and an agentic coding session are not the same category of tool, even though both can feel like "the editor is helping me write code." Autocomplete is fast, structural, and works a few tokens at a time as you type; Codex is slower, works at the level of whole changes across whole files, and can reason about intent in a way autocomplete fundamentally isn't built to do. Treating Codex as "a smarter autocomplete" undersells what it's actually for, and treating autocomplete as unnecessary once you have Codex ignores that they solve genuinely different, complementary problems at different points in how you write code.

When the language server disagrees with what Codex just did

If the language server flags a change Codex just made as an error, that's worth taking seriously as real, structural information rather than dismissing it — but it's also worth checking whether the language server itself is simply stale, still indexing after a large multi-file change, before assuming the flagged error reflects the current state of the code accurately. A quick restart or reload of the language server, or waiting for it to finish re-indexing, resolves a surprising number of "Codex just broke this" moments that turn out to be a diagnostic view that hadn't caught up yet.

A reasonable default workflow

Let Codex make a change, check the diagnostics panel before reading the diff in detail, feed any real errors back to Codex with the language server's own message included, and only move on to reviewing the diff itself once diagnostics are clean. That order — structural check first, human review second — catches the cheap, mechanical mistakes before spending your own attention on the more nuanced judgment calls a diff review actually needs.

Multi-file changes and diagnostic scope

A language server's diagnostics are usually scoped to open files or a currently-analyzed subset of the project, not the entire codebase continuously — which means a multi-file Codex change can introduce a structural issue in a file that isn't currently open in your editor, and the diagnostics panel simply won't show it until that file is opened or the project is fully re-analyzed. For a large refactor specifically, it's worth deliberately opening or triggering analysis on every touched file, not just the ones you happen to already have open, before trusting a clean diagnostics panel as a sign the whole change is structurally sound.

Language-specific quirks worth knowing about

Some language servers are more aggressive than others about surfacing warnings versus outright errors, and a session iterating against "no errors" as its bar for done can leave real warnings — a genuinely unused import, a deprecated API call — sitting unaddressed simply because the language server didn't treat them as blocking. Knowing your specific language server's conventions for what counts as an error versus a warning is worth understanding once, so you know whether "diagnostics are clean" from Codex's perspective matches what you'd consider clean from your own.