No. The index lives in .ctx/ inside your repository. ctx opens no network connections, sends no telemetry, and never executes project code. The MCP server runs as a child process over stdio — nothing leaves the machine.
TypeScript/JavaScript, Python, Rust, and Go. Each is parsed with a tree-sitter grammar, and dependency resolution is language-aware.
No. The graph is built with static analysis, and ranking is a deterministic scoring function. There are no API calls, no models, no keys — which is also why the results are reproducible.
grep finds lines; ctx knows structure. It knows that create_user is a function defined in one file and called from others, which files import which, and what a change would ripple into. Skeleton output gives an agent signatures and exports without bodies, and impact analysis walks real dependency edges instead of matching text.
Embeddings answer "what is this about?" — fuzzy semantic similarity. ctx answers "where does this live, what calls it, what would break?" which are exact questions with exact answers. For agents working on a codebase, exactness matters more than similarity.
ctx indexes whatever directory you point it at, including the root of a monorepo. Use -R DIR to point any command at a specific project root.
If your tool speaks MCP over stdio, it works. Claude Desktop, Cursor, opencode, VS Code (Cline, Roo), and most other MCP clients are covered in the MCP guide.
The binary is a single static-ish Rust executable with no runtime dependencies. Initial indexing of a moderate repository takes about a second; incremental re-indexing is typically tens of milliseconds.
Yes. Every command supports --json, so ctx diff and ctx impact can feed checks, code review, or changelog generation.