[BUG] Experimental LSP tool returns empty results instead of initialization errors for nested Rust workspace

[matthewjameswatkins1978-cyber]

Description

Summary

The experimental OpenCode LSP tool is exposed and callable, but it does not produce usable Rust workspace results for a valid nested Cargo project. More importantly, apparent infrastructure or initialization failure is surfaced as an authoritative empty answer ([], [null], or No results found) rather than as an error.

That makes it difficult for a coding agent to distinguish “this symbol genuinely has no references” from “the language server never loaded the workspace.”

Environment

• OpenCode: 1.18.12
• OS: Windows 11
• Language server: rust-analyzer, installed through the Rust toolchain
• Repository layout:

<git-root>/tethers-0.1/host-rust/Cargo.toml

The Rust crate is nested below the Git repository root.

OpenCode was launched in a fresh console process with process-local environment variables:

OPENCODE_EXPERIMENTAL_LSP_TOOL=true
OPENCODE_DISABLE_LSP_DOWNLOAD=true

The real OpenCode CLI executable was used, not the desktop GUI executable.

Observed behaviour

For known Rust functions, fields, and symbols that definitely exist and have references:

• goToDefinition returned No results found
• findReferences returned No results found
• hover returned [null]
• documentSymbol returned no results
• workspaceSymbol returned no results
• opencode debug lsp document-symbols <valid-file-uri> returned [] with exit code zero
• a second fresh targeted session, using real zero-based positions at known call sites, timed out after approximately 244 seconds without usable LSP output

The same definitions and references were immediately discoverable with rg, and the Rust project compiled and passed its complete test suite.

Why this is risky

The current result shape does not distinguish between:

1. a successful query with zero results;
2. rust-analyzer not starting;
3. the wrong workspace root being selected;
4. Cargo metadata or workspace initialization failing;
5. the document not being opened or indexed;
6. indexing still being in progress;
7. the request timing out or the client/server bridge failing.

An agent may therefore treat a language-server failure as valid code-navigation evidence and make an unsafe edit.

Expected behaviour

When the language server or workspace is not ready, the LSP tool should return an explicit error or status rather than an empty successful result.

Ideally the tool would expose enough diagnostic state to identify:

• selected workspace root;
• language-server process status;
• initialization or Cargo metadata errors;
• whether the file belongs to the loaded workspace;
• whether indexing is still in progress;
• request timeout.

A bounded timeout would also be preferable to a request hanging for several minutes.

Suggested fallback behaviour

If OpenCode cannot prove that the server is initialized and the document/workspace is loaded, return a clear failure such as:

LSP unavailable: rust-analyzer did not initialize this workspace

rather than [], [null], or No results found.

The feature is marked experimental, so occasional failure is understandable. The important issue is that failure currently looks indistinguishable from a valid empty answer.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• TypeScript LSP doesn't spawn when project is in subdirectory (Module.resolve uses ctx.directory instead of resolved root) #35396: TypeScript LSP doesn't spawn when project is in subdirectory — covers the same nested/subdirectory workspace root resolution problem that likely affects rust-analyzer here too.
• TypeScript LSP server is not used if package.json is in a sub-directory #18694: TypeScript LSP server is not used if package.json is in a sub-directory — same class of issue where LSP fails silently for nested project layouts.

The silent empty-result behaviour you describe (where failure looks identical to "genuinely no results") may share the same underlying cause as those issues. It would be worth checking if rust-analyzer is even spawning at all before investigating the result-shape problem.

[matthewjameswatkins1978-cyber]

Thanks. I checked both suggested issues. They may share the nested-project-root symptom, but I do not think they fully duplicate #40413: - #35396 identifies a TypeScript-specific spawn failure caused by resolving `typescript/lib/tsserver.js` from `ctx.directory` instead of the already-resolved project root. - #18694 is also specifically about the TypeScript server not starting when `package.json` and `node_modules` live below the repository root. This report concerns Rust on Windows, with `rust-analyzer` installed through the Rust toolchain rather than resolved from a nested `node_modules` directory. I did not independently prove whether the `rust-analyzer` process spawned, so that remains a useful diagnostic question. However, the central bug in #40413 remains whichever answer is true: - if `rust-analyzer` did not spawn, OpenCode returned successful-looking empty results instead of reporting that the server was unavailable; - if it spawned against the wrong root or failed to initialize, OpenCode again returned empty results instead of reporting that state; - one targeted request also hung for about 244 seconds rather than returning a bounded failure. The observed results included `[]`, `[null]`, `No results found`, and an exit-zero `opencode debug lsp document-symbols` response for known Rust symbols. Those result shapes are indistinguishable from a legitimate query with no matches, which is the safety problem this issue is intended to capture. Environment for clarity: - OpenCode 1.18.12 - Windows 11 - nested Cargo project at `<git-root>/tethers-0.1/host-rust/Cargo.toml` - `rust-analyzer` installed as a Rust toolchain component - experimental LSP tool enabled in a fresh console process I am happy to run a specific OpenCode diagnostic command that proves server spawn, selected workspace root, initialization state, or captured stderr if you can point me to the intended command or log location. Until an exact shared code path is confirmed, I would treat #35396 and #18694 as related rather than duplicates.

…

On Tue, 04 Aug 2026 04:22:53 -0700, "github-actions[bot]" ***@***.***> wrote: github-actions[bot] left a comment [(anomalyco/opencode#40413)](#40413 (comment)) This issue might be a duplicate of existing issues. Please check: - [#35396](#35396): TypeScript LSP doesn't spawn when project is in subdirectory — covers the same nested/subdirectory workspace root resolution problem that likely affects rust-analyzer here too. - [#18694](#18694): TypeScript LSP server is not used if package.json is in a sub-directory — same class of issue where LSP fails silently for nested project layouts. The silent empty-result behaviour you describe (where failure looks identical to "genuinely no results") may share the same underlying cause as those issues. It would be worth checking if rust-analyzer is even spawning at all before investigating the result-shape problem. — Reply to this email directly, [view it on GitHub](#40413?email_source=notifications&email_token=B3QRKYZATJRQ4HL37BCTHYT5IHBQ3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJXHAZDSOJRGMZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5178299132), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/B3QRKY7RS7CHUUP35PFYLPL5IHBQ3AVCNFSNUABFKJSXA33TNF2G64TZHM4TONJXGM2DGMJZHNEXG43VMU5TKMBVHE4DINBSHA22C5QC). Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for [iOS](https://github.com/notifications/mobile/ios/B3QRKY7XKET7I6JZSEF7XK35IHBQ3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJXHAZDSOJRGMZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG) and [Android](https://github.com/notifications/mobile/android/B3QRKY2KPFGL4ZAFUBWAOWT5IHBQ3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJXHAZDSOJRGMZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA). Download it today! You are receiving this because you authored the thread.

[matthewjameswatkins1978-cyber]

Follow-up diagnostic on Windows with OpenCode 1.18.13.

Environment

• OpenCode shim: C:\Users\Matmus\AppData\Roaming\npm\opencode.ps1
• Executed binary: C:\Users\Matmus\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe
• rust-analyzer: 1.97.1 (8bab26f4 2026-07-14)
• rust-analyzer path: C:\Users\Matmus\.cargo\bin\rust-analyzer.exe
• Rust file: tethers-0.1/host-rust/src/event_queue.rs

Results

All commands exited 0 without timing out:

Working directory	Probe	Result
Git root	debug lsp diagnostics	empty diagnostics object
Git root	debug lsp document-symbols	[]
Git root	debug lsp symbols ResultEventQueue	[]
Cargo crate root	debug lsp diagnostics	empty diagnostics object
Cargo crate root	debug lsp document-symbols	[]

Both roots were selected correctly in the logs and behaved identically.

The logs listed Rust among the enabled LSP servers and, for diagnostics, recorded the target file being touched. They contained no Rust-server startup, successful initialization, initialization failure, process-exit, or timeout message.

No persistent rust-analyzer.exe process was observed in snapshots at approximately T+3s or T+10s. The CLI instance disposed within roughly one second, so these snapshots do not conclusively exclude a short-lived spawn and exit before T+3s.

OpenCode Desktop Electron processes were still running, so this was not a completely isolated process set. They were not children of the diagnostic CLI, however, and no rust-analyzer process was associated with them.

Relevant 1.18.13 source behaviour

Reviewing these files at tag v1.18.13 clarifies the empty results:

• packages/opencode/src/cli/cmd/debug/lsp.ts
• packages/opencode/src/lsp/lsp.ts

Observed control flow:

• debug lsp diagnostics calls touchFile, which calls getClients and therefore attempts server/client creation.
• getClients catches server-spawn and client-initialization failures, marks the server/root as broken, and returns no client rather than propagating an error.
• touchFile also suppresses errors while opening the file and waiting for diagnostics.
• diagnostics() then queries the current client list. With zero clients it returns an empty object and the CLI exits successfully.
• documentSymbol() also obtains clients, but request failures become []; zero clients likewise produces [].
• workspaceSymbol() queries only clients already present in the current process. A fresh debug lsp symbols invocation does not touch a file or initialize a client, so [] can occur without any spawn attempt.

Conclusion

The diagnostic does not yet identify why the Rust client failed to become available.

However, the central reporting problem is directly visible in the 1.18.13 control flow: a server spawn or client initialization failure can be swallowed and converted into an exit-zero empty diagnostics or symbol result, indistinguishable from a healthy LSP returning no findings.

The Git-root versus Cargo-root comparison did not alter the behaviour, so this evidence does not currently support nested workspace selection as the immediate cause.

[samiralibabic]

I traced the current dev request path and tested a local bounded-request prototype. A timeout alone is not sufficient: converting timeout or initialization failures to [] or null preserves the central problem reported here, because failure still looks like a successful empty result.

A complete fix should distinguish a healthy empty response from server-unavailable, initialization-failed, and request-timeout states. I can contribute a fake nonresponsive LSP regression test once the desired error shape is decided.

I also found a separate workspace-symbol routing problem: the tool accepts filePath but workspaceSymbol ignores it and queries only already-active clients. I am filing that separately so it does not broaden this issue.