LSP bridge: goToDefinition/findReferences/workspaceSymbol/goToImplementation empty while hover/documentSymbol work — call hierarchy result inconsistent across sessions (independent repro of #44767 / #32499)

Preflight Checklist

• [x] I have searched existing issues and this is a follow-up to two locked/closed duplicates that never got a landed fix (#44767, #32499)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Why a new issue

I wanted to comment on #44767 and its canonical duplicate #32499 with an independent repro, but both are locked (closed as duplicate / not_planned) so GitHub rejects new comments (403 Unable to create comment because issue is locked). Filing fresh since the underlying bug still reproduces and has a detail neither of those threads captured.

Environment

• Claude Code: 2.1.204
• OS: macOS 15.7.7 (Darwin 24.6.0), Apple Silicon
• typescript-language-server: 5.3.0
• Node: v22.13.1
• Clean session — no LSP processes manually killed at any point (ruling out the separate "server is running" stuck-state bug family, e.g. claude-plugins-official#1359)

Bug description

Confirmed the pattern from #44767 in an independent environment.

Test file: a top-level TS function (function foo(voyage, transferStart) {...}) that:

• imports a named const from another file in the project and uses it
• declares 4 local consts, one reused 6 lines below its declaration
• is called from exactly one other file, and itself calls 2 methods on an imported class instance

| Operation | Position | Result |
|---|---|---|
| documentSymbol | whole file | ✅ correct outline |
| hover (declaration) | local const decl | ✅ correct type |
| hover (usage, 4 lines below) | same const, later usage | ✅ same correct type |
| goToDefinition (same file) | usage → decl | ❌ "No definition found" |
| goToDefinition (cross-file import) | imported const usage | ❌ "No definition found" (hover on the same position correctly resolved it as (alias) const ... import ...) |
| findReferences | decl with 1 known usage | ❌ "No references found" |
| workspaceSymbol | exact function name | ❌ "No symbols found" |
| goToImplementation | imported class usage | ❌ "No definition found" |
| prepareCallHierarchy | function decl | ✅ resolved |
| incomingCalls | same position | ✅ found the real (only) call site, correct file+line |
| outgoingCalls | same position | ✅ found all 4 real internal calls, including one into @types/luxon (third file) |

Retried all empty results after 15s — identical, so not an indexing race.

New data point vs #44767's own repro

prepareCallHierarchy/incomingCalls/outgoingCalls are not reliably in the "broken" bucket together with goToDefinition/findReferences/workspaceSymbol/goToImplementation. In one session (same day, same machine, same Claude Code version) prepareCallHierarchy failed ("No call hierarchy item found") on a different file; in the session documented here it fully succeeded, including a correct cross-file incomingCalls/outgoingCalls result.

So the failure isn't cleanly "single-file/positional ops work, graph-based ops don't" — call hierarchy seems to intermittently fall on either side. This may be a useful clue for root-causing: it suggests a timing race rather than a structural gap, since the same request shape (a request that depends on the server having indexed/loaded the project) sometimes succeeds and sometimes doesn't, matching the "bridge reads the notification instead of waiting for the real response" hypothesis from #44767 more than a hardcoded "operation type X is unsupported" explanation.

Also worth flagging

#44767 was auto-closed as a duplicate of #32499, but #32499's repro has the opposite profile (hover/documentSymbol broken, workspaceSymbol working) from #44767's own repro (hover/documentSymbol working, workspaceSymbol broken) and from what's reproduced here. These may be distinct root causes that got merged by the auto-dedup bot — a fix aimed at one profile may not fix the other. Worth someone with repo access re-examining whether they should be split back out.

Expected behavior

goToDefinition, findReferences, workspaceSymbol, and goToImplementation should return correct results whenever the underlying language server would, matching what hover/documentSymbol already demonstrate is reachable through the same bridge.