Glasir

Glasir

Deterministic code intelligence for repositories. Glasir builds a local, queryable graph of definitions, references, dependencies, and change impact, then serves bounded evidence over MCP. It gives engineering tools structural answers instead of an unfiltered file dump: what calls this, what breaks if it changes, and how two symbols connect.

*Glasir is the tree with golden leaves that stands before Valhalla, "the fairest among gods and men" — a tree whose every branch is visible from the ground.*

One Rust binary. No Python, no Node, no database, no GPU, and no model anywhere in the index or query path — the same tree and the same question always produce the same answer.

Production deployments pair the Core with Glasir Control for tenant policy,

mTLS boundaries, audited administration, cross-repository review, and

provider pull-request checks.

Quickstart

Install with the package manager you already use:

brew install attackwave/glasir/glasir                      # macOS, Linux

scoop bucket add glasir https://github.com/Attackwave/scoop-glasir scoop install glasir # Windows

Or download the archive for your platform from Releases, check it against the .sha256 beside it or its build provenance (gh attestation verify --repo Attackwave/glasir), and put glasir on your PATH:

The Linux binaries are statically linked and run on any distribution, including Alpine and older enterprise releases. A binary downloaded by hand on macOS is not yet notarized, so macOS refuses its first start; clear the flag once, after checking the checksum: xattr -d com.apple.quarantine glasir. Homebrew installs are not affected.

Clients that read the MCP registry list Glasir as io.github.Attackwave/glasir; that entry runs the container image with the repository mounted read-only.

Then, in the repository you want to ask about:

glasir install .

That finds the coding assistants installed on your machine — by their program on PATH, their settings in your home directory, or their files in the project — and registers Glasir with each, in the project's own configuration:

The server it registers runs with --watch, so the graph follows your edits while the assistant runs. It also installs git hooks that keep the graph current after a pull, checkout or rebase. For Claude Code it adds a SessionStart hook to .claude/settings.local.json: in an analysed tree, the session starts with a note to load the graph tools, because Claude Code defers MCP tools and an assistant that has not loaded them searches text instead. --no-hook skips both kinds. A registration file it creates holds absolute paths to your machine, so it is added to .gitignore; one your team already tracks is merged into, never replaced, and nothing in your home directory is touched. With no assistant detected it writes a neutral glasir-mcp.json for any MCP client. --platform picks one explicitly.

Several assistants on one tree share one server. What a client starts is a small relay to that tree's backend, which it starts when none runs: one graph, one watcher, whatever number of assistants are open. The backend ends a minute after the last client closes, and is started again when one returns. After ten minutes without a request it lets the graph go and stops watching, and the next request loads it again (--sleep-after , 0 keeps it). A relay a client forgets to close costs a few megabytes and no CPU. glasir servers lists what runs; --stop-replaced ends a server a client replaced without closing it. On Windows each client keeps its own server.

Most assistants ask before they start a new server: Claude Code and Qwen Code want the server approved, Codex and Gemini CLI read project settings only in a folder you have trusted, and Antigravity asks before its first use of an MCP tool. install prints the step for each one it wrote.

In Claude Code the plugin does the same without a step per repository, once glasir is on your PATH:

/plugin marketplace add Attackwave/glasir

/plugin install glasir@glasir

It serves whichever git repository a session starts in, and starts nothing elsewhere. Its generated files go into .git/info/exclude, so nothing tracked changes. Use the plugin or glasir install in a tree, not both: each brings its own copy of the server.

Restart the assistant and ask it something about the code: *"what breaks if I change parse_config?"*, *"how does a request reach the database?"*. The answers come from impact, query_graph, shortest_path and twelve more tools listed under What it serves.

glasir status .             # what is registered, what the graph holds

glasir why "your question" # what the search saw, when an answer surprises you glasir view . # the graph as a map in the browser, one region per subsystem glasir review # the uncommitted change as a Markdown review: risk, dependents, tests glasir export . > graph.json # the graph as node-link JSON, for another tool glasir servers # running servers; --stop-replaced ends those a client replaced glasir uninstall . # remove the registration and the hooks

What gets indexed

Everything your .gitignore files leave in, at every level of the tree, minus build output and dependencies (target, node_modules, dot-directories). A .glasirignore beside them uses the same syntax and wins over them, so it can both exclude more and bring back what git ignores:

# .glasirignore

!plan.md # untracked, but worth asking about !/reference/ # git ignores the whole directory ... /reference/scans/ # ... of which only this part stays out

A tree holding a copy of itself, such as an amalgamated header or a vendored snapshot, defines each name twice, and calls to an ambiguous name stay unlinked. overview names such directories; exclude the copy here.

As in git, a file inside an ignored directory comes back only once the directory does (!/reference/ above). Only ignore files inside the tree count — not your global excludes file and not .git/info/exclude — so the same commit gives the same graph on every machine, whatever each developer ignores locally.

Instruction files for coding assistants (AGENTS.md, CLAUDE.md, GEMINI.md and their .local.md variants, COPILOT.md, OPENAI.md, CHATGPT.md) and CONTRIBUTING.md, CHANGELOG.md, CODE_OF_CONDUCT.md are left out by default: they describe how to work on the code in the words a question is asked in, and outrank the code they describe. A project that wants one indexed names it in .glasirignore, e.g. !AGENTS.md. A change to either file takes effect on the next analysis, and immediately under --watch.

Of .github, the workflows, local actions and scripts/ are indexed although it is a dot-directory: a workflow's jobs are symbols, needs connects them, and uses: ./… and the scripts a step runs connect the job to those files, so impact on a script and review of a workflow see each other.

Why a graph

Search finds text. A graph preserves the relationships that make a repository behave as a system.

For example, answering "what is affected if authorize changes?" with search requires finding candidate files, interpreting each call site, and repeatedly reconstructing transitive dependencies. impact follows stored, provenance-labelled edges and returns affected symbols grouped by distance. Likewise, shortest_path shows the evidence-backed route between two symbols instead of asking a caller to infer one from unrelated file excerpts.

The graph does not claim to translate arbitrary natural language. Search uses deterministic identifier and text matching; unresolved or ambiguous symbols remain visible as such rather than being guessed.

Benchmarking

Glasir ships regression benchmarks, not vendor-comparison claims. They compare the checked-in corpus with a documented grep-and-read baseline and fail when a configured recall floor regresses. Results change as the corpus, questions and implementation change, so this README intentionally does not publish static percentages or token counts.

glasir benchmark .

glasir benchmark . --check python3 bench/scale.py target/release/glasir --check # 100k vs 1M lines

Benchmark methodology defines the corpus, baseline, token estimate, limits, and interpretation. It also explains why results from this repository are not a substitute for an evaluation on a customer's code.

Performance

Indexing and query latency depend on source shape, parser tier, storage, hardware, and the requested graph traversal. The analyse command reports the measured cold-index time and graph size for a repository; running it a second time measures snapshot reuse. Evaluate performance with the exact release, repository shape, and deployment limits that will be used in production.

Snapshots are stored beside the source tree and validated before reuse. A warm start maps the stored graph instead of reparsing the full tree, provided the source and extraction configuration still match.

What it serves

Fifteen MCP tools, over stdio for a local editor or Streamable HTTP for a remote agent:

• overview — the subsystems of an unfamiliar tree and the way into each; in a Rust workspace its crates, and each subsystem named by its crate
• query_graph — the subgraph relevant to a question; given a file's path, every definition in that file
• shortest_path — how one symbol reaches another
• explain_node — callers, callees and subsystem of one symbol
• impact — what breaks if this changes, grouped by distance
• cycles — dependency cycles, compiler-resolved edges only by default
• get_code_snippet — the source a symbol names, from the range the parser recorded, so nothing has to open the file or guess a line; a Markdown section returns that section, not the whole document, and following: N reads on through the next N definitions. An assembly routine that branches or falls into another says where it continues
• find_callers — the direct callers of one symbol, as one list, and the definitions that use it by name without calling it (a type in a signature, a constant re