You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bumping this question ^ I'd like to hook in a custom LSP (Lexical for Elixir), and it seems the lsp key is not accepted in opencode.json. Maybe this feature is in flux?
Since it's not linked in the menu, I figured it probably was something still being worked on. You're doing great work guys; thanks so much.
That was irritating me too ... the linked documentation does not fit to the sst/opencode source. for instance the documentation refers to ~/.config/opencode/opencode.json as config file which is wrong for the sst/opencode (it is ~/.config/opencode/config.json).
Ask Claude Sonnet 4 to deliberately edit a file and introduce an error.
It does this and tells me that it is not being passed any lsp diagnostics
I open the file in NeoVim and confirm that Claude has indeed added an error, which is being highlighted as such by the typescript lsp running in NeoVim
I run opencode debug lsp diagnostics ./path/to/file/with/error.ts and get the output below, which looks fine to me:
opencode debug lsp diagnostics ./src/config/config.ts { "/home/david/projects/grace/packages/grace-core/src/config/config.ts": [ { range: [Object ...], message: "Type 'number' is not assignable to type 'string'.", severity: 1, code: 2322, source: "typescript", }, { range: [Object ...], message: "'z' is declared but its value is never read.", severity: 4, code: 6133, source: "typescript", }, { range: [Object ...], message: "'invalidCode' is declared but its value is never read.", severity: 4, code: 6133, source: "typescript", } ], }
Ask Claude Sonnet 4 to deliberately edit a file and introduce an error.
It does this and tells me that it is not being passed any lsp diagnostics
I open the file in NeoVim and confirm that Claude has indeed added an error, which is being highlighted as such by the typescript lsp running in NeoVim
I run opencode debug lsp diagnostics ./path/to/file/with/error.ts and get the output below, which looks fine to me:
opencode debug lsp diagnostics ./src/config/config.ts { "/home/david/projects/grace/packages/grace-core/src/config/config.ts": [ { range: [Object ...], message: "Type 'number' is not assignable to type 'string'.", severity: 1, code: 2322, source: "typescript", }, { range: [Object ...], message: "'z' is declared but its value is never read.", severity: 4, code: 6133, source: "typescript", }, { range: [Object ...], message: "'invalidCode' is declared but its value is never read.", severity: 4, code: 6133, source: "typescript", } ], }
Same. It's wried that when I run opencode debug lsp diagnostics <file path> it got me the issues I'm expecting, but when I use the program and even explicitly ask about any issues on that file using LSP, it doesn't report anything that is reported from the debug lsp command. Instead, it fallbacks to run tsc --noEmit ... command.
the way it works is when edit calls are made and it introduces an error we send those errors back to the LLMif you suspect it's not working you can try the following command opencode debug lsp diagnostics ./path/to/file/with/error.ts
Just curious how its different from calling tsc or any other cli tool to get errors? The issue is performance? You dont need to build go project for example, etc
still no way to enable the lsp for me in typescript. it is not auto enabled and I have no idea why. opencode debug lsp diagnostics ./path/to/file does return {} although neovim lsp reports issues in the file.
Reacted by Matthieu Joannon, Louis Dauvergne and frolovgo
I think this is caused by a timeout. When JDTLS starts it does a build (Maven/Gradle) and other setup stuff. That takes quite a bit depending on your project size. AFAIU OpenCode has a timeout of 10s, which is too short. I'm currently experimenting with running JDTLS outside OpenCode and have it connect to it instead.
Activity
thdxr commentedon Jul 5, 2025
the way it works is when edit calls are made and it introduces an error we send those errors back to the LLM
if you suspect it's not working you can try the following command
opencode debug lsp diagnostics ./path/to/file/with/error.tsolk commentedon Jul 13, 2025
No additional configuration for LSP support (as described here https://pkg.go.dev/github.com/sst/opencode#readme-lsp-language-server-protocol) is required?
giddie commentedon Jul 18, 2025
Bumping this question ^ I'd like to hook in a custom LSP (Lexical for Elixir), and it seems the
lspkey is not accepted inopencode.json. Maybe this feature is in flux?adamdotdevin commentedon Jul 18, 2025
this is the other opencode; @thdxr will add custom lsp config soon
giddie commentedon Jul 18, 2025
Just FYI, the docs I found were linked from this repo. It popped up when I searched for LSP: https://opencode.ai/docs/lsp-servers
Since it's not linked in the menu, I figured it probably was something still being worked on. You're doing great work guys; thanks so much.
olk commentedon Jul 18, 2025
That was irritating me too ... the linked documentation does not fit to the sst/opencode source. for instance the documentation refers to ~/.config/opencode/opencode.json as config file which is wrong for the sst/opencode (it is ~/.config/opencode/config.json).
davidfriar1 commentedon Jul 19, 2025
This is not working for me. I do the following:
opencode debug lsp diagnostics ./src/config/config.ts { "/home/david/projects/grace/packages/grace-core/src/config/config.ts": [ { range: [Object ...], message: "Type 'number' is not assignable to type 'string'.", severity: 1, code: 2322, source: "typescript", }, { range: [Object ...], message: "'z' is declared but its value is never read.", severity: 4, code: 6133, source: "typescript", }, { range: [Object ...], message: "'invalidCode' is declared but its value is never read.", severity: 4, code: 6133, source: "typescript", } ], }alvis commentedon Aug 9, 2025
Same. It's wried that when I run
opencode debug lsp diagnostics <file path>it got me the issues I'm expecting, but when I use the program and even explicitly ask about any issues on that file using LSP, it doesn't report anything that is reported from the debug lsp command. Instead, it fallbacks to runtsc --noEmit ...command.@thdxr any clue?
jgordijn-ah commentedon Dec 20, 2025
I tried this on the
Pet.javafile, which has a syntax error:The result is an empty json?
istarkov commentedon Dec 21, 2025
Just curious how its different from calling tsc or any other cli tool to get errors? The issue is performance? You dont need to build go project for example, etc
finnzio commentedon Dec 29, 2025
I think we should add the Node-related executables directory to the environment, for example:
export PATH=/home/user/.local/share/opencode/bin/node_modules/.bin:$PATH
After setting this, my Vue diagnostics can run properly. Previously, it was failing with a "command not found" error when LLM call lsp_diagnostics.
thdxr commentedon Mar 25, 2026
To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.
feat: add MCP health-check hook (anomalyco#711)
uloco commentedon Apr 28, 2026
still no way to enable the lsp for me in typescript. it is not auto enabled and I have no idea why. opencode debug lsp diagnostics ./path/to/file does return {} although neovim lsp reports issues in the file.
LouiFi commentedon May 4, 2026
Hi, I found a fix where I used typescript-language-server locally with bun. Now the LSP works :
Here is my config, hope it will work for you :
feat(opencode-router): add first-class media transport for Slack and …
kleberm91 commentedon May 18, 2026
I think this is caused by a timeout. When JDTLS starts it does a build (Maven/Gradle) and other setup stuff. That takes quite a bit depending on your project size. AFAIU OpenCode has a timeout of 10s, which is too short. I'm currently experimenting with running JDTLS outside OpenCode and have it connect to it instead.