Graphify - Codebase Knowledge Graphs for AI Coding Agents

Most AI coding work eventually hits the same practical problem: the agent can read files, but it does not automatically keep a compact map of how the project fits together.

Graphify is trying to give agents that memory layer.

It scans a folder, extracts code structure and semantic relationships, builds a graph, and then lets an assistant query that graph instead of repeatedly grepping or reading large chunks of the repository.

Graphify is a Python CLI and assistant skill that turns code, docs, papers, images, and media into a queryable knowledge graph.

Graphify GitHub Source Code Graphify Website Graphifyy on PyPI License: MIT

What is Graphify?

Graphify is distributed as the Python package graphifyy, but the command is graphify.

That double-y package name is worth remembering because the README explicitly warns that other similarly named PyPI packages are not affiliated.

Once installed, Graphify can be used in two related ways:

• as a direct CLI for extracting, querying, clustering, and exporting project graphs
• as an installed skill or instruction layer for AI coding assistants

The second mode is the main idea. Graphify is most useful when paired with an agentic coding CLI or IDE assistant such as Codex, Claude Code, Hermes, OpenCode, Kilo Code, Cursor, Gemini CLI, Aider, or Copilot CLI.

The standalone CLI is still useful for automation and debugging, but the stronger workflow is: build the graph once, then let the agent query that graph while working inside the codebase.

The upstream project supports a long list of assistant environments, including Claude Code, Codex, OpenCode, Kilo Code, Cursor, Gemini CLI, GitHub Copilot CLI, VS Code Copilot Chat, Aider, Amp, OpenClaw, Factory Droid, Trae, Hermes, Kimi Code, Kiro, Pi, Devin CLI, and Google Antigravity.

The basic output is a graphify-out/ folder:

graphify-out/
|-- graph.html
|-- GRAPH_REPORT.md
`-- graph.json

That gives you a browser graph, a readable report, and the structured graph data that later queries can use.

Why It Is Interesting

Graphify is not just another repository summarizer.

Its code path separates deterministic extraction from semantic extraction:

• code files can be parsed locally with tree-sitter
• docs, PDFs, images, and transcripts can use LLM-backed extraction when needed
• the final graph can be queried, exported, clustered, and refreshed

That means a code-only corpus can be useful without an API key, while richer mixed corpora can still use LLMs when the extra semantic pass is worth the cost.

For agent workflows, the interesting part is the query loop:

graphify query "what calls authentication?" --graph graphify-out/graph.json

Instead of making the agent re-read the repository, you can give it a graph-shaped memory of files, functions, imports, calls, communities, and relationships.

Tech Overview

The upstream architecture document describes the pipeline as:

detect() -> extract() -> build_graph() -> cluster() -> analyze() -> report() -> export()

The source tree follows that shape closely:

The project currently uses Python, NetworkX, datasketch, RapidFuzz, and many tree-sitter grammar wheels.

Optional extras add support for PDFs, Office files, video/audio transcription, MCP, Neo4j, SVG export, SQL, Terraform/HCL, Chinese query segmentation, and several LLM providers.

Installing Graphify

The recommended install path is uv:

uv tool install graphifyy
graphify install

Alternatives:

pipx install graphifyy
pip install graphifyy

For Codex:

graphify install --platform codex

The README also recommends enabling multi-agent support in ~/.codex/config.toml:

[features]
multi_agent = true

Project-scoped installs are possible too:

graphify install --project --platform codex

That writes Graphify’s skill files into the current repository rather than only your home directory.

Trying Graphify Locally

I tested Graphify locally from the cloned repository:

git clone https://github.com/safishamsi/graphify.git tmp/foss-post/graphify

The checkout I tested was commit 4b06fd7, with package version 0.8.33 in pyproject.toml and CHANGELOG.md.

One small version nuance: the repository also contains an older v1.0.0 git tag from April 2026, but the current HEAD describes itself as 0.8.33.

For this project, package metadata and changelog are more useful than naive git tag sorting.

Local Environment

This ran on a constrained Ubuntu machine:

I used an isolated virtualenv inside the cloned repo:

python3 -m venv tmp/foss-post/graphify/.venv
tmp/foss-post/graphify/.venv/bin/python -m pip install --upgrade pip setuptools wheel
tmp/foss-post/graphify/.venv/bin/python -m pip install -e tmp/foss-post/graphify

The install completed from wheels. It pulled many tree-sitter grammar packages plus networkx, datasketch, rapidfuzz, numpy, and scipy, but it did not download AI models.

The cloned repo plus virtualenv occupied about 356MB.

First Gotcha: Ignored Paths Matter

My first tiny test folder lived under this site’s ignored tmp/ tree.

Graphify respected the ignore rules and found nothing:

[graphify extract] found 0 code, 0 docs, 0 papers, 0 images

That is not a bug, but it is a practical gotcha. If your scan root sits under an ignored path, Graphify may quite correctly skip it.

Moving the same sample to /tmp/graphify-local-sample fixed the test.

Code-Only Extraction

I copied three small fixture files into a clean folder:

rm -rf /tmp/graphify-local-sample
mkdir -p /tmp/graphify-local-sample

cp tmp/foss-post/graphify/tests/fixtures/sample.py /tmp/graphify-local-sample/
cp tmp/foss-post/graphify/tests/fixtures/sample_calls.py /tmp/graphify-local-sample/
cp tmp/foss-post/graphify/tests/fixtures/sample.ts /tmp/graphify-local-sample/

Then ran extraction without clustering:

/usr/bin/time -v tmp/foss-post/graphify/.venv/bin/graphify extract \
  /tmp/graphify-local-sample \
  --out /tmp/graphify-local-sample \
  --no-cluster

Result:

[graphify extract] found 3 code, 0 docs, 0 papers, 0 images
[graphify extract] AST extraction on 3 code files...
[graphify extract] wrote /tmp/graphify-local-sample/graphify-out/graph.json - 19 nodes, 25 edges (no clustering)

Measured locally:

That confirms the useful recent change from the changelog: code-only extraction can run offline.

Clustering and Browser Output

To generate the report and browser graph without LLM labels:

/usr/bin/time -v tmp/foss-post/graphify/.venv/bin/graphify cluster-only \
  /tmp/graphify-local-sample \
  --no-label

Result:

Loading existing graph...
Graph: 19 nodes, 23 edges
Re-clustering...
Done - 4 communities. GRAPH_REPORT.md, graph.json and graph.html updated.

Measured locally:

Generated files:

/tmp/graphify-local-sample/graphify-out/graph.json
/tmp/graphify-local-sample/graphify-out/GRAPH_REPORT.md
/tmp/graphify-local-sample/graphify-out/graph.html
/tmp/graphify-local-sample/graphify-out/manifest.json

The report showed:

Extraction: 100% EXTRACTED - 0% INFERRED - 0% AMBIGUOUS
Token cost: 0 input - 0 output

That is exactly what I want from a local structural extraction pass.

Querying the Graph

I then queried the generated graph:

tmp/foss-post/graphify/.venv/bin/graphify query \
  "what calls greet" \
  --graph /tmp/graphify-local-sample/graphify-out/graph.json

The query term was fuzzy enough to land on the call-flow fixture and returned useful extracted edges:

Traversal: BFS depth=2
8 nodes found

EDGE run_analysis() --calls [EXTRACTED context=call]--> compute_score()
EDGE run_analysis() --calls [EXTRACTED context=call]--> normalize()
EDGE run_analysis() --calls [EXTRACTED context=call]--> .process()
EDGE compute_score() --calls [EXTRACTED context=call]--> .score()
EDGE normalize() --calls [EXTRACTED context=call]--> .full_pipeline()

I also tried a direct explain command:

tmp/foss-post/graphify/.venv/bin/graphify explain greet \
  --graph /tmp/graphify-local-sample/graphify-out/graph.json

That correctly answered:

No node matching 'greet' found.

So the query path is fuzzy, while the explain path needs a real node match.

Call-Flow HTML Export

Finally, I exported a call-flow page:

tmp/foss-post/graphify/.venv/bin/graphify export callflow-html \
  --graph /tmp/graphify-local-sample/graphify-out/graph.json \
  --output /tmp/graphify-local-sample/graphify-out/callflow.html

Output:

Call-flow HTML written: /tmp/graphify-local-sample/graphify-out/callflow.html
Sections: 4 | Mermaid diagrams: 3 | Call tables: 2

This is a nice companion artifact to the force-directed graph view when you want a more readable architecture page.

Does Graphify Need Docker?

No.

Graphify is a CLI and Python package, not a self-hosted web app in the default path.

I did not add a Home-Lab Docker Compose file for it because the repository does not ship an app-level Docker service to validate.

The clean reproducible unit is a Python tool install:

uv tool install graphifyy

If Graphify later grows an official server container or we build a small wrapper service around it, then it would make sense to add a Home-Lab/graphify/docker-compose.yml.

Useful Commands

Install:

uv tool install graphifyy
graphify install --platform codex

Project-scoped install:

graphify install --project --platform codex

Build a graph headlessly:

graphify extract . --out .

Update code extraction after changes:

graphify update .

Re-cluster without LLM community labels:

graphify cluster-only . --no-label

Query:

graphify query "what calls the payment flow?" --graph graphify-out/graph.json

Explain a node:

graphify explain "PaymentService" --graph graphify-out/graph.json

Export call-flow HTML:

graphify export callflow-html \
  --graph graphify-out/graph.json \
  --output graphify-out/callflow.html

Install git hooks:

graphify hook install

Remove Graphify integrations:

graphify uninstall

Remove integrations and graphify-out/:

graphify uninstall --purge

Optional Extras

Install only the capabilities you need:

For example:

uv tool install "graphifyy[pdf]"
uv tool install "graphifyy[terraform]"
uv tool install "graphifyy[openai]"

When I Would Use It

Graphify makes most sense when:

• the repository is large enough that reading files one by one is wasteful
• you want an assistant to answer architecture questions repeatedly
• you want call graphs, imports, central nodes, and communities extracted once
• you have mixed docs and code that should become a reusable graph
• you want an auditable local artifact instead of another opaque summary

For a six-file toy project, a graph may not save many tokens.

For a larger repository, a graph becomes much more interesting because the assistant can ask scoped questions against graph.json.

Caveats

The biggest practical caveats I found:

• The package name is graphifyy, not graphify.
• Ignore rules can make a scan find zero files if your target folder sits under an ignored path.
• Code-only extraction is local, but docs/images/PDF semantic extraction can use LLM APIs and token budget.
• Optional extras can add heavier dependencies.
• Community auto-labeling may need an LLM backend; use cluster-only --no-label for a local-only report.
• The repo’s older v1.0.0 tag can be confusing; current package metadata in this checkout is 0.8.33.

How Graphify Helps the Agentic Stack

Graphify is not another coding agent. It is context infrastructure for agents.

That makes it useful beside Codex CLI, OpenCode, Pi, OpenClaw, or Hermes Agent.

Those tools decide and act.

Graphify gives them a reusable map of the repository so they do not have to rediscover the same relationships every run.

The practical pattern is: generate the graph after a large refactor or before an agent session, then let the agent query the graph when it needs dependency, call-flow, or architecture context.

FAQ

graphify-out/
|-- graph.json
|-- graph.html
`-- GRAPH_REPORT.md

tmp/foss-post/graphify

/tmp/graphify-local-sample/graphify-out

uv tool install graphifyy
graphify extract . --out . --no-cluster
graphify cluster-only . --no-label

uv tool install graphifyy
graphify install --platform codex