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

[Daniel-Santiago-Acosta-1013]

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:

1. Auto-detection based on file extensions and project markers (package.json, deno.json, go.mod, etc.)
2. A built-in server mapping (language -> LSP server + install strategy + requirements)
3. Auto-install (opt-in by default, or prompted) for servers that can be installed automatically
4. Lifecycle management (start/stop, per-workspace, prefer stdio transport)
5. Document sync (didOpen/didChange/didSave)
6. 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

[medz]

This is the best proposal ever!

[etraut-openai]

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.

[Daniel-Santiago-Acosta-1013]

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:

1. 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).
2. Semantic signals for safer refactors: beyond diagnostics, LSP offers standardized symbols/definitions/references that can help keep edits consistent during multi-file changes.
3. 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.

[Oktai15]

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:

1. “find all references / implementations of this symbol” (not just text matches),
2. workspace-wide rename that produces one coherent set of edits,
3. move symbol/file and update imports safely,
4. 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.

[bhack]

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

[allenanswerzq]

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

[allenanswerzq]

wrote a discussion page as well: #8955

[etraut-openai]

@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?

[allenanswerzq]

@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.

[it-sha]

@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.

[bhack]

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