projects / openez-graph / README.md

openez-graph

OpenEZ Graph is a local-first code intelligence engine for indexing codebases and docs into a reusable retrieval runtime for CLI tools, MCP clients, and a management UI

01README

OpenEZ Graph

npm version npm downloads License: MIT Website

Local-first code intelligence for coding agents. OpenEZ indexes code and documentation into SQLite, then exposes focused retrieval, graph context, and durable project memory through MCP.

Website · npm · Contributing

Quick start

Requires Node.js 20 or newer.

npm install -g @openez-graph/cli
openez setup codex .

Replace codex with claude, opencode, windsurf, or devin. Restart the agent after setup.

Without a global install:

npx @openez-graph/cli setup codex .

The MCP runtime registers the current project, creates its first index when needed, and keeps the index synchronized as files change.

Why OpenEZ

Coding agents repeatedly spend context reading the same files. OpenEZ creates a reusable local index so agents can retrieve relevant code and relationships without sending the whole codebase to an external database.

  • Local SQLite storage in WAL mode
  • Multi-workspace indexing and retrieval
  • Full-text search with graph expansion and optional embedding reranking
  • Persistent technical decisions through agent memory
  • CLI, MCP, and management UI over the same runtime
  • No Docker, Postgres, or Redis required

MCP tools

Tool Purpose
code_query Retrieve ranked code and documentation context
code_context Get graph-adjacent context for a symbol or file
graph_neighbors Inspect nearby graph nodes and edges
list_workspaces List registered workspaces and index status
memory_recall Recall stored technical decisions and notes
memory_write Store a decision or learned constraint
index_workspace Run an incremental or full index

Read tools support one or many workspaces. Write and index operations remain scoped to one workspace.

CLI

openez init [path]          # register and index a workspace
openez index [path]         # update changed files
openez reindex [path]       # rebuild the index
openez watch [path]         # keep an index synchronized
openez status [path]        # show workspace and graph counts
openez list                 # list registered workspaces
openez serve --mcp          # start the MCP server
openez serve --web          # start the management UI
openez setup <agent> [path] # configure an agent integration
openez config get [key]     # show embedding config (all if no key)
openez config set <key> <value>  # set an embedding config value
openez config list          # list all DB-stored config overrides

Run openez --help or openez <command> --help for all options.

Storage

OpenEZ uses four local artifacts:

~/.openez/registry.sqlite       registered workspace metadata + global config
~/.openez/master.key            encryption key for sensitive config (API keys)
<project>/.openez/index.sqlite  code, chunks, graph, memories, metrics
<project>/.openez/workspace.json workspace resolution hint

The project-local .openez directory is generated state and should not be committed.

Supported content

  • TypeScript and JavaScript: rich AST indexing with ts-morph
  • Python, Go, and Rust: tree-sitter AST parsing with regex fallback
  • YAML, JSON, and TOML: structure-aware chunks
  • Markdown: section-oriented chunks

Embeddings are optional. The default retrieval path works with SQLite full-text search and graph expansion.

Benchmark: FTS vs Embedding

Metric FTS only FTS + Embedding (bge-m3)
Recall@5 91.30% 95.65%
Keyword queries 100.00% 100.00%
Semantic queries 66.67% 83.33%
Avg latency 5 ms 249 ms

FTS-only is the default — 100% recall on keyword queries, 50x faster. Embedding adds semantic search with +16.67% semantic recall and no keyword regression via full RRF fusion. Pipeline: bge-m3 model, query expansion, similarity threshold, code file boost, path dedup, input hash dedup, embedding retry. See BENCHMARK.md for full analysis.

Embedding configuration

Embedding providers can be configured via CLI or the management UI. Config is stored globally in the registry DB and applies to all workspaces. DB-stored config takes priority over environment variables.

# Use local Ollama (bge-m3 recommended for code search)
openez config set embedding.provider ollama
openez config set embedding.ollama_model bge-m3

# Or use OpenAI
openez config set embedding.provider openai
openez config set embedding.openai_api_key sk-...
openez config set embedding.openai_model text-embedding-3-small

# View current config (merges DB + env defaults)
openez config get

Valid config keys:

Key Description
embedding.provider none, openai, or ollama
embedding.openai_api_key OpenAI API key (encrypted at rest)
embedding.openai_base_url Custom OpenAI-compatible base URL
embedding.openai_model OpenAI model name
embedding.ollama_base_url Ollama server URL
embedding.ollama_model Ollama model name

API keys are encrypted at rest with AES-256-GCM. The master key is stored at ~/.openez/master.key with file mode 0600.

If the embedding provider is unreachable or the API key is invalid, indexing and retrieval automatically fall back to FTS-only mode without crashing.

Management UI

The web UI provides workspace status, query telemetry, document and memory inspection, benchmarks, and a graph explorer.

openez serve --web

Workspace overview

Graph explorer

Development

pnpm install
pnpm typecheck
pnpm test
pnpm dev:web

The monorepo separates runtime surfaces under apps/ from reusable packages under packages/:

apps/       cli, mcp, web, worker
packages/   config, core, db, indexer, ui
landing/    product website
tests/      integration and retrieval tests

See CONTRIBUTING.md before opening a pull request.

License

MIT © Asta Nguyen

02Stats

6
stars
0
forks
TypeScript
language
Aug 6, 2026
last push

03Repository

openez-graphLive demo

openez-graph — Nguyen Thai Tai | Nguyen Thai Tai