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

[joao-jlcm]

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:

Operation	Position	Result
documentSymbol	line 51	No results found
hover	51:14 (queryService)	[null]
goToDefinition	51:14	No results found
workspaceSymbol queryService	—	No results found

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.

[github-actions]

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

• [BUG] Experimental LSP tool returns empty results instead of initialization errors for nested Rust workspace #40413: LSP tool returns empty results instead of initialization errors for nested workspace (same symptom: empty/null results for files in a nested sub-project)
• 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 (same root area: tsconfig/tsserver resolution when TS project is not at the workspace root)
• 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 scenario: monorepo layout where the TS project lives in a subdirectory)

If your issue is distinct (e.g. the server does spawn but returns empty results specifically due to multiple tsconfig roots rather than failing to spawn at all), please clarify the difference so this can be tracked separately.

[joao-jlcm]

I dug into this and the suspected cause matches: there are three compounding defects in the LSP runtime that produce both symptoms.

Root cause

1. Wrong root resolution — packages/opencode/src/lsp/server.ts:115-142. The builtin Typescript server uses NearestRoot(["package-lock.json", ...]) and never walks up looking for tsconfig.json. In your layout, no lockfile exists under my-project/, so every .ts file resolves to ctx.directory (= my-project/). tsserver is initialized with rootUri = file:///my-project/ and never learns about frontend/tsconfig.json, sdk-ts/tsconfig.json, etc. Because the cache key in lsp.ts is root + server.id, all sub-projects share one client.

2. tsserver.js resolved from the wrong place — same file, line 123: Module.resolve("typescript/lib/tsserver.js", ctx.directory). Module.resolve calls createRequire(path.join(dir, "package.json")), so when the opencode working directory has no package.json the call throws and returns undefined. spawn then returns undefined, the key goes into s.broken, and hasClients returns false — that is where the explicit "No LSP server available for this file type." comes from for sdk-ts/src/client.ts.

3. No readiness synchronization with tsserver — tool/lsp.ts:80-103 calls lsp.touchFile(file, "document") and immediately fires the request. client.ts:173-175 returns null from window/workDoneProgress/create and there is no $/progress listener, even though typescript-language-server maps tsserver's projectLoadingStart/projectLoadingFinish to standard $/progress notifications. The first request races tsserver's project load and gets [].

Proposed fix

• packages/opencode/src/lsp/server.ts — add "tsconfig.json" to Typescript.root's include list (nearest wins, so each sub-project gets its own root); resolve tsserver.js from root first and fall back to ctx.directory for non-nested projects.

  root: NearestRoot(
    ["tsconfig.json", "package-lock.json", "bun.lockb", "bun.lock", "pnpm-lock.yaml", "yarn.lock"],
    ["deno.json", "deno.jsonc"],
  ),
  async spawn(root, ctx, flags) {
    const tsserver =
      Module.resolve("typescript/lib/tsserver.js", root) ??
      Module.resolve("typescript/lib/tsserver.js", ctx.directory)
    if (!tsserver) return
    ...
  }

• packages/opencode/src/lsp/client.ts — return the token from window/workDoneProgress/create (currently returns null and silently drops progress events); add a $/progress listener that tracks in-flight progress tokens; expose an awaitProgress(timeoutMs) helper; call awaitProgress(5_000) after didOpen in notify.open for the typescript server.

• packages/opencode/test/lsp/typescript-root.test.ts — new file mirroring jdtls-root.test.ts, covering: nested tsconfig in a workspace with no parent lockfile, sibling sub-projects resolving to distinct roots, tsconfig-co-located-with-lockfile (tsconfig wins), lockfile-only (backward compat), no markers (fallback to ctx.directory), deno.json exclusion.

Behavior is fully backward compatible: projects without a tsconfig.json keep their lockfile-based root; projects without any markers keep the ctx.directory fallback; Deno projects still return undefined.

Verification

End-to-end repro matching the issue's layout:

1. Create my-project/{frontend,backend,website,sdk-ts}/tsconfig.json with bun dev running from packages/opencode pointed at the workspace root.
2. Call documentSymbol, hover, goToDefinition on frontend/src/lib/services/query.service.ts and sdk-ts/src/client.ts — all should return non-empty results, and sdk-ts should not throw "No LSP server available for this file type.".
3. bun run packages/opencode/src/cli/cmd/debug/lsp.ts status should report two connected typescript clients rooted at each sub-project.
4. cd packages/opencode && bun test test/lsp/typescript-root.test.ts test/lsp/client.test.ts test/tool/lsp.test.ts test/config/lsp.test.ts && bun typecheck — all green.

Open questions

• Wait timeout — proposed 5 s cold / 500 ms warm. Will tune based on real-world tsserver load times.
• Scope of the readiness wait — currently scoped to serverID === "typescript". Trivial to broaden to every server that emits $/progress (e.g. vue-language-server); happy to do that in the same change if preferred.