more LSP

[thdxr]

[jedisct1]

Zig (via ZLS) would be really useful.

[sockthedev]

being able to opt into typescript-go too :)

[mitsuhiko]

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]

PHP Intelephense perhaps? 👀

[cemarta7]

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

[joe-niland]

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

[vasilvestre]

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

This works for me after a global install without licenseKey

[Cyrille37]

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

[dbpolito]

I'm using:

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

Working pretty well for me

[Cyrille37]

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

[dbpolito]

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!

[ALameLlama]

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]

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

[noirbizarre]

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)

[gytis-ivaskevicius]

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

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]

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.

[noirbizarre]

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

[dbpolito]

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]

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

[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

@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

[noirbizarre]

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)

[Cyrille37]

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]

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

[noirbizarre]

@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