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

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

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.

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

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.

<img width="775" height="673" alt="Image" src="https://github.com/user-attachments/assets/6389020b-9e2d-4b6a-8905-e44e50146e3c" />

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

<img width="951" height="670" alt="Image" src="https://github.com/user-attachments/assets/28d67073-45a8-40da-a92b-ed2080f233be" />

wrote a discussion page as well: https://github.com/openai/codex/discussions/8955

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

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

+1 for LSP integration. Our team is really missing this feature compared to the OpenCode and Claude Code, which keeps us away from using Codex CLI.

meanwhile claude code team is asking others whether LSP can be useful: https://x.com/jarredsumner/status/2017704989540684176

I assume the desktop app will also have the LSP support after this proposal is implemented.

Hi, I reviewed 'Built-in LSP integration (auto-detect + auto-install) for Codex CLI to enable language-aware edits' and can start immediately. I can deliver a first usable version quickly and iterate based on your feedback. If this scope still matches your priority, I can proceed right away.

LSP integration is already critical for our team — without it, work in our large codebase is slower and refactors are less reliable. We’re actively discussing moving to Claude Code, and while we tested OpenCode too, it still doesn’t cover all our requirements. We love Codex and really hope to see LSP implementation soon.

You'd think they'd be eager to add LSP support just for the token savings...

LSP's absolutely benefit coding agents. Claude and OpenCode with LSP support both spot issues while writing the files rather than having to write everything then build only to find out it's not right, redoing it, finding it's wrong again. It stops most silly coding agent issues before they even become a problem.

I just swapped to Codex from Claude and it's night and day how much more efficient Codex is with LSP support in OpenCode vs the Codex client with no LSP. I'd much rather use the Codex client but it's really not worth it for me without LSP support.

+1 for LSP support for codex

Claude with lsp seem to work with codebase way better

still no LSP? We are living in stone age?

Has anyone found any success with Serena in Codex?
https://github.com/oraios/serena

Are we getting LSP support on Codex anytime soon

+1 for LSP support for codex

While still no official support, any alternatives?

I experimented with implementing this feature and have a working prototype in my fork.

Implementation:
https://github.com/nguyenphutrong/codex/pull/2

The prototype adds a basic LSP manager to the CLI and demonstrates how Codex can consume LSP diagnostics during the edit loop. The current version focuses mainly on:

• Detecting language servers based on project files / extensions
• Spawning and managing LSP processes via stdio
• Collecting "publishDiagnostics" from the server and feeding them back into the iteration loop

This is still an early implementation and doesn't yet cover the full matrix of servers or auto-install logic described in the proposal, but it should demonstrate the core integration pattern.

Since I don't have permission to open a PR directly against "openai/codex", I'm sharing the implementation here in case it’s useful for discussion or as a reference for a future upstream implementation.

Happy to adapt the approach or open a proper PR if maintainers think this direction makes sense.

Is this happening anytime soon? At this point its my only reason to use Opencode or Cursor instead of this

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

Using the LSP for things like renaming a field, jumping to definition/implementation are obvious benefits for the efficiency of the agent loop. Choosing any other option that burns more tokens and is less precise sounds like trying to harvest more money from the customer.

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.

@etraut-openai

I agree the standard should be outcome, not mechanism. The case for LSP is not "it would be nice to have editor tech inside Codex", but "does it materially outperform the current AGENTS.md + lint/typecheck loop on the tasks Codex is actually asked to do?"

My view is that LSP helps in two places that batch checkers do not:

1. Incremental diagnostics during the edit loop

A linter/typechecker in AGENTS.md is post-hoc: edit first, then run the checker, then interpret the result, then iterate.

LSP diagnostics can surface file-scoped breakage immediately after an edit. That changes the loop from:

• edit
• run full checker
• inspect failure
• patch
• rerun

into something closer to:

• edit
• immediately see the affected errors
• fix them in the same turn

So the expected benefit is fewer iterations, fewer shell calls, and faster convergence, especially in typed repos.

1. Semantic navigation/refactor signals

AGENTS.md can tell Codex to verify with tools, but it does not give Codex better primitives for planning the edit itself.

For tasks like:

• changing a function signature and updating callers
• renaming a symbol across many files
• tracking references/implementations
• resolving imports/types in large typed codebases

definition/references/symbol queries are qualitatively different from grep + file reading. They are lower-latency and more precise.

So I don't see LSP as replacing the existing checker flow. I see it as complementing it:

• LSP for low-latency semantic feedback during editing
• lint/typecheck/tests for final validation

I also agree this should probably be evaluated as a small experiment, not as a large feature pitch.

I implemented a working prototype in my fork here:

• https://github.com/nguyenphutrong/codex/pull/2

The current prototype focuses on the narrow core:

• spawning/managing LSP processes
• syncing touched documents
• collecting publishDiagnostics
• feeding diagnostics back into the edit loop
• exposing a small LSP query surface

I intentionally see the built-in server matrix / auto-install story as secondary. The real question is whether the integration pattern itself improves outcomes.

If this direction is interesting, I'd be happy to split this into smaller upstreamable pieces rather than propose one large PR. A reasonable sequence might be:

1. opt-in experimental LSP plumbing
2. diagnostics for touched files only
3. a minimal semantic query surface
4. only later, if justified, broader runtime/install UX

I'd also be happy to back this up with a reproducible benchmark instead of arguing from intuition:

• baseline Codex + AGENTS.md + checker loop
• Codex with LSP diagnostics
• optionally Codex with full semantic LSP access

Metrics I think matter:

• task success rate
• iterations to green
• shell/checker churn
• wall-clock time
• performance specifically on typed multi-file refactor tasks

If you think that narrower experimental scope is worth evaluating, I'd be glad to open a proper upstream PR and/or break my fork into reviewable pieces.

I don’t think insisting on LSP support for Codex is the right long-term bet.

LSP was designed for IDEs, not for autonomous coding agents. It depends on constant state synchronization and mostly works with line/column positions instead of stable semantic identifiers. That is manageable in an editor, but brittle for an LLM that is constantly editing files and reasoning across many steps. After every change, positions shift, state has to be re-synced, and the whole interaction becomes fragile.

On top of that, LSP payloads are often a poor fit for LLMs: too verbose, too tied to editor protocols, and too easy to turn into token bloat. You can patch around some of this, but the core mismatch remains.

A better approach is to build agent-native tooling per language: a stateful MCP server that watches file changes, preserves semantic state, and exposes operations using stable symbol keys. That gives the model something much closer to how human developers actually work in a serious IDE.

I built a similar server for .NET because agents were failing badly in my day job repository, around 2.5M LOC. The improvement was huge. For large codebases, the gap is basically the same as asking a developer to work in Notepad versus Rider or Visual Studio. Same codebase, same task, completely different outcome.

So in my view, LSP is fine as a bridge, but not a real foundation for agentic development.

I would love to see your implementation of MCP server and how it has significantly improved your workflow

Maybe using your approach I can implement it for my own typescript codebase

I would love to see your implementation of MCP server and how it has significantly improved your workflow Maybe using your approach I can implement it for my own typescript codebase

It’s written in C# and it’s closed source, but you can still look at the tool set and the request/response contracts here: https://glidermcp.com/tools

I’m not sure whether any platform other than .NET currently has something comparable to the Roslyn compiler APIs with stable symbol keys. For JS/TS, that’s probably the first problem you need to solve.

After that, I’d start with search/navigation tools and a file watcher. Then spend time on tool descriptions and server instructions so the LLM actually uses your MCP effectively, which is trickier than it sounds.

> I would love to see your implementation of MCP server and how it has significantly improved your workflow > > Maybe using your approach I can implement it for my own typescript codebase It’s written in C# and it’s closed source, but you can still look at the tool set and the request/response contracts here: https://glidermcp.com/tools I’m not sure whether any platform other than .NET currently has something comparable to the Roslyn compiler APIs with stable symbol keys. For JS/TS, that’s probably the first problem you need to solve. After that, I’d start with search/navigation tools and a file watcher. Then spend time on tool descriptions and server instructions so the LLM actually uses your MCP effectively, which is trickier than it sounds.

Thanks for sharing this it looks pretty promising

I might implement it for as test for my own typescript codebase to see how much improvement can i get

Thanks — the strongest path here seems to be an outcome-focused experiment rather than a broad built-in LSP feature pitch.

A concrete way to evaluate this without overcommitting the design would be:

1. an opt-in, diagnostics-only experiment for touched files,
2. user-configured LSP server command(s) instead of a built-in server matrix,
3. no auto-install in the first pass,
4. comparison against the current AGENTS.md + lint/typecheck workflow on a small benchmark set of multi-file typed tasks.

The metrics that seem most relevant are:

• iterations to green,
• shell/checker churn,
• wall-clock time,
• and success rate on tasks like symbol renames, signature changes, and import/type repair.

There is already a helpful prototype in the thread from nguyenphutrong that appears to cover the narrow plumbing for process management + publishDiagnostics. If the team is interested, the highest-value next step may be a reproducible evaluation artifact around that narrower implementation, rather than jumping straight to the full built-in server / auto-install story.

I’d be happy to help structure that experiment so the question becomes “does this improve outcomes enough to justify the complexity?” rather than “should Codex have LSP because editors do.”

We pushed the narrowest version of this idea far enough locally to get past transport questions and into outcome questions.

What we tested locally was intentionally much narrower than the full issue ask:

• opt-in only
• diagnostics only
• no built-in server catalog
• no auto-install
• no hover / definition / references tools
• no shell integration
• diagnostics appended to apply_patch output only

Current local status:

• the reduced stdio LSP path is working locally
• real rust-analyzer diagnostics round-trip is now green
• the last blocker was a client lifecycle/shutdown issue, not the benchmark design

We ran four local benchmark phases:

1. synthetic micro-benchmark
2. synthetic multi-file fake-server benchmark
3. warmed real rust-analyzer benchmark
4. larger-workspace warmed real rust-analyzer benchmark

Aggregate result across 12 task comparisons:

• inline diagnostics appeared in apply_patch in every LSP-mode run
• checker runs before the first useful diagnostic dropped from 1 to 0 in 12/12
• inline diagnostics were faster in wall-clock in 0/12

So my current read is:

• this does make a credible case for earlier inline feedback and less checker churn
• it does not currently make a credible case for raw speedup
• that means the broad version of the issue is not well-supported by the current evidence yet
• but a much smaller first step, like opt-in diagnostics-only LSP enrichment, still looks plausible if the goal is a better edit workflow rather than lower wall-clock time

So I don’t think the local evidence says “LSP is a bad idea.”
I think it says “the strongest case right now is a narrow diagnostics-first slice, not the full auto-detect/auto-install/full-tooling version.”

Happy to summarize the local artifacts further if useful.

While still no official support, any alternatives?

What's stopping you using Opencode for this? It's already built-in https://opencode.ai/docs/lsp/

> While still no official support, any alternatives? What's stopping you using Opencode for this? It's already built-in https://opencode.ai/docs/lsp/

The fact it's run by a bunch of absolute assholes and the Codex client is 100x better.

But yes, using OpenCode will tell you one thing: LSP's absolutely help. Issues are caught much earlier and it stops the agent going on a wild ride, compiling then realising it messed up 4 steps ago.

I don't even know why there's a discussion on this. Literally just use OpenCode with an LSP for a week and you will realise that the difference is night and day.

Stop making light features like this a bureaucratic nightmare requiring benchmarks and studies. Add the support and gate it behind a switch. Your biggest competitors now all have this, given OpenAI's waning marketshare and relevance this is bit of a silly feature to block on.

I think LSP will increase the capabilities of AI agents.
Using grep/ripgrep and rag only understands the code from a textual perspective, while using LSP will understand the code from a structural perspective. Actually, I trust LSP.

> While still no official support, any alternatives? What's stopping you using Opencode for this? It's already built-in https://opencode.ai/docs/lsp/

Opencode doesn't have gpt 5.4 right now

> > While still no official support, any alternatives? > > What's stopping you using Opencode for this? It's already built-in https://opencode.ai/docs/lsp/ Opencode doesn't have gpt 5.4 right now

And also the cost difference for people without unlimited tokens for Openai models

> > > While still no official support, any alternatives? > > > > What's stopping you using Opencode for this? It's already built-in https://opencode.ai/docs/lsp/ > > Opencode doesn't have gpt 5.4 right now And also the cost difference for people without unlimited tokens for Openai models

I mean its the same subscription you can oauth into opencode with your chatgpt account

Opencode doesn't have gpt 5.4 right now

Yes it does. They added support in early March.

crazy it doesnt have LSP support! just figured it out. its a must

https://github.com/missdeer/ace-tool-rs
https://github.com/Agents2AgentsAI/ata
https://github.com/bartolli/codanna

In the meantime people can use this codex plugin for Rust LSP support: https://github.com/fedemagnani/rust-lsp-plugin

fwiw serena MCP can be used to provide a LSP for a variety of languages. I have it enabled in my global config and it easily adds LSP support for rust, typescript, and many others.

I think it's important to run the LSP server only once, sharing it with your IDE. A LSP server like rust-analyzer can be very heavy, and it would be totally unresonable to run it twice.

In this sense, the approach of vscode-mcp-server is probably the best one can do currently (at least for people using Codex in VSCode). It's inspired by Serena, but using VSCode to power the queries.

Another approach is to run the LSP servers in proxies/multiplexers like lspmux. That way, Codex and the IDE would both connect to the same LSP server independently. However this would require broad changes on each IDE plugin to run the multiplexer rather than the LSP server directly. This is unlikely to work well without coordination between multiple projects.

so right

Claude code uses LSP and it is very helpful. When codex will add it?

I used GPT-5.5 to run a planning task on a large-scale OSS, comparing it with and without codegraph as an LSP alternative. I checked token usage, runtime, and output quality, but honestly, there wasn’t a huge difference.

IMO, it feels like we might not even need an LSP anymore. Would love to see someone else test this out with an actual LSP!

I used GPT-5.5 to run a planning task on a large-scale OSS, comparing it with and without codegraph as an LSP alternative. I checked token usage, runtime, and output quality, but honestly, there wasn’t a huge difference. IMO, it feels like we might not even need an LSP anymore. Would love to see someone else test this out with an actual LSP!

What about execution task? Like new feature, bug fix and a refactor. I'd expect bug fix and refactor to be improved

I added a small read-only preflight helper for the detection/status part of this request in trace-to-skill@0.1.69:\n\n``bash\nnpx trace-to-skill@0.1.69 lsp-audit . --format json\n`\n\nIt does not auto-install or start LSP servers, so it is not a replacement for first-class Codex LSP integration. The goal is to give maintainers a safe readiness report today: detected languages, evidence files, whether matching server commands are executable on PATH, and install hints.\n\nInitial mapping covers TypeScript/JavaScript, Python, Go, Rust, Swift, Java, C/C++, Ruby, PHP, and C#. A fresh npm smoke on a temp TS+Python repo returned missing server install hints for typescript-language-server and pyright-langserver`.\n\nRelease: https://github.com/grnbtqdbyx-create/trace-to-skill/releases/tag/v0.1.69\nSchema: https://github.com/grnbtqdbyx-create/trace-to-skill/blob/main/schemas/lsp-audit-result.schema.json

Some LSP features are optimized for human IDE workflows and client-side rendering, not necessarily for agent review.

For example, hover is based on a document URI plus a cursor-like position:

{
  "textDocument": { "uri": "file:///path/to/file.ts" },
  "position": { "line": 42, "character": 17 }
}

That works well for an IDE, but an agent may need a more direct "get symbol info" tool that returns the symbol, type, docs, and nearby usage context.

Diagnostics have a similar issue. They usually point to a range and message:

{
  "uri": "file:///path/to/file.ts",
  "diagnostics": [
    {
      "range": {
        "start": { "line": 42, "character": 10 },
        "end": { "line": 42, "character": 20 }
      },
      "severity": 1,
      "source": "typescript",
      "message": "Type 'string' is not assignable to type 'number'."
    }
  ]
}

This is useful protocol data, but an agent often needs the relevant source snippet, surrounding context, and structured fix hints.

Semantic tokens are also optimized for editor performance. They are returned as a linear encoded integer stream:

{
  "data": [2, 5, 3, 0, 3, 0, 5, 4, 1, 0, 3, 2, 7, 2, 0]
}

This is a highly encoded, ordered linear structure. That is efficient for IDE rendering, but not very convenient for an agent trying to quickly inspect code structure.

But as Anders Hejlsberg said, language servers are very good at semantic search, which remains highly valuable for agents, especially when your repository has 500,000 lines of code.
It just needs some adjustments.

This would be an awesome feature to add, what is the status of it?

This really needs to happen - like Claude Code has. The LSP servers out in the wild are all very buggy and unreliable. PHP especially has no reliable LSP servers except bloated Serena.

Rofl. It's hilarious that this still isn't getting traction 7 months in.

GPT 5.6 may have earned you some grace but the fact is your coding agent is lacking one of the most basic features every single one of your competitors now have.

What? Still no built-in LSP?

+1