Code intelligence: search_symbols rows are one line too high, so find_references on its result returns the wrong symbol's references

[venkatq3]

Summary

The code tool's tree-sitter search_symbols reports every symbol's start_row/end_row one line after where the symbol actually is. Its LSP find_references reads row as the real line. An agent that passes search_symbols' position to find_references, which is the natural chain and the one agents make on their own, gets the references of whatever identifier sits on the next line. The tool reports them as the requested symbol's references, and the agent treats that wrong answer as fact.

Environment

• kiro-cli 2.24.0, KAS 2.24.0, --v3 acp, macOS arm64
• gopls v0.23.0 on PATH, .kiro/settings/lsp.json present
• Code intelligence enabled via initialize → clientCapabilities._meta.kiro.settings.codeIntelligence = {"enabled": true}

Minimal repro

main.go (line numbers shown):

 1 package main
 2
 3 import "fmt"
 4
 5 // Target is the function whose references we look up.
 6 func Target(n int) int {
 7 	local := n * 2
 8 	return local + 1
 9 }
10
11 func main() {
12 	fmt.Println(Target(1))
13 	fmt.Println(Target(2))
14 }

other.go:

1 package main
2
3 func useTarget() int { return Target(3) }

Prompt: "Use only your code intelligence tool: search_symbols for Target, then find_references with the file_path, row and column search_symbols returned."

search_symbols {"symbol_name":"Target"}:

{"name":"Target","symbol_type":"Function","file_path":".../main.go","start_row":7,"start_column":2,"end_row":10,"end_column":3}
{"name":"useTarget","symbol_type":"Function","file_path":".../other.go","start_row":4,"start_column":2,"end_row":4,"end_column":43}

Target is on lines 6–9, not 7–10. useTarget is on line 3, not 4.

find_references {"file_path":".../main.go","row":7,"column":2}:

{"references":[
  {"file_path":".../main.go","start_row":7,"start_column":2,"end_row":7,"end_column":7},
  {"file_path":".../main.go","start_row":8,"start_column":9,"end_row":8,"end_column":14}],
 "total_count":2}

These are the references of the local variable local (lines 7 and 8). Target has 4 (the declaration plus calls at main.go:12, main.go:13 and other.go:3). gopls references main.go:6:6 returns them correctly.

Impact

On a real repo (a Go method with 37 references across its package), the agent chained the two operations this way and reported "2 references, both in the declaring file". Those were the references of a local variable one line below the declaration. Nothing in either response lets the agent notice the mismatch.

Expected

search_symbols and find_references use the same row convention, so a position returned by one can be passed to the other. Ideally the convention (0- or 1-based) is documented; https://kiro.dev/docs/tools/code-intelligence/ doesn't say.

[github-actions]

Thanks for opening this issue and for the incredibly detailed repro — the off-by-one between search_symbols row output and what find_references expects is a really clear catch! We can see how this silently leads agents down the wrong path when chaining those tools together. A maintainer will review this shortly, and your thorough write-up will definitely help speed things along. Great bug report! 🙌

[AnilMaktala]

Thanks for the detailed repro. The root cause you've identified is a row-convention mismatch: tree-sitter uses 0-based row indices, while LSP uses 1-based line numbers, and search_symbols is returning tree-sitter rows without converting to LSP coordinates. So when an agent chains search_symbols -> find_references using the returned position, it's looking at the wrong line every time.

We'll look into normalizing search_symbols' output to match the LSP convention that find_references expects so the two tools can be chained reliably. Marking this as a bug to investigate further.