LSP integration (auto-detect + auto-install) for Codex CLI

What feature would you like to see?

Summary

Please add built-in Language Server Protocol (LSP) support to Codex CLI, including auto-detection and auto-installation of popular language servers. The goal is for Codex CLI to use LSP diagnostics and symbol intelligence to produce more precise, language- and project-aware code edits with minimal or zero manual setup.

Motivation / Problem

Codex CLI is often used on real repositories that are:

multi-language (frontend + backend + infra)
strongly typed / toolchain-driven (TypeScript, Go, Rust, C#, Java, etc.)
linted and configured per-project (eslint rules, tsconfig, deno.json, etc.)

Without structured feedback, the model can produce changes that:

fail type-checking or compilation (wrong imports/types/symbols)
violate project conventions/tooling config
require repeated manual cycles of build/test/lint to discover issues

LSP servers provide semantic diagnostics + code intelligence. If Codex CLI can optionally leverage LSP signals during the edit loop, it becomes significantly more reliable.

Proposal

Add an LSP Manager to Codex CLI with:

Auto-detection based on file extensions and project markers (package.json, deno.json, go.mod, etc.)
A built-in server mapping (language -> LSP server + install strategy + requirements)
Auto-install (opt-in by default, or prompted) for servers that can be installed automatically
Lifecycle management (start/stop, per-workspace, prefer stdio transport)
Document sync (didOpen/didChange/didSave)
Use LSP output as feedback for code edits:
- publishDiagnostics (must)
- document/workspace symbols, definition/references (high value)
- optional: hover/signatureHelp

CLI / UX suggestion

codex --lsp=auto (or --lsp=on), codex --lsp=off
codex lsp status (which servers detected, installed, running)
codex lsp diagnostics [--file path] (print diagnostics used by Codex)
Optional: codex fix --with-lsp (iterate until diagnostics improve / are clean)

Built-in LSP server matrix (target scope)

Codex CLI should ship with a curated built-in list like:

LSP Server	Extensions	Requirements / Install behavior
astro	.astro	Auto-installs for Astro projects
bash	.sh, .bash, .zsh, .ksh	Auto-installs bash-language-server
clangd	.c, .cpp, .cc, .cxx, .c++, .h, .hpp, .hh, .hxx, .h++	Auto-installs for C/C++ projects
csharp	.cs	.NET SDK installed
clojure-lsp	.clj, .cljs, .cljc, .edn	clojure-lsp command available
dart	.dart	dart command available
deno	.ts, .tsx, .js, .jsx, .mjs	deno command available (auto-detect deno.json/deno.jsonc)
elixir-ls	.ex, .exs	elixir command available
eslint	.ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, .cts, .vue	eslint dependency in project
fsharp	.fs, .fsi, .fsx, .fsscript	.NET SDK installed
gleam	.gleam	gleam command available
gopls	.go	go command available
jdtls	.java	Java SDK (version 21+) installed
kotlin-ls	.kt, .kts	Auto-installs for Kotlin projects
lua-ls	.lua	Auto-installs for Lua projects
nixd	.nix	nixd command available
ocaml-lsp	.ml, .mli	ocamllsp command available
oxlint	.ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, .cts, .vue, .astro, .svelte	oxlint dependency in project
php intelephense	.php	Auto-installs for PHP projects
prisma	.prisma	prisma command available
pyright	.py, .pyi	pyright dependency installed
ruby-lsp (rubocop)	.rb, .rake, .gemspec, .ru	ruby and gem commands available
rust	.rs	rust-analyzer command available
sourcekit-lsp	.swift, .objc, .objcpp	swift installed (xcode on macOS)
svelte	.svelte	Auto-installs for Svelte projects
terraform	.tf, .tfvars	Auto-installs from GitHub releases
tinymist	.typ, .typc	Auto-installs from GitHub releases
typescript	.ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, .cts	typescript dependency in project
vue	.vue	Auto-installs for Vue projects
yaml-ls	.yaml, .yml	Auto-installs Red Hat yaml-language-server
zls	.zig, .zon	zig command available

This is the “built-in” experience requested: detection + install + run handled by Codex CLI without users wiring it manually.

Installation model (recommended)

Install servers into a Codex-managed cache directory (per-user), pinned versions.
Prefer official distribution channels:
- npm-based servers (typescript-language-server, bash-language-server, yaml-language-server, etc.)
- GitHub releases for binaries (terraform-ls, tinymist, etc.) with checksums
- Respect “project-provided” servers when present (eslint/ts in node_modules, pyright dependency, etc.)
Provide safe defaults and clear logs:
- prompt before downloads, or allow --yes for non-interactive installs
- allow --lsp=off to disable all LSP activity

Acceptance criteria

codex --lsp=auto detects language(s) and starts appropriate server(s) or explains unmet requirements.
For supported auto-install servers, Codex CLI can install them and cache them.
Codex CLI can surface or internally use LSP diagnostics for edited files.
Optional “fix loop”: improve patches using diagnostics until stable/clean or max iterations reached.
Graceful fallback when a server is missing/unavailable, without breaking Codex CLI.

Security / Privacy considerations

LSP processes run locally and only access the workspace.
Clear opt-in behavior for downloads and execution.
Ability to disable LSP entirely and to view which commands are being executed.

Additional information

Primary use cases

Multi-language repos (e.g., TS + Python + Terraform)
Large refactors where symbol navigation/definitions matter
Reducing trial-and-error cycles with build/lint/test

Environment

OS: macOS (can also test on Linux if needed)
Common toolchains available depending on repo: Node/npm, Go, Rust, .NET, Java

This is the best proposal ever!

Thanks for the suggestion. Can you clarify what you see as the primary benefits that you want to see out of this feature? You can already tell Codex to run a linter or type checker in your AGENTS.md, and it will dutifully do so. The acceptance criteria are very much focused on the mechanism rather than the outcome.

I'm a big fan of LSPs (I'm the author of pyright, a popular LSP for Python), but the language server protocol was not designed for coding agents, and it's not clear LSPs are a good match here. We've experimented with the idea, and it hasn't provide the benefits that I initially thought it might.

Thanks for the response — and totally fair point about AGENTS.md: running linters/typecheckers can cover a lot of the value already.

The primary benefits I’m aiming for are:

Lower-latency, structured feedback: LSP diagnostics are incremental and file-scoped, which could reduce expensive “run the whole lint/typecheck” loops after each patch (especially in large repos).
Semantic signals for safer refactors: beyond diagnostics, LSP offers standardized symbols/definitions/references that can help keep edits consistent during multi-file changes.
A consistent interface across ecosystems: one protocol surface for “errors + symbols”, while still letting projects choose their underlying toolchain.

Given your note that LSP hasn’t provided the benefits you expected in prior experiments, I’m happy to narrow this to a small, mechanism-focused, opt-in experiment:

codex --lsp=on (default off)
start with diagnostics only for files Codex edits (stdio servers, lifecycle + document sync)
user-configured server command (no built-in auto-install initially)
evaluate whether it reduces iterations/tool runs vs AGENTS.md workflows

If you’re willing, I’d also love to hear what specifically didn’t work well in your LSP experiments (stale/noisy diagnostics, workspace sync, performance, etc.) so the proposal can avoid those pitfalls.

@etraut-openai

Can you clarify what you see as the primary benefits that you want to see out of this feature?

@etraut-openai, Let’s suppose I want to rename some method of a class which my code uses a lot. As far as I know, LSP makes renaming a semantic operation (symbol + references), while renaming without LSP usually degenerates into a bunch of grep-like searches and heuristics that can be noisy and sometimes wrong (aliases, same names in different scopes, re-exports, shadowing, etc.).

More generally, the thing I’m after is not “LSP for LSP’s sake”, but reliable semantic refactors / navigation primitives that an agent can call:

“find all references / implementations of this symbol” (not just text matches),
workspace-wide rename that produces one coherent set of edits,
move symbol/file and update imports safely,
quick access to symbol info (definition, signature) without the agent having to open/read a large number of files.

Running a linter/type checker from AGENTS.md is useful as a verification step, but it doesn’t really replace those semantics. It tells you what broke after the fact; it doesn’t give you a precise map of what needs to change (or reduce false positives) when planning a large refactor.

How was this experiment going? https://github.com/ktnyt/cclsp

@etraut-openai

Hi, codex community, if you guys interested, can checkout my tool: https://github.com/allenanswerzq/llmcc it should be better than what LSP can provide. It can provide a very clear architectual view in a very faster speed in one shot. for codex code repo, its only took like 0.5s for the whole repo.

check this folder out for codex, https://github.com/allenanswerzq/llmcc/tree/main/sample/rust/codex-pagerank especially check this one: https://github.com/allenanswerzq/llmcc/blob/main/sample/rust/codex-pagerank/depth_3_file.svg (download view in brower). I felt it produces a very good structure of codex internally, coding agents should be very quickly to grasp the architecture.

more words would be (lsp/grep) scope is very small and needs many many rounds of back and forth, we need project architectual view (llmcc+grep) to truly understand a codebase (no rag stuff, very slow and lag updates).

@etraut-openai sir would you mind to take a look, see if it something worth spend more time on, thanks in advance.

example (one shot/seconds time): code agents can quickly understand the codebase in seconds for main components and where they are.

example (one shot/seconds time): if we want to make some chagnes to how promopts gets handled, what places should we looking into you think

wrote a discussion page as well: #8955

@allenanswerzq

@allenanswerzq, this is a really interesting idea! Thanks for sharing. I haven't had time yet to play with it, but it looks promising. Do you have any concrete tests that compare common agentic coding tasks with and without the additional information provided by llmcc?

@etraut-openai

@etraut-openai sir, thank you for your time checking it. thats good idea to do some comparsions, right now I dont have.,

as far as i know, most people use SWE-bench, which is more fouced on getting tasks done (largely depends on model ability). not measure how efficiently(number of too calls/token used/time spent etc.) it gets task done. so very trick to do comparsions.

I can think of is to generate a few tasks(coding or understaring), big and small, lets say based on codex repo. then collect some stats to see, i will try to see if I can have more clear trustworth results.

feat: Add LSP integration for language-aware code edits

@etraut-openai

@etraut-openai
About LSP support

Currently, checking TypeScript errors via npm run type-check in an enterprise project repository may take 10–20 minutes.
This makes Codex unusable in many cases.

Cursor, OpenCode, and Claude Code can check these errors via LSP in milliseconds.

As a fast way of implementation, we could simply update the Codex VSCode extension to expose VSCode linter errors and warnings via MCP
like it’s done for Claude Code.
The Claude Code VSCode extension provides access of linter errors to CC via mcp__ide__getDiagnostics().
As a result, it works much, much faster.
If Codex could do the same, it would be a huge advantage.

What do you think about https://lsp-client.github.io/LSAP/ ?

Claude code has built-in LSP support since 2.0.74

2.0.74
Added LSP (Language Server Protocol) tool for code intelligence features like go-to-definition, find references, and hover documentation

As far as I could tell, it reduce both token usage and latency especially for large codebase with multiple overload and heritage. Please do consider add this feature.

I am really astonished that this is not yet done. Specifically for large code refactors LSP's are essential!
All folks from the AI labs out here saying that you can build anything with them coding agents, yet fail to close the gap that the community is asking for since ages!

@nullbio

@nullbio @esoxjem Not saying this fixes this issue; I would much rather have fast, lightweight, native integration. But I open sourced a work-around for Serena that I personally use: https://github.com/costleya/serena-shared-mcp

It's not perfect. But it does make it so I have 1 2GB node process per branch instead of like 8 (per subagent), and aggressively closes them.

@etraut-openai

@nullbio @esoxjem Not saying this fixes this issue; I would much rather have fast, lightweight, native integration. But I open sourced a work-around for Serena that I personally use: https://github.com/costleya/serena-shared-mcp

It's not perfect. But it does make it so I have 1 2GB node process per branch instead of like 8 (per subagent), and aggressively closes them.

Thank you. Crazy that this still hasn't been done by OpenAI themselves though. How long has Anthropic had built-in LSP? A year? @etraut-openai is this on the todo list?

@etraut-openai

I found this whole discussion randomly while researching LSP's impact on coding harnesses. I made a vidya on it, https://www.youtube.com/watch?v=DM75WbP16Vk hope you don't mind folks @etraut-openai do you still find this to be the case? Did you ever explore the direction that @allenanswerzq suggested?

Curious to know. Great discourse :)

feat(lsp): diagnostics-only stdio client behind opt-in config (refs o…

Still nothing? Really? I guess we still want to do ctrl+shift+f style search in millions of lines of code instead of simple "find references"...

I built a small diagnostics-only Stage 1 prototype to make this discussion more concrete:

https://github.com/MartinCajiao/codex/tree/lsp-diagnostics-8745-v2

This is a reference experiment, not a claim that the full proposal is solved. It currently provides:

one persistent stdio language-server process per client/workspace
initialize / initialized with a real workspace URI
didOpen followed by versioned full-text didChange
matching JSON-RPC responses by ID while handling intermediate notifications and basic server requests
a clear distinction between a clean diagnostics publication (Some([])) and no publication before the timeout (None)
stale-diagnostics filtering, bounded diagnostic output, graceful shutdown, and kill-on-drop
cancellation-safe LSP framing with header/message size limits
URI handling through Codex's existing PathUri utility

Validation on the current Codex main branch:

just fmt
just fix -p codex-lsp
just test -p codex-lsp: 17/17 tests passing
in-memory fake-server tests cover initialization ordering, server requests, empty diagnostics, timeouts, repeated document updates, stale versions, partial-frame cancellation, and oversized frames

Not implemented yet: agent-loop integration, server auto-detection/install, symbols, references, or rename. The next useful step would be an outcome-oriented benchmark against the existing “run the configured linter/type checker” workflow—latency, number of verification cycles, and edit success rate on large repositories—before expanding the mechanism.

Strong +1. I think this is more important than a convenience feature: first-class LSP can become a low-cost semantic substrate for the agent loop.

Claude Code's current "code intelligence" model is a useful reference point: connect to language servers, surface diagnostics after edits, and query definitions / references / type information on demand. The important part is not merely IDE parity; semantic lookup often replaces broad file reads and grep-driven exploration, so it can improve both correctness and context/token efficiency.

For Codex, I would especially like to see:

Native symbol navigation: definition, references, workspace/document symbols, hover/type info.
Post-edit diagnostics: automatically surface new type errors / warnings after a patch, before a full build/test cycle.
Agent-loop integration: make LSP queries cheap first-class tools rather than raw protocol plumbing the model has to discover/configure.
Remote-aware lifecycle: when Codex is attached to a remote SSH host/container/workspace, the language server should run in that same execution environment and see the same filesystem/toolchain.
Workspace-level manager/status: show which LSPs are active, where they run, failures/restarts, and allow enable/disable/restart.
Prefer project-provided servers/toolchains when available, with managed install as an explicit fallback rather than surprising global mutation.
Graceful degradation: LSP failure should never block the agent; fall back to text search/build/test.

The remote point matters a lot for real Codex workflows: running Pyright/clangd/rust-analyzer on the local Mac while the actual project, dependencies, generated files, Python env, compile database, etc. live on a remote Linux GPU box is often incorrect. LSP should bind to the same workspace abstraction as shell execution.

One useful design principle would be:

text search      → lexical discovery
LSP              → semantic discovery / fast diagnostics
build/test       → authoritative validation

Those layers complement each other rather than replacing one another.

Claude Code docs currently describe code intelligence as language-server-backed symbol navigation plus live diagnostics, with low context overhead because symbol lookup can replace broad file reads:
https://code.claude.com/docs/id/features-overview

I think this would be one of the highest-leverage improvements to Codex's day-to-day coding quality, especially on large Python/C++/Rust/TypeScript/Java repos and remote development.

ai_docs: make the code-navigation MCP adapter required, not optional

For anyone who wants this today without waiting for native support: I built it on top of the hooks API that Codex already ships. It's called agent-squiggles.

PreToolUse / PostToolUse on apply_patch|Bash snapshot the working tree as git trees, using a private index. The index, branches and stash are untouched.
For each changed file, the language server is shown the old text and then the new text. Only the diagnostics the edit introduced are returned as additionalContext, including breakage in files the model never opened. Pre-existing errors are filtered out with a line-mapped diff, so large legacy codebases don't flood the context.
It auto-detects Go (gopls), TypeScript/JS (TypeScript 7 native tsc --lsp, or typescript-language-server for TS ≤ 6) and Python (pyright/basedpyright), and installs missing servers into its own directory.
A per-workspace daemon keeps the servers warm. Typical checks take tens of ms (TS 7) to a few hundred ms (gopls).

A few notes from building it that may help whoever implements this natively:

decision: "block" on PostToolUse turns the tool call into a failure (FunctionCallError::RespondToModel), so the model may believe its patch didn't apply. additionalContext works better for "your edit succeeded but broke X".
gopls does not re-publish unchanged diagnostics, so waiting for publishDiagnostics after an edit can stall. The synchronous gopls.diagnose_files command is a reliable settle point.
TypeScript 7's native server is pull-only (textDocument/diagnostic); nothing is pushed.
Hooks run outside the sandbox, so anything that executes project-local binaries (node_modules/.bin/tsc, a virtualenv's interpreter) should respect project trust.

Feedback and bug reports are very welcome.

+1

@etraut-openai

One number from this thread answers part of @etraut-openai's question about outcomes: in SproutSeeds' narrow test (diagnostics added to apply_patch output only), checker runs before the first useful error went from 1 to 0 in 12 of 12 tasks, and it was faster in 0 of 12. So the case is fewer wrong turns, not speed.

That suggests a small first version:

After apply_patch, show only the errors that edit introduced, not every old warning.
Use a language server already in the project or on PATH. No auto-install.
Off by default.

agent-squiggles (linked above) already does roughly this through existing hooks, so it may not need a new subsystem. A fair test: fewer edit → build → fix loops on typed repos with no drop in success rate. If that doesn't show up, rename and navigation features probably won't justify more machinery either.

Strong support for native LSP integration.

I see LSP as providing complementary intelligence, rather than simply another mechanism for linting or compilation.

AI agents offer reasoning about intent, architecture and design. Language servers offer authoritative semantic information about symbols, types, scope, references and dependencies.

Combining these capabilities would help an agent understand the precise boundaries and implications of a proposed change before editing code, not merely discover errors afterwards.

This is particularly valuable in languages and environments where substantial dependency information is available through compiled symbols rather than directly accessible source code, such as Microsoft Dynamics 365 Business Central AL.

I believe the greatest benefit would come from treating LSP as an additional source of structured knowledge throughout the agent's reasoning process.

Following up with numbers, since the open question in this thread is outcomes rather than mechanism (comment).

I ran a small, placebo-controlled eval of the hook-based approach I linked above (agent-squiggles: diagnostics for the errors an edit introduced, after each apply_patch/shell edit). Six typed multi-file tasks in Go, TypeScript, Python and Rust, built so a missed caller is plausible: calls through renamed re-exports and aliased imports, a Get among a dozen unrelated .Get( calls, a TS project whose tsc already fails on ~40 known errors. Every task has an AGENTS.md naming the checker to run. Both conditions have the same hooks installed and the same flags; in the baseline the hooks are switched off.

gpt-5.6-luna, medium, 36 runs:

Success: 18/18 vs 18/18. Time and tokens: no difference (35 s vs 36 s per run).
Runs where a compile/type error reached the build, type-check or test step: 3/18 baseline vs 0/18 with diagnostics.
The 6 times diagnostics fired, the model fixed the errors before its first checker run. The clearest case: in all 3 baseline runs of one Python task, Codex updated the production callers, ran the tests, and only then fixed the stale calls in the test file; in 2 of the 3 diagnostics runs it made the same first edit, was told about the test file, and fixed it before running the tests.

So it agrees with SproutSeeds' measurement earlier in this thread: fewer wrong turns, not speed. And the effect is small with a strong model on small repositories, because it usually finds every caller on its own; it would matter more where the checker is slow. 18 runs per condition is not much, so take it as a direction rather than a conclusion.

Method, raw JSONL and per-run notes (including two bugs an earlier batch found in my implementation): https://github.com/wpkc0429/agent-squiggles/tree/main/eval

If anyone has a task that tends to trip Codex up in a typed codebase, I'm happy to add it.

For anyone who wants this before it lands natively: I built symbolhop, an MCP server that gives Codex read-only lsp_definition, lsp_references, lsp_hover, lsp_diagnostics and lsp_symbols from whatever language servers are on your PATH (clangd, pyright, gopls, rust-analyzer, typescript-language-server…), picked per file. Symbols are given by name, so the model doesn't need column numbers.

One measurement, on a made-up C project: finding a function's uses returned 10 exact lines through symbolhop, against 59 to 77 from grep, 49 to 67 of them not uses, so about 9 to 11 times fewer tokens. That's the best of three questions; the other two came out about 4x and 2–3x. The script is in bench/ and CI reruns it. So far only clangd has been exercised live.

Setup in ~/.codex/config.toml:

[mcp_servers.symbolhop]
command = "npx"
args = ["-y", "github:stanczykwyatt/symbolhop#v0.1.0", "serve"]

It never writes files and has no dependencies or network access. MIT. Not a replacement for native support with auto-install, just something that works today.

Navigation Menu

Repository navigation

LSP integration (auto-detect + auto-install) for Codex CLI #8745

What feature would you like to see?

Summary

Motivation / Problem

Proposal

CLI / UX suggestion

Built-in LSP server matrix (target scope)

Installation model (recommended)

Acceptance criteria

Security / Privacy considerations

Additional information

Primary use cases

Environment

example (one shot/seconds time): code agents can quickly understand the codebase in seconds for main components and where they are.

example (one shot/seconds time): if we want to make some chagnes to how promopts gets handled, what places should we looking into you think

55 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

LSP integration (auto-detect + auto-install) for Codex CLI #8745

Description

What feature would you like to see?

Summary

Motivation / Problem

Proposal

CLI / UX suggestion

Built-in LSP server matrix (target scope)

Installation model (recommended)

Acceptance criteria

Security / Privacy considerations

Additional information

Primary use cases

Environment

Activity

medz commented on Jan 6, 2026

etraut-openai commented on Jan 6, 2026

danielsacosta commented on Jan 6, 2026

Oktai15 commented on Jan 6, 2026

bhack commented on Jan 6, 2026

allenanswerzq commented on Jan 9, 2026

example (one shot/seconds time): code agents can quickly understand the codebase in seconds for main components and where they are.

example (one shot/seconds time): if we want to make some chagnes to how promopts gets handled, what places should we looking into you think

allenanswerzq commented on Jan 9, 2026

etraut-openai commented on Jan 13, 2026

allenanswerzq commented on Jan 13, 2026

it-sha commented on Jan 28, 2026

bhack commented on Jan 28, 2026

hadrianWang commented on Jan 30, 2026

55 remaining items

philikai commented on Aug 13, 2026

costleya commented on Aug 14, 2026

nullbio commented on Aug 15, 2026

ScottRBK commented on Sep 8, 2026

snakex64 commented on Sep 18, 2026

MartinCajiao commented on Sep 21, 2026

abcjhby2871 commented on Sep 24, 2026

wpkc0429 commented on Sep 30, 2026

tsarenkotxt commented on Oct 15, 2026

balabommablock-cpu commented on Oct 21, 2026

Development-Acciobiz-Ltd commented on Oct 21, 2026

wpkc0429 commented on Oct 22, 2026

stanczykwyatt commented on Oct 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions