`lsp` tool returns empty results for TypeScript files in nested sub-projects (multiple tsconfig roots) under the working directory

Summary

When using the lsp tool on .ts files that belong to a nested TypeScript sub-project (a folder with its own tsconfig.json inside a larger working directory), every operation returns empty results even though a working TypeScript language server is configured. In some nested projects the tool reports No LSP server available for this file type. outright.

Environment

• opencode 1.18.27
• typescript-language-server 6.0.0 (global), node v24.15.0
• typescript@6.0.3 installed locally in each sub-project

Repro layout

Working directory contains several independent TS sub-projects, each with its own tsconfig.json:

my-project/
├── frontend/tsconfig.json   └── src/lib/services/query.service.ts
├── backend/tsconfig.json
├── website/tsconfig.json
├── sdk-ts/tsconfig.json
└── opencode.json   (only enables cloudflare mcp)

Steps

1. Open opencode with the working directory set to my-project/ (the parent that contains multiple TS sub-projects).
2. frontend/src/lib/services/query.service.ts line 51 contains export const queryService = { ... }.
3. Run the lsp tool on that file:

4. Run lsp on sdk-ts/src/client.ts (a .ts file in the sibling sub-project): returns No LSP server available for this file type.

Expected

documentSymbol returns the file's symbols and hover returns the type signature of queryService, as the configured TypeScript LSP is capable of producing.

Control test (works)

Calling the same typescript-language-server --stdio directly over the LSP protocol with rootUri set to the sub-project folder and waiting after textDocument/didOpen returns all symbols and the full hover for queryService (resolves to the local typescript@6.0.3). This confirms the LSP binary + config are correct and the gap is in the tool's server selection / handshake / timing.

Suspected cause

The lsp tool does not correctly associate a file with its nearest nested tsconfig.json project root. It likely (a) queries before the lazy tsserver finishes indexing the sub-project (empty results), and (b) for some sub-projects fails to select a server at all. The tool also does not seem to retry / wait for project load on subsequent warm calls.