#OpenEZ: Local-First Code Intelligence for AI Coding Agents

AI coding agents do not usually fail because they cannot generate code. They fail because they cannot retrieve the right part of a large codebase quickly enough.

They read the same files repeatedly, miss callers several modules away, lose technical decisions between sessions, and spend context on repository structure instead of the task itself.

OpenEZ Graph is a local-first code intelligence engine for that problem. It indexes code and documentation into SQLite, builds a symbol and relationship graph, and exposes focused retrieval tools through MCP.

The CLI package is @openez-graph/cli. It runs on Bun 1.1+, requires no Docker, Postgres, Redis, or external database, and can connect coding agents such as Claude Code, Codex, OpenCode, Windsurf, and Devin.

• OpenEZ website
• GitHub repository
• npm package

#The shortest mental model

OpenEZ has four layers:

1. Indexer — scans source files and documentation into chunks and symbols.
2. Local store — keeps workspace data in SQLite under the project.
3. Retrieval and graph engine — searches content and follows relationships such as imports and calls.
4. Agent interfaces — exposes the same runtime through CLI, MCP, and a web dashboard.

The result is a reusable project context layer. Instead of asking an agent to read the whole repository, the agent can ask for the code, symbols, callers, and decisions relevant to the current task.

#Why local-first matters

OpenEZ stores workspace artifacts locally:

Code
Copy
Loading…

The project-local .openez/ directory is generated state and should be gitignored. Source code stays in the repository; the index stays beside it.

This design gives teams:

• no hosted code database to provision
• no Docker, Postgres, or Redis requirement
• fast local startup
• workspace isolation
• a portable index that can be rebuilt at any time
• a clear trust boundary for source code

OpenEZ is not trying to replace your application database. It is a developer-side index of the code and technical context needed by an agent.

#Install and connect an agent

OpenEZ requires Bun 1.1 or newer.

Install the published CLI:

Code
Copy
Loading…

Use the setup target for your client:

Code
Copy
Loading…

Or run it without a global install:

Code
Copy
Loading…

The setup command writes the MCP configuration for the selected agent and adds project instructions that tell the agent when to prefer OpenEZ tools. Restart the agent after setup.

For a manual workspace workflow:

Code
Copy
Loading…

The MCP server can then be started with:

Code
Copy
Loading…

The first MCP session auto-registers the current project and indexes it when no documents exist. Live file watching is optional:

Code
Copy
Loading…

Without the watcher, read tools still perform throttled incremental catch-up before querying.

#MCP tools built for agent work

OpenEZ does not expose a generic CRUD API to the model. It exposes capabilities that map to real coding tasks:

The tools are intentionally narrow. An agent can first query a concept, then inspect the symbol context, then traverse callers, without loading unrelated files into the conversation.

#What gets indexed

OpenEZ combines language-aware parsing with safe fallback scanning.

This matters for brownfield repositories. A project does not need to be rewritten into one language or one framework before OpenEZ can provide useful retrieval.

#Is OpenEZ a RAG system?

OpenEZ is best understood as the retrieval layer of an agent RAG workflow, not as a complete application that generates answers by itself.

The retrieval path is:

1. index source and documentation
2. search relevant chunks
3. optionally rerank with embeddings
4. expand through code-graph relationships
5. return bounded context to the coding agent
6. let the agent reason and act

The default path uses SQLite FTS5 with BM25 ranking and graph expansion. Optional vector search supports OpenAI, Ollama, or a local embedding model.

Embeddings are deliberately separate from indexing:

Code
Copy
Loading…

You can also use Ollama or OpenAI embeddings. If embeddings are unavailable, retrieval falls back to FTS plus graph context. This keeps the basic installation local and usable without an API key.

#The code graph

Text search can find a symbol name. The graph explains how that symbol participates in the system.

OpenEZ stores relationships such as:

• file contains symbol
• symbol imports another file
• function calls another function
• graph nodes connect related chunks and documents

That enables questions such as:

• Who calls this service?
• Which controllers reach this repository?
• What files depend on this symbol?
• What should be rechecked after changing this API?
• Which documentation pages are connected to this workflow?

code_context also applies token budgets and limits its context size per workspace. This prevents a useful relationship lookup from turning into an unbounded context dump.

#Durable project memory

Repositories contain decisions that are not obvious from source code:

• why a dependency was avoided
• which API is intentionally deprecated
• what migration constraint must remain
• which edge case caused a production incident

memory_write stores these decisions in the local workspace index. Later sessions can use memory_recall before planning or editing.

Memory is not a replacement for source code or tests. It is a durable layer for decisions and constraints that would otherwise remain trapped in chat history.

#CLI and dashboard

The CLI is the shortest path for setup and automation:

Code
Copy
Loading…

The management UI is useful when a team needs visibility rather than another terminal command:

Code
Copy
Loading…

The dashboard shows workspace status, document and chunk counts, graph data, query telemetry, memories, and indexing controls. The default development server runs locally.

#What OpenEZ deliberately does not do

OpenEZ is not:

• a hosted source-of-truth repository
• a replacement for Git
• a general-purpose application database
• a promise that embeddings fix poor retrieval
• an autonomous coding agent
• a reason to send the entire codebase to a remote service

It gives an agent better context. The agent still needs a workflow that says when to inspect, plan, implement, test, and review.

#A practical team workflow

A reliable setup looks like this:

1. Install OpenEZ and connect the team’s coding agent.
2. Let the first session index the repository.
3. Before coding, call memory_recall and query the relevant domain.
4. Use code_context and graph_neighbors to trace callers and downstream effects.
5. Make the smallest change that satisfies the approved plan.
6. Run the narrow test and review the diff.
7. Re-index after meaningful source changes.

This pairs well with a repository workflow such as Agent DevKit: the wiki provides verified human-readable context, while OpenEZ provides semantic retrieval and graph traversal for the agent.

#Final take

OpenEZ is a focused answer to a practical problem: coding agents need a fast, local, relationship-aware way to understand a real codebase.

Its strongest design choices are simple:

• Bun and SQLite keep the runtime local and lightweight.
• MCP exposes agent-level capabilities instead of low-level database operations.
• FTS works out of the box; embeddings remain optional.
• The graph helps trace impact beyond text matches.
• Memory keeps technical decisions available across sessions.
• The CLI and dashboard share one runtime and one workspace model.

If your team is already using AI coding agents and keeps paying the same context cost every session, OpenEZ is worth trying.

Install @openez-graph/cli on npm · View the source on GitHub