Tree-sitter-based Repo Map

[dcieslak19973]

Please explain the motivation behind the feature request.
Goose currently relies on ripgrep for code navigation and search, which is fast but limited to text/regex matching. Adding Tree-sitter-based symbol extraction would enable Goose to build a structured, language-aware repo map, unlocking advanced features like class hierarchy analysis, symbol-based navigation, and more precise LLM context.

Describe the solution you'd like
Integrate Tree-sitter (with Rust bindings and language grammars) into Goose to:

• Parse source files and extract classes, functions, methods, and their relationships
• Build a repo map (e.g., JSONL) with symbol metadata (type, name, signature, parent, overrides, etc.)
• Add a CLI command (e.g., goose repo index) to generate/update the repo map
• Allow the LLM to use this map for context, navigation, and code understanding

Describe alternatives you've considered

• Continue using ripgrep (text-based, less precise)
• Integrate Zoekt (external dependency, less structural awareness)
• Use ctags (limited symbol info, not AST-based)

Additional context

• Tree-sitter is Rust-friendly and easy to package

• Enables features like class hierarchy mapping, override detection, and more

• Can be combined with ripgrep for hybrid workflows

• I have verified this does not duplicate an existing feature request

[DOsinga]

This is cool. Two questions though:

• Should this be build into the CLI? That precludes it from working in the desktop
• Could this be an MCP server

[dcieslak19973]

i only use the goose cli, so that's where i put it....if there's a better place that both the cli and desktop could use it great.

which is probably where you're going with the mcp. based on my experiences where i work, i'm leary of local (stdio) mcps which would be the natural place for something like this potentially. i also think, eventually, that having this sort of data available in memory will help it. I believe, but haven't looked closely, that aider does something like this with repomap and keeps it in memory

[taqtiqa-mark]

@DOsinga I believe the MCP is where this fits more naturally. For example https://github.com/wrale/mcp-server-tree-sitter
@dcieslak19973 can this be closed? There is repomix and you can also probably setup the tree-sitter MCP with the memory, knowledge-graph, etc. MCPs to work exactly how you want?

[DOsinga]

that makes a lot of sense to me. especially since the current approach seems to be cli only. with mcp it would work for both.

I would be supportive of adding this to the built-in developer kit though, which is also an mcp, but a little more controlled than I think @dcieslak19973 is worrying about. does that sound like a good way forward?

[dcieslak19973]

I'm sympathetic to above. That said, in the corporate environment I'm most familiar with there are security concerns about MCPs running locally. To that degree repomix is a reasonable alternative, though I don't think it actually does much treesitting and mostly just seems to concat all the source files together (or, in compress mode), just the classes and function signatures. The MCP-Server-Tree-Sitter running in a container (not currently supported), may aleviate some corporate InfoSec concerns as one could control the mount as read-only potentially.

I'm not familiar with use-cases of Goose Desktop for coding workflows, hence my focus on the cli, where I view goose's cli as similar to the claude code cli. Claude code seems to do a better job exploring a codebase than goose, and this PR was an attempt to improve goose in that regard.

At the end of the day, this probably comes down to this project's maintainer's views on what functionality is "core" to goose and what should come from integration points like MCP tools, etc. I understand the corporate environment I work in may be unique and/or may not be something goose maintainers prioritize. It could also be the case that we change how / where we would use goose to address our corporate infosec concerns w/r/t MCPs.

[michaelneale]

I am trying out that PR - curious about it. I really think it needs to be in core agent not cli however, and not clear how/when to trigger it, but worth a try.

[dcieslak19973]

I'll see what I can do about moving it.

[DOsinga]

closing since stale