[BUG] LSP documentSymbol output drops selectionRange

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The LSP tool's documentSymbol operation renders each symbol as "<name> (<kind>) - Line N", using only range.start.line. No column is ever surfaced. The line can point to the wrong place: for a symbol preceded by an annotation or a Javadoc comment, range covers the symbol's full extent including those leading annotations/comments, so range.start.line is the annotation's (or comment's) line, not the declaration's line.

The LSP spec defines selectionRange for exactly this: every compliant server (confirmed via a raw JSON-RPC capture of the actual response) already returns the exact {line, character} of the identifier itself, excluding annotations/comments. The tool's rendering discards it.

What Should Happen?

The tool should render a position derived from selectionRange, e.g. "someMethod (Method) - Line 214, Column 17"

Error Messages/Logs

Steps to Reproduce

1. Open a Java file with a method preceded by an annotation, e.g.:

   @Transactional
   public void someMethod(...) { ... }

1. Call LSP with operation documentSymbol on that file.
2. Observe the rendered line for someMethod.

Actual output:
someMethod (Method) - Line 213 // the @Transactional line, no column

Raw JSON-RPC response for the same symbol (0-based positions per LSP spec):

{
  "name": "someMethod",
  "range":          { "start": { "line": 212, "character": 4 } },
  "selectionRange": { "start": { "line": 213, "character": 16 } }
}

Note: affects every symbol kind, not just annotated ones. The tool never uses selectionRange at all.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.278

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Any workflow feeding a symbol's position into another LSP call (e.g. outgoingCalls, goToDefinition, which require line+character) cannot rely on documentSymbol alone.