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: 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,
Posted by danielsacosta on Jan 5, 2026, 4:56 PM
Tags
Related issues
- ⚠️ PHP CVEs. Update required!
- I think RTS could continue to work if someone made a massive leap of faith and put all the modern infra around it that a AAA extraction s...
- RFC: Pluggable SessionDB Provider — PostgreSQL, MySQL, and Beyond
- v2.1.113+ broken on Termux/Android: native binary requires glibc, no JS fallback
- I’m firmly anti-Tahoe and haven’t updated, and I’ve started to find Apple despicable.
- [FEATURE] Link a source control repo as the source for organization skills
Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments
reliability (Sysadmin)
⚠️ PHP CVEs. Update required!
I think RTS could continue to work if someone made a massive leap of faith and put all the modern infra around it that a AAA extraction s...
RFC: Pluggable SessionDB Provider — PostgreSQL, MySQL, and Beyond
v2.1.113+ broken on Termux/Android: native binary requires glibc, no JS fallback
I’m firmly anti-Tahoe and haven’t updated, and I’ve started to find Apple despicable.
[FEATURE] Link a source control repo as the source for organization skills
Feature Request: Option to disable paste text collapse in input field
We went down the WASM sandboxing rabbit hole at Gobii when building our agent infra.
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: 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,
Comments (0)
No comments yet. Start the discussion.