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
Does more here mean "more than nothing"? I'm a bit confused at the moment of the state of the LSP stuff because the lsp tools currently return "do not use" in the description so the agents don't even attempt to use them.
Reacted by Christopher Little-Savage, Nitsan Avni, Hugo and Nino
Reacted by Bastien Jaillot, Oliver Servín, zien, sheena-antikode, Mateusz Tymek, Ameen Radwan, Joe Niland, Justin Vogt, Cesar Hernandez, morke and 5 more
I was wonder if it's possible to have multiple LSP's for a language and to pick between them. I know php intelephense is the most popular but I've found php actor to be better over all and has better performance once it's indexed too. it's also the more common LSP installed for vim users.
@noirbizarre i completely agree with you, but all I am saying is that I see no reason not to have both.
More often than not users run opencode alongside IDE anyways, and I think adding IDE specific support is worth exploring
The way I imagine this being implemented is by defining something like openapi spec and having one or two reference implementations of the API from IDE side. This allows users to easily add support for other IDEs
I do agree that having integration with IDEs makes a lot of sense. Even if you aren't using an IDE but an editor, you are using one, the AI isn't doing 100% of everything for you 100% of the time.
How about instead of more LSPs adding a feature to connect to vscode/jetbrains diagnostic and use that instead?
100%. in large projects opencode's lsp initialization keeps timing out #742
so i've increased timeout then realized it adds 3-5 seconds delay in every file edit.
on the other hand cursor, windsurf works almost instant.
i don't anyone who codes in notepad and also wants linting luxury in opencode. makes more sense if it's part of extension.
Yes, I understand, but my fear is that, given I use OpenCode exactly because it doesn't have IDE adherence, as soon as this project start having some IDE specific code, it means that:
as a neovim user, I can now have a "this feature is only on VSCode currently"
OpenCode team will have to maintain n IDE integrations, so:
loose bandwidth for the non-IDE specifics
have to handle the IDE-specific support requests
have to stay up to date with each IDE specific and maintain compatibility
More, not only it defeat the purpose of this cli-only tool, it defeats the purpose of LSP itself as it is meant by design to not rely on the IDE (so using a vendor-specific IDE integration to access its LSPs is diabolic 😅).
This is why, I think the only sustainable approach it to have the IDE behave as an LSP itself, so each IDE can have its own plugin to do that, it's reusable across tools, and LSP implementation in OpenCode which is already there, can remain vendor-neutral (I'm not a OpenCode dev, it's just my humble opinion)
Note: you can disable LSPs on big projects to avoid the perf hit
I've been trying it for 1 month and I stopped for the following reasons:
1 more MCP is 1 more service running by IDE+Opencode instance (cpu+memory+tokens consumption)
the dashboard opening is annoying. You can disable it but then you are blind on what serena do, wether it attached it to the right project...
I did not find any improvement (I think the semantic code retrieval and edit needs to be part of OpenCode as a core tools for it to be efficient, OpenCode was still performing grep+edit in addition to mcp calls)
While I liked the idea, it didn't replace OpenCode core tools (on my use cases).
I think the idea is interesting, OpenCode could do it natively (rely on LSPs instead of grep/edit when supported), but to benefit of Serena I think you need to adjust some prompts.
Also, I think it does not solve the issue, it reproduce it in another product: Serena runs its own LSPs, which are not those from your editor, nor those of OpenCode.
Note
Sorry, I think debate polute the initial thread. I would be nice to have the discussions sections open to be able to discuss those kind of thinks without adding some noice to issues
@noirbizarreas a neovim user, I can now have a "this feature is only on VSCode currently"
My proposal was to have a simple spec for opencode to comunicate with editors, which would include nvim, I don't think it would take much time to implement such extensions for any editor, but I would think that opencode team would create a couple of them for the tooling they use and let community take care of the rest
I really liked your idea so i gave it a shot, went all the way to disabling default tools and fully replacing it with serena and system prompt, strongly encouraging serena tools
anyways, my conclusion is that it is not worth it for most projects. it just ends up using more tokens for basically everything, maybe on large repos with complex refactoring it would make sense, but i was not able to find a good usecase myself
@noirbizarreas a neovim user, I can now have a "this feature is only on VSCode currently"
My proposal was to have a simple spec for opencode to comunicate with editors, which would include nvim, I don't think it would take much time to implement such extensions for any editor, but I would think that opencode team would create a couple of them for the tooling they use and let community take care of the rest
Agreed, but instead of a new protocol, I think it's best to reuse one well established that OpenCode already support, that's why I said this:
This is why, I think the only sustainable approach it to have the IDE behave as an LSP itself, so each IDE can have its own plugin to do that, it's reusable across tools, and LSP implementation in OpenCode which is already there, can remain vendor-neutral (I'm not a OpenCode dev, it's just my humble opinion)
Also, on Serena, I reached the same conclusion than you, it would only work if LSP edits are part of OpenCode core (which I think is in progress and available as experimental feature)
@Cyrille37 It's not VSCode's, OpenCode uses its own LSP, it's using the same one. If you have both OpenCode and VSCode open, you should see 2 PHP intellisense processes.
Most of the time it's OK, but it can be an issue when:
you don't use the same LSP in your IDE (VSCode or Neovim, same) than OpenCode (so OpenCode won't see the same issues than you IDE
you work on a big code base or a resource-intensive LSP: effort is duplicated, twice the CPU and RAM usage, and twice the computation time on change
you have specific settings in your IDE that are not handled (or handlable) by config file: OpenCode won't use them or you will have to replicate them in your OpenCode config
However it's only used for diagnostic currently, not for edits from what I understand
Activity
jedisct1 commentedon Jun 26, 2025
Zig (via ZLS) would be really useful.
sockthedev commentedon Jun 27, 2025
being able to opt into typescript-go too :)
mitsuhiko commentedon Jun 27, 2025
Does more here mean "more than nothing"? I'm a bit confused at the moment of the state of the LSP stuff because the lsp tools currently return "do not use" in the description so the agents don't even attempt to use them.
xHeaven commentedon Jun 27, 2025
PHP Intelephense perhaps? 👀
cemarta7 commentedon Aug 9, 2025
I think I got it working with this. Could you tested
"intelephense": { "disabled": false, "command": ["intelephense", "--stdio"], "extensions": [".php", ".phtml", ".php3", ".php4", ".php5", ".phps", ".blade.php"], "initialization": { "storagePath": "/tmp/intelephense", "globalStoragePath": "~/.config/intelephense", "licenceKey": "XXXXXXXXXXXXXX", "clearCache": false, "files": { "maxSize": 5000000, "associations": ["*.php", "*.phtml"], "exclude": [ "**/vendor/**/{Tests,tests}/**", "**/.git/**", "**/node_modules/**", "**/bower_components/**" ] }, "environment": { "phpVersion": "8.2.0", "includePaths": [ "vendor/laravel/framework/src", "_ide_helper.php", "_ide_helper_models.php" ], "documentRoot": "public", "shortOpenTag": false }, "completion": { "insertUseDeclaration": true, "fullyQualifyGlobalConstantsAndFunctions": false, "triggerParameterHints": true, "maxItems": 100 }, "diagnostics": { "enable": true, "run": "onType", "undefinedSymbols": false, "undefinedTypes": false, "undefinedMethods": false }, "stubs": [ "apache", "bcmath", "bz2", "calendar", "Core", "curl", "date", "dom", "exif", "fileinfo", "filter", "gd", "hash", "iconv", "json", "ldap", "libxml", "mbstring", "mcrypt", "mysqli", "openssl", "pcntl", "pcre", "PDO", "pdo_mysql", "Phar", "posix", "readline", "redis", "Reflection", "session", "SimpleXML", "soap", "sockets", "sodium", "SPL", "sqlite3", "standard", "tokenizer", "xml", "xmlreader", "xmlwriter", "zip", "zlib" ], "format": { "enable": true }, "maxMemory": 512 }, "env": { "NODE_OPTIONS": "--max-old-space-size=2048" } }joe-niland commentedon Sep 27, 2025
@cemarta7 based on #2121, I tested this and it seemed to work:
I also then got it to fix the file and it spawned the LSP again.
just using simplified config:
vasilvestre commentedon Nov 12, 2025
This works for me after a global install without licenseKey
Cyrille37 commentedon Nov 19, 2025
Hi
When "Intelephense" is installed in VSCode/Codium, how to use this installation without re-installing Intelephense globally ?
Thanks.
dbpolito commentedon Nov 19, 2025
I'm using:
Working pretty well for me
Cyrille37 commentedon Nov 19, 2025
Thanks @dbpolito. But I think your config works with npx and intelephense installed globally.
I cannot find if the
opencode/sdks/vscodeextension connect in the VSCode LSP pipeline. Perhaps I will open a dedicated issue ...dbpolito commentedon Nov 19, 2025
I just opened a PR to add support for PHP Intelephense: #4504
The way opencode works is it doesn't install globally but at
~/.local/share/opencode/binso it's global but only for opencode, pretty cool!ALameLlama commentedon Nov 20, 2025
I was wonder if it's possible to have multiple LSP's for a language and to pick between them. I know php intelephense is the most popular but I've found php actor to be better over all and has better performance once it's indexed too. it's also the more common LSP installed for vim users.
gytis-ivaskevicius commentedon Nov 27, 2025
How about instead of more LSPs adding a feature to connect to vscode/jetbrains diagnostic and use that instead?
While this does not cover all the use cases, this definitely would simply life for a lot of users
1 remaining item
gytis-ivaskevicius commentedon Nov 27, 2025
@noirbizarre i completely agree with you, but all I am saying is that I see no reason not to have both.
More often than not users run opencode alongside IDE anyways, and I think adding IDE specific support is worth exploring
The way I imagine this being implemented is by defining something like openapi spec and having one or two reference implementations of the API from IDE side. This allows users to easily add support for other IDEs
nesl247 commentedon Nov 27, 2025
I do agree that having integration with IDEs makes a lot of sense. Even if you aren't using an IDE but an editor, you are using one, the AI isn't doing 100% of everything for you 100% of the time.
I believe I've seen other scenarios of this, but not 100% sure, but if LSP doesn't work because editors/IDEs don't have the integrations, MCP is another scenario. https://www.jetbrains.com/help/idea/mcp-server.html#get_file_problems for example.
rakibdev commentedon Nov 28, 2025
100%. in large projects opencode's lsp initialization keeps timing out #742
so i've increased timeout then realized it adds 3-5 seconds delay in every file edit.
on the other hand cursor, windsurf works almost instant.
i don't anyone who codes in notepad and also wants linting luxury in opencode. makes more sense if it's part of extension.
noirbizarre commentedon Dec 1, 2025
Yes, I understand, but my fear is that, given I use OpenCode exactly because it doesn't have IDE adherence, as soon as this project start having some IDE specific code, it means that:
More, not only it defeat the purpose of this cli-only tool, it defeats the purpose of LSP itself as it is meant by design to not rely on the IDE (so using a vendor-specific IDE integration to access its LSPs is diabolic 😅).
This is why, I think the only sustainable approach it to have the IDE behave as an LSP itself, so each IDE can have its own plugin to do that, it's reusable across tools, and LSP implementation in OpenCode which is already there, can remain vendor-neutral (I'm not a OpenCode dev, it's just my humble opinion)
Note: you can disable LSPs on big projects to avoid the perf hit
dbpolito commentedon Dec 1, 2025
one option i came across today is: https://github.com/oraios/serena
It's not a LSP directly, it's a mcp with lsp support... very interesting, not sure what would take to integrate with OpenCode.
noirbizarre commentedon Dec 1, 2025
I've been trying it for 1 month and I stopped for the following reasons:
While I liked the idea, it didn't replace OpenCode core tools (on my use cases).
I think the idea is interesting, OpenCode could do it natively (rely on LSPs instead of grep/edit when supported), but to benefit of Serena I think you need to adjust some prompts.
Also, I think it does not solve the issue, it reproduce it in another product: Serena runs its own LSPs, which are not those from your editor, nor those of OpenCode.
Note
Sorry, I think debate polute the initial thread. I would be nice to have the discussions sections open to be able to discuss those kind of thinks without adding some noice to issues
gytis-ivaskevicius commentedon Jan 6, 2026
My proposal was to have a simple spec for opencode to comunicate with editors, which would include nvim, I don't think it would take much time to implement such extensions for any editor, but I would think that opencode team would create a couple of them for the tooling they use and let community take care of the rest
I really liked your idea so i gave it a shot, went all the way to disabling default tools and fully replacing it with serena and system prompt, strongly encouraging serena tools
anyways, my conclusion is that it is not worth it for most projects. it just ends up using more tokens for basically everything, maybe on large repos with complex refactoring it would make sense, but i was not able to find a good usecase myself
noirbizarre commentedon Jan 6, 2026
I think we agree @gytis-ivaskevicius
Agreed, but instead of a new protocol, I think it's best to reuse one well established that OpenCode already support, that's why I said this:
Also, on Serena, I reached the same conclusion than you, it would only work if LSP edits are part of OpenCode core (which I think is in progress and available as experimental feature)
Cyrille37 commentedon Jan 7, 2026
Hi,
Sorry if I'm out of subject, but I try 😉 : With the opencode's vscode extension the LSP is already used, without any configuration ...
dbpolito commentedon Jan 7, 2026
PHP LSP support was added a while back: #4504
noirbizarre commentedon Jan 7, 2026
@Cyrille37 It's not VSCode's, OpenCode uses its own LSP, it's using the same one. If you have both OpenCode and VSCode open, you should see 2 PHP intellisense processes.
Most of the time it's OK, but it can be an issue when:
However it's only used for diagnostic currently, not for edits from what I understand
github-actions 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: auto-connect web sessions and sidebar workspace hub (anomalyco#438