CodeRisk

CodeRisk explains the risk around a code change before it is merged: what else tends to move with it, which dependencies expand its impact, who has context, and whether the area has enough tests or incident history to justify extra review.

Git can show that payments.py changed. CodeRisk is designed to answer the next questions:

What else historically changes with this file?
Which dependencies increase the blast radius?
Who last worked in this area?
Is the evidence strong enough to escalate review?

CodeRisk is currently a source-built, local prototype. It is useful as an engineering portfolio and an inspectable reference implementation; it is not yet a packaged end-user product.

What is implemented

• Detect explicit files, staged files, or all working-tree changes.
• Resolve renamed files against indexed history using exact paths and git log --follow.
• Score structural coupling, temporal co-change, and test-file ratio with repository-adaptive thresholds.
• Index GitHub commits, pull requests, issues, developers, and file relationships into PostgreSQL and Neo4j.
• Surface function-level history and ownership with crisk log and crisk blame after optional code-block atomization.
• Run an optional Gemini-backed second-stage investigation for changes that cross the Phase 1 threshold.
• Expose indexed risk evidence through an MCP server for coding-agent workflows.

CodeRisk does not currently integrate with Slack. A Phase 2 directive can print a manual copy/paste contact message, but the public website's crisk check --draft command and pip installation instructions are not implemented in this repository.

CLI at a glance

$ ./bin/crisk --help
CodeRisk analyzes changed files using repository structure, Git history,
test evidence, ownership, and linked incident context.

Selected commands:
  blame       Show ownership and risk attribution for functions
  check       Assess risk for changed files using baseline metrics
  ingest      Build the Neo4j graph from staged PostgreSQL data
  init        Initialize analysis for the current repository
  log         Show semantic function history across renames

crisk check accepts file paths directly, auto-detects working-tree changes when no paths are supplied, and supports --pre-commit, --no-ai, --quiet, --explain, and --ai-mode.

Installation

The only installation path supported by the current repository is building from source. There are no published release assets, working Homebrew formula, or Python package produced here.

Prerequisites:

• Go 1.24 or newer with CGO support
• Git
• Docker with Compose, for PostgreSQL, Neo4j, and Redis
• A GitHub token for repository ingestion
• A Gemini API key only for optional LLM extraction and investigation

git clone https://github.com/rohankatakam/coderisk.git
cd coderisk
make build
./bin/crisk --version

Quickstart

The full workflow builds a local evidence graph, so it requires local services and access to the GitHub repository being analyzed.

# 1. Configure local services. Replace the example passwords and add GITHUB_TOKEN.
cp .env.example .env

# 2. Start PostgreSQL, Neo4j, and Redis.
docker compose up -d

# 3. Export the token for the CLI process.
export GITHUB_TOKEN='<your token>'

# 4. From the repository you want to analyze, run CodeRisk by absolute path.
cd /path/to/your/project
/path/to/coderisk/bin/crisk init --days 90

# 5. Change or stage a file, then run the deterministic Phase 1 analysis.
/path/to/coderisk/bin/crisk check --no-ai

# Optional: inspect function ownership after LLM-backed atomization.
/path/to/coderisk/bin/crisk blame src/example.ts

To build function-level records during initialization, set GEMINI_API_KEY and add --llm --enable-atomization. Without those flags, initialization still builds the GitHub/file graph used by the baseline checks.

For a safe smoke test that needs no credentials or databases, run ./bin/crisk --help. In an initialized Git repository with no working-tree changes:

$ CRISK_MODE=development /path/to/coderisk/bin/crisk check --no-ai
✅ No changed files to check

Architecture

flowchart LR
    A["Git repository + GitHub history"] --> B["crisk init"]
    B --> C["PostgreSQL facts"]
    B --> D["Neo4j relationships"]
    C --> E["Phase 1 metrics"]
    D --> E
    E --> F["crisk check"]
    C --> G["crisk log / blame"]
    D --> G
    C --> H["MCP risk summary"]
    D --> H
    E -. "threshold crossed + API key" .-> I["Gemini investigation"]

Loading

PostgreSQL is the system of record for fetched GitHub facts and code-block metadata. Neo4j stores navigable repository relationships used for coupling and impact queries. The CLI coordinates ingestion and reads both stores for analysis. See Architecture, Risk model, and MCP integration.

Supported languages and workflows

Area	Current support
Source-file indexing	JavaScript, JSX, TypeScript, TSX, Python
Diff chunking / language labels	Broader extension-based handling, including Go, Java, Ruby, Rust, and others
Change selection	Explicit paths, unstaged/staged working-tree changes, pre-commit mode
Evidence	Dependencies, historical co-change, test-file ratio, ownership, issues/PRs
Interfaces	Go CLI and local stdio MCP server
LLM workflow	Optional Gemini extraction and second-stage investigation

The broader extension detector should not be read as full parser support. The current repository walker only indexes the JavaScript/TypeScript and Python families listed above.

Limitations

• Initialization depends on PostgreSQL, Neo4j, a GitHub token, and a repository with a GitHub origin.
• Function-level log and blame data requires the optional atomization pipeline.
• Phase 2 depends on Gemini and Redis; Phase 1 can be run with --no-ai.
• The “blast radius” is evidence from stored dependencies, co-change, and incident links, not a runtime call-graph guarantee.
• There is no Slack API/sender, --draft command, web dashboard, pip package, supported Homebrew tap, or published binary release.
• Source ingestion is not yet a general multi-language parser.

Development and verification

gofmt -w path/to/changed.go
go test ./...
go vet ./...
make build

The Docker-backed integration scripts require the local services and test credentials described in Development. Unit tests should not require production credentials.

Status and roadmap

Current status: public beta/prototype. The default Go tests and local builds are green; Docker-backed ingestion and end-to-end workflows still require an explicitly configured local environment.

Near-term roadmap:

1. Keep go test ./..., go vet ./..., and release builds continuously green.
2. Add deterministic fixtures for end-to-end risk output without external credentials.
3. Expand source indexing beyond JavaScript/TypeScript and Python.
4. Publish signed release artifacts before reintroducing Homebrew or one-line installers.
5. Reconcile the public website with the supported Go workflow.

Future items are not implemented capabilities.

Contributing

See CONTRIBUTING.md. Security-sensitive configuration belongs in an untracked .env, never in commits or bug reports.

License

MIT