more LSP #319

Open
opened 2026-02-16 17:26:11 -05:00 by yindo · 25 comments
Owner

Originally created by @thdxr on GitHub (Jun 26, 2025).

Originally assigned to: @thdxr on GitHub.

Originally created by @thdxr on GitHub (Jun 26, 2025). Originally assigned to: @thdxr on GitHub.
yindo added the growth label 2026-02-16 17:26:11 -05:00
Author
Owner

@jedisct1 commented on GitHub (Jun 26, 2025):

Zig (via ZLS) would be really useful.

@jedisct1 commented on GitHub (Jun 26, 2025): Zig (via ZLS) would be really useful.
Author
Owner

@sockthedev commented on GitHub (Jun 27, 2025):

being able to opt into typescript-go too :)

@sockthedev commented on GitHub (Jun 27, 2025): being able to opt into typescript-go too :)
Author
Owner

@mitsuhiko commented on GitHub (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.

@mitsuhiko commented on GitHub (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.
Author
Owner

@xHeaven commented on GitHub (Jun 27, 2025):

PHP Intelephense perhaps? 👀

@xHeaven commented on GitHub (Jun 27, 2025): PHP Intelephense perhaps? 👀
Author
Owner

@cemarta7 commented on GitHub (Aug 9, 2025):

PHP Intelephense perhaps? 👀

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" } }

@cemarta7 commented on GitHub (Aug 9, 2025): > PHP Intelephense perhaps? 👀 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" } }`
Author
Owner

@joe-niland commented on GitHub (Sep 26, 2025):

@cemarta7 based on #2121, I tested this and it seemed to work:

opencode run "make a php file with errors" --model "github-copilot/grok-code-fast-1" --print-logs  
IINFO  2025-09-27T00:29:54 +207ms service=file.time sessionID=ses_6776cc140ffee7g2wia0WBr8uz file=/Users/me/project/src/error_example.php read
INFO  2025-09-27T00:29:54 +2ms service=lsp serverID=intelephense spawned lsp server
INFO  2025-09-27T00:29:54 +0ms service=lsp.client serverID=intelephense starting client
INFO  2025-09-27T00:29:54 +1ms service=lsp.client serverID=intelephense sending initialize
INFO  2025-09-27T00:29:54 +224ms service=lsp.client serverID=intelephense initialized
INFO  2025-09-27T00:29:54 +1ms service=lsp.client serverID=intelephense path=/Users/me/project/src/error_example.php waiting for diagnostics
INFO  2025-09-27T00:29:54 +0ms service=bus type=lsp.client.diagnostics subscribing
INFO  2025-09-27T00:29:54 +0ms service=lsp.client serverID=intelephense path=/Users/me/project/src/error_example.php textDocument/didOpen
INFO  2025-09-27T00:29:55 +1006ms service=lsp.client serverID=intelephense path=/Users/me/project/src/error_example.php textDocument/publishDiagnostics
INFO  2025-09-27T00:29:55 +0ms service=bus type=lsp.client.diagnostics publishing
INFO  2025-09-27T00:29:55 +0ms service=lsp.client serverID=intelephense path=/Users/me/project/src/error_example.php got diagnostics
INFO  2025-09-27T00:29:55 +0ms service=bus type=lsp.client.diagnostics unsubscribing
INFO  2025-09-27T00:29:55 +0ms service=bus type=lsp.client.diagnostics unsubscribing

I also then got it to fix the file and it spawned the LSP again.

just using simplified config:

 "lsp": {
    "intelephense": {
      "command": [
        "src/node_modules/.bin/intelephense",
        "--stdio"
      ],
      "extensions": [
        ".php"
      ],
      "initialization": {
        "licenceKey": "XXXX"
      }
    }
  }
@joe-niland commented on GitHub (Sep 26, 2025): @cemarta7 based on #2121, I tested this and it seemed to work: ``` opencode run "make a php file with errors" --model "github-copilot/grok-code-fast-1" --print-logs ``` ``` IINFO 2025-09-27T00:29:54 +207ms service=file.time sessionID=ses_6776cc140ffee7g2wia0WBr8uz file=/Users/me/project/src/error_example.php read INFO 2025-09-27T00:29:54 +2ms service=lsp serverID=intelephense spawned lsp server INFO 2025-09-27T00:29:54 +0ms service=lsp.client serverID=intelephense starting client INFO 2025-09-27T00:29:54 +1ms service=lsp.client serverID=intelephense sending initialize INFO 2025-09-27T00:29:54 +224ms service=lsp.client serverID=intelephense initialized INFO 2025-09-27T00:29:54 +1ms service=lsp.client serverID=intelephense path=/Users/me/project/src/error_example.php waiting for diagnostics INFO 2025-09-27T00:29:54 +0ms service=bus type=lsp.client.diagnostics subscribing INFO 2025-09-27T00:29:54 +0ms service=lsp.client serverID=intelephense path=/Users/me/project/src/error_example.php textDocument/didOpen INFO 2025-09-27T00:29:55 +1006ms service=lsp.client serverID=intelephense path=/Users/me/project/src/error_example.php textDocument/publishDiagnostics INFO 2025-09-27T00:29:55 +0ms service=bus type=lsp.client.diagnostics publishing INFO 2025-09-27T00:29:55 +0ms service=lsp.client serverID=intelephense path=/Users/me/project/src/error_example.php got diagnostics INFO 2025-09-27T00:29:55 +0ms service=bus type=lsp.client.diagnostics unsubscribing INFO 2025-09-27T00:29:55 +0ms service=bus type=lsp.client.diagnostics unsubscribing ``` I also then got it to fix the file and it spawned the LSP again. just using simplified config: ``` "lsp": { "intelephense": { "command": [ "src/node_modules/.bin/intelephense", "--stdio" ], "extensions": [ ".php" ], "initialization": { "licenceKey": "XXXX" } } } ```
Author
Owner

@vasilvestre commented on GitHub (Nov 12, 2025):

  "lsp": {
    "intelephense": {
      "command": ["intelephense", "--stdio"],
      "extensions": [".php", ".phtml", ".inc"]
    },
  }

This works for me after a global install without licenseKey

@vasilvestre commented on GitHub (Nov 12, 2025): ```json "lsp": { "intelephense": { "command": ["intelephense", "--stdio"], "extensions": [".php", ".phtml", ".inc"] }, } ``` This works for me after a global install without licenseKey
Author
Owner

@Cyrille37 commented on GitHub (Nov 19, 2025):

Hi
When "Intelephense" is installed in VSCode/Codium, how to use this installation without re-installing Intelephense globally ?
Thanks.

@Cyrille37 commented on GitHub (Nov 19, 2025): Hi When "Intelephense" is installed in VSCode/Codium, how to use this installation without re-installing Intelephense globally ? Thanks.
Author
Owner

@dbpolito commented on GitHub (Nov 19, 2025):

I'm using:

  "lsp": {
    "intelephense": {
      "command": ["npx", "intelephense", "--stdio"],
      "extensions": [
        ".php"
      ],
      "initialization": {
        "licenceKey": "XXX"
      }
    }
  }

Working pretty well for me

@dbpolito commented on GitHub (Nov 19, 2025): I'm using: ``` "lsp": { "intelephense": { "command": ["npx", "intelephense", "--stdio"], "extensions": [ ".php" ], "initialization": { "licenceKey": "XXX" } } } ``` Working pretty well for me
Author
Owner

@Cyrille37 commented on GitHub (Nov 19, 2025):

Thanks @dbpolito. But I think your config works with npx and intelephense installed globally.

I cannot find if the opencode/sdks/vscode extension connect in the VSCode LSP pipeline. Perhaps I will open a dedicated issue ...

@Cyrille37 commented on GitHub (Nov 19, 2025): Thanks @dbpolito. But I think your config works with npx and intelephense installed globally. I cannot find if the `opencode/sdks/vscode` extension connect in the VSCode LSP pipeline. Perhaps I will open a dedicated issue ...
Author
Owner

@dbpolito commented on GitHub (Nov 19, 2025):

I just opened a PR to add support for PHP Intelephense: https://github.com/sst/opencode/pull/4504

The way opencode works is it doesn't install globally but at ~/.local/share/opencode/bin so it's global but only for opencode, pretty cool!

@dbpolito commented on GitHub (Nov 19, 2025): I just opened a PR to add support for PHP Intelephense: https://github.com/sst/opencode/pull/4504 The way opencode works is it doesn't install globally but at `~/.local/share/opencode/bin` so it's global but only for opencode, pretty cool!
Author
Owner

@ALameLlama commented on GitHub (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.

@ALameLlama commented on GitHub (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.
Author
Owner

@gytis-ivaskevicius commented on GitHub (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

@gytis-ivaskevicius commented on GitHub (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
Author
Owner

@noirbizarre commented on GitHub (Nov 27, 2025):

I think the main selling point of OpenCode or most AI CLI tools is to be independent from the IDE. Doing that would mean:

  • write an integration for each known IDE
  • introduce the concept of "supported IDE" and defeat the initial purpose of being IDE agnostic

Edit: however it fills a lot like the agent composition problem, and having the IDE being able to serve as a meta-LSP could be interesting (no vendor specific integration to write, each IDE can expose itself as a LSP)

@noirbizarre commented on GitHub (Nov 27, 2025): I think the main selling point of OpenCode or most AI CLI tools is to be independent from the IDE. Doing that would mean: - write an integration for each known IDE - introduce the concept of "supported IDE" and defeat the initial purpose of being IDE agnostic Edit: however it fills a lot like the agent composition problem, and having the IDE being able to serve as a meta-LSP could be interesting (no vendor specific integration to write, each IDE can expose itself as a LSP)
Author
Owner

@gytis-ivaskevicius commented on GitHub (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

@gytis-ivaskevicius commented on GitHub (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
Author
Owner

@nesl247 commented on GitHub (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.

@nesl247 commented on GitHub (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.
Author
Owner

@rakibdev commented on GitHub (Nov 28, 2025):

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 https://github.com/sst/opencode/issues/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.

@rakibdev commented on GitHub (Nov 28, 2025): > 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 https://github.com/sst/opencode/issues/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.
Author
Owner

@noirbizarre commented on GitHub (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:

  • 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

@noirbizarre commented on GitHub (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: - 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
Author
Owner

@dbpolito commented on GitHub (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.

@dbpolito commented on GitHub (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.
Author
Owner

@noirbizarre commented on GitHub (Dec 1, 2025):

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

@noirbizarre commented on GitHub (Dec 1, 2025): 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
Author
Owner

@gytis-ivaskevicius commented on GitHub (Jan 6, 2026):

@noirbizarre as 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

@dbpolito serena idea...

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

@gytis-ivaskevicius commented on GitHub (Jan 6, 2026): > @noirbizarre `as 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 > @dbpolito serena idea... 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
Author
Owner

@noirbizarre commented on GitHub (Jan 6, 2026):

I think we agree @gytis-ivaskevicius

@noirbizarre as 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)

@noirbizarre commented on GitHub (Jan 6, 2026): I think we agree @gytis-ivaskevicius > > [@noirbizarre](https://github.com/noirbizarre) `as 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)
Author
Owner

@Cyrille37 commented on GitHub (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 ...

Image
@Cyrille37 commented on GitHub (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 ... <img width="368" height="288" alt="Image" src="https://github.com/user-attachments/assets/799e4669-0d7f-48fb-af95-31243f0425e6" />
Author
Owner

@dbpolito commented on GitHub (Jan 7, 2026):

PHP LSP support was added a while back: https://github.com/anomalyco/opencode/pull/4504

@dbpolito commented on GitHub (Jan 7, 2026): PHP LSP support was added a while back: https://github.com/anomalyco/opencode/pull/4504
Author
Owner

@noirbizarre commented on GitHub (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:

  • 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

@noirbizarre commented on GitHub (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: - 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
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#319