Orihime

Orihime

A cross-repository code knowledge graph for Java/Kotlin/JavaScript/TypeScript codebases. Orihime indexes your source code into an embedded KuzuDB graph database using tree-sitter and exposes the graph through an MCP server (for AI assistants), a local web UI, and a CLI.

Mythology: Orihime (織姫) is Vega — the weaving princess who weaves the fabric of the cosmos. She weaves connections. The tool that weaves your codebase into a single graph.

---

What It Does

• Call graph across repositories — who calls what, across service boundaries, including REST calls resolved to the endpoint they target
• Cross-repo taint analysis — track user-controlled data from HTTP/Kafka/JMS entry points through the call graph to dangerous sinks (SQL injection, path traversal, XXE, deserialization, SSRF, log injection, …)
• Security reports — OWASP Top 10, CWE, PCI DSS, STIG frameworks; second-order injection detection; custom sources/sinks via YAML
• Entry-point reachability filtering — suppress false positives from dead code; only surface findings reachable from real entry points (HTTP handlers, @KafkaListener, @Scheduled, @JmsListener, @RabbitListener)
• Complexity hints — static O(n²) loop detection, N+1 JPA risk, unbounded queries, recursive calls — no profiler needed
• Performance correlation — ingest Gatling/JMeter load test results; correlate with the call graph to find confirmed hotspots and Little's Law capacity ceilings per endpoint
• License compliance — scan Maven/Gradle dependencies against SPDX identifiers; flag GPL/AGPL/LGPL in commercial projects
• Incremental re-index — git blob-hash-based skip; only changed files are re-parsed on subsequent runs
• Multi-language — Java, Kotlin, JavaScript, TypeScript (Next.js, Express, React)

---

Quick Start — AI-first (Claude Code)

The primary way to use Orihime is through an AI assistant via MCP. You index once, then ask questions in natural language — no Cypher, no grep, no reading source files.

1. Install

git clone https://github.com/srinivasan-sundaresan95/orihime.git
cd orihime
pip install -e .

2. Register with Claude Code (one-time setup)

python -m orihime register       # writes MCP server entry to ~/.claude/settings.json
python -m orihime install-skills # copies Claude Code skills to ~/.claude/skills/

Restart Claude Code. The orihime MCP tools and skills (/orihime-call-flow, /orihime-security-audit, /orihime-perf-analysis, /orihime-change-impact) are now active.

3. Index your repositories

python -m orihime index --repo /path/to/your/service-a --name service-a
python -m orihime index --repo /path/to/your/service-b --name service-b

4. Ask questions

Trace the call flow for GET /api/orders in service-a
Find SQL injection risks in service-b
What breaks if I change OrderService.processPayment?
Which endpoints are approaching saturation?

No source file reads. No grep. Claude uses the graph directly — typically 5–8 tool calls vs 30+ for source-only analysis.

CLI alternative: All operations above are also available as Python commands (python -m orihime index, python -m orihime ui, etc.) if you prefer working outside an AI assistant. See CLI Reference below.

---

Feature Comparison

¹ Via the official sonarqube-mcp-server (SonarSource, production-ready). Works with all SonarQube editions. ² Custom taint sources/sinks require the Advanced Security add-on (Enterprise+). ³ License compliance (SBOM + policy enforcement) requires the Advanced Security add-on (Enterprise+).

GitNexus (PolyForm Non-Commercial) provides cross-repo call graphs and MCP integration across 14 languages including Java and Kotlin. It does not cover SAST, perf analysis, or compliance reporting.

---

MCP Tools Reference

Call Graph

Discovery

ORM / JPA

Security (SAST)

Complexity & Performance

License Compliance

Index

---

CLI Reference

All operations are also accessible directly without an AI assistant:

python -m orihime index        --repo PATH  --name NAME  [--db PATH] [--force] [--branch NAME]
python -m orihime ui           [--port 7700] [--db PATH]
python -m orihime serve
python -m orihime serve-sse    [--port 7702] [--db PATH]
python -m orihime resolve        [--db PATH]
python -m orihime write-server   [--port 7701] [--db PATH]
python -m orihime register       [--db PATH] [--python PATH]
python -m orihime install-skills

---

Web UI

http://localhost:7700

---

Configuration

Environment Variables

Custom Sources and Sinks

Create ~/.orihime/security_config.yaml (or set ORIHIME_SECURITY_CONFIG):

sources:
  - method_pattern: ".*getCustomUserInput"
    description: "Custom input source"

sinks:
  - method_pattern: ".*legacyExec"
    sink_type: "COMMAND_INJECTION"
    description: "Legacy shell executor"

sanitizers:
  - method_pattern: ".*sanitizeForLegacy"

The built-in config covers HttpServletRequest, @RequestParam, @PathVariable, @RequestBody, JDBC execute*, JPA native queries, Runtime.exec, ProcessBuilder, XML parsers, ObjectInputStream, Files.get, Paths.get, new URL, logging calls, and more.

---

Documentation

---

Team / Server Mode

KuzuDB has a single-writer constraint. In team deployments where multiple developers re-index simultaneously, run the write-serialization server:

# On the shared server — owns the KuzuDB connection
python -m orihime write-server --port 7701 --db /shared/orihime.db

# Each developer's indexer sends writes to the server
ORIHIME_SERVER_URL=http://server:7701 python -m orihime index --repo /path --name my-service

Developers running locally without ORIHIME_SERVER_URL open KuzuDB directly as always. The web UI and MCP server always read directly from KuzuDB (reads do not go through the write server).

---

Architecture

Source files
    │
    ▼ tree-sitter (Java, Kotlin, JS, TS)
ParseResult (plain Python dicts, picklable)
    │
    ▼ ProcessPoolExecutor (parallel parse workers)
Phase 2: KuzuDB writes (batched by table, 500-edge transactions)
    │
    ▼
KuzuDB embedded graph  ←──────────────────────────────┐
    │                                                   │
    ├── MCP server (FastMCP, stdio)                     │
    ├── Web UI (Starlette, port 7700)                   │
    └── Write server (FastAPI, port 7701, team mode) ──┘

Graph schema (SCHEMA_VERSION 10):

---

Performance

Query performance (graph DB)

Benchmarked on an 845-file Java/Kotlin service:

Batch write speedup vs naive per-row writes: 12×.

---

AI assistant benchmark — tracing a single call flow

Java/Kotlin codebase (845 + 224 files, measured)

Benchmarked on a 845-file Kotlin service and a 224-file Java service, tracing one controller endpoint through service → repositories → upstream APIs. GitNexus v1.6.3, Orihime v1.9, and a grep+source-read baseline were all measured on the same codebase on the same hardware (WSL2/Ubuntu, Intel i7, 2026-04-30).

Orihime vs baseline: 95% fewer tokens · 200–1,400× faster queries
Orihime vs GitNexus: 2.2× fewer tokens · 200–1,400× faster queries · MCP-native

The 7 Orihime tool calls produced ~80% of the structural picture (full controller→service→repo→upstream chain, 27 test methods surfaced, resilience wiring discovered automatically). The remaining ~20% — upstream API URLs, auth headers, branch-level control flow — requires targeted source reads, scoped to ~5 specific files rather than 27.

GitNexus's cold index is ~1.3× faster on NTFS (Node.js parse throughput advantage). On native Linux this gap narrows to near parity.

⁴ GitNexus query latency is dominated by live GitHub API round trips (1–3 per query × 500–2,000ms each, rate-limit dependent). Blast radius returned results in the wrong direction (upstream imports rather than downstream dependents).

---

License

MIT