codag - Moses Yebei

The problem Teams building AI‑augmented codebases spend hours grepping for LLM calls, manually tracing branches, and rebuilding mental models after every prompt change. Codag automates that tracing: it extracts the full workflow, renders an interactive graph inside VS Code, and highlights which functions changed when files are edited.

What this does Codag analyses the codebase and produces a live, clickable DAG of every LLM call, decision branch, and data transformation. Key capabilities, grounded in the code, include:

Automatic workflow detection – tree‑sitter parsers scan 78 source files (70 TypeScript, 7 Python) and resolve 222 import edges, surfacing LLM calls from OpenAI, Anthropic, Gemini, LangChain, etc. The detection logic lives in frontend/src/tree-sitter/extractors.ts and frontend/src/analysis/workspace.ts.
Live graph updates – editing a file triggers an incremental re‑analysis; changed functions receive a green highlight. The update pathway runs through frontend/src/webview.ts → postMessage → state.ts.
Click‑to‑source navigation – each graph node links to the exact function and line. The navigation mesh is built in frontend/src/webview-client/state.ts (27 functions, called from 9 other files) and frontend/src/webview-client/messages.ts (1 → 16 edges).
Export to PNG – the graph can be exported as a high‑resolution PNG via frontend/src/webview-client/export.ts.
Native theme support – graphs automatically adopt the VS Code light/dark theme, using styles defined in frontend/media/webview/styles.css.

How it is wired Execution starts at two entry points:

Entry point	File	Reaches
`init`	`frontend/src/tree-sitter/parser-manager.ts:75`	50 functions; called from 2 places
`scheduleFileAnalysis`	`frontend/src/file-watching/handler.ts:47`	6 functions; called from 1 place

The internal call graph contains 748 resolved call edges. Notable hubs and cycles:

Hub module – frontend/src/webview-client/state.ts is depended on by 17 modules; any change has a broad blast radius.
Import cycles – four modules form circular dependencies: frontend/src/call-graph-extractor.ts, frontend/src/tree-sitter/extractors.ts, frontend/src/webview-client/directory.ts, and frontend/src/webview-client/visibility.ts.
Most connected functions – postMessage (34 callers), toRelativePath (20), log (16), estimateTokens (10).

Paths that leave the process: init → show → getHtml reads the filesystem via fs.readFileSync; outbound network calls are limited to 4 functions that make HTTP requests from backend/main.py.

How to use it The repository does not ship a documented start‑up script, but the presence of the following files gives a practical pathway:

Clone the repository: ``bash git clone https://github.com/moses-y/codag ``
Install dependencies (npm‑based front‑end, Python back‑end): ``bash cd codag/frontend && npm install cd ../backend && python -m pip install -r requirements.txt ``
Build / run the extension – the VS Code extension is packaged from frontend/. Typical commands (inferred from package.json scripts) are npm run compile and npm run watch, or load the extension folder directly into VS Code for development.
Start the backend server – run python backend/main.py (the entry point listed in the analysis) or use the provided Dockerfile: docker compose up --build.
Open VS Code and enable the Codag extension; the graph appears in the side panel and updates as you edit files.

If the README or package.json scripts differ, consult those files for the exact commands.

Real‑world use A developer joins a LangChain project with 20 files and nested tool calls. After opening the codebase in VS Code and activating Codag, the extension instantly maps every LLM call, decision branch, and data transformation. The graph highlights the exact function that failed after a prompt tweak, and a click jumps to the source line. The team exports a PNG for documentation and watches the graph update in real‑time as they refactor.

Code health & issues (measured static‑analysis findings)

[HIGH] Add a test suite – 78 source files, no test files exist. Any change ships with no regression signal.
[HIGH] Add a CI/CD workflow – no .github/ CI config; every merge runs untested.
[HIGH] Build gate for Docker image – backend/Dockerfile has no automated build validation.
[HIGH] Replace wildcard CORS origin – backend/main.py sets allow_origins=["*"] with credentials enabled, a security risk.
[MEDIUM] Enable Dependabot/Renovate – 3 manifest files, no update bot configured.
[MEDIUM] Pin container base image by digest – backend/Dockerfile uses python:3.11-slim without a digest.
[MEDIUM] Move large binaries out of repo – media/demo.gif is 21.5 MB; every clone pays that cost.
[MEDIUM] Add timeout to outbound requests – backend/Dockerfile has no timeout on the single outbound call.
[MEDIUM] Add non‑root USER to Docker image – container runs as root; no USER directive.
[LOW] Add convention files – missing .editorconfig, .gitattributes, formatter config.

The bottom line Codag provides a powerful, in‑VS‑Code view of AI/LLM workflows with minimal configuration, making it easy to trace and visualise complex pipelines. The codebase suffers from a lack of tests, CI, and several security / maintenance gaps that should be addressed before production use, especially the CORS wildcard and missing test coverage. It is well‑suited for AI engineers and agent builders who need rapid insight into code‑level LLM interactions, provided the hygiene items are resolved.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

127 files

TypeScript70
Markdown10
JSON7
Python7
YAML1
JavaScript1

ReactDockerLangChain

Module dependencies

The 10 most depended-upon modules of 78, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_end_src_webview_client_state["state"] n1_src_webview_client_constants["constants"] n2_frontend_src_config["config"] n3_end_src_webview_client_types["types"] n4_frontend_src_cache["cache"] n5_frontend_src_analysis_state["state"] n6_end_src_call_graph_extractor["call-graph-extractor"] n7_frontend_src_repo_structure["repo-structure"] n8_frontend_src_api["api"] n9_end_src_webview_client_utils["utils"] n5_frontend_src_analysis_state --> n6_end_src_call_graph_extractor n5_frontend_src_analysis_state --> n7_frontend_src_repo_structure n4_frontend_src_cache --> n2_frontend_src_config n0_end_src_webview_client_state --> n3_end_src_webview_client_types n9_end_src_webview_client_utils --> n1_src_webview_client_constants classDef cyc stroke:#ef4444,stroke-width:2px; class n6_end_src_call_graph_extractor cyc;

Findings

MediumNo test files detected - untested code paths repository-wide
MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high4

medium5

low1

Add a test suite; this repository has nonehigh78 occurrences

78 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Add a workflow that builds and tests this repositoryhigh

78 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Add a build gate for the deployable artifacts herehigh2 occurrences

backend/Dockerfile

deployment artifacts with no workflow

Something in the repo is meant to reach a server and no automated step has ever validated it, which is the state of 125 repositories here.

Fix: Add a workflow that at least builds the image and validates the manifests.

Replace the wildcard CORS origin with an explicit allow listhigh

backend/main.py

allow_origins=["*"] together with credentials enabled

Any page on the internet can call the API with the browser's cookies attached, so a logged-in visitor to an unrelated site performs authenticated requests without knowing, and the wildcard combined with credentials is the exact configuration browsers refuse for that reason.

Fix: List the origins the API actually serves, and never pair a wildcard with credentials.

Enable Dependabot or Renovatemedium

3 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium

backend/Dockerfile

python:3.11-slim

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Move large binaries to Git LFS or out of the repositorymedium

media/demo.gif

1 blobs over 5MB: demo.gif 21.5MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Give the outbound request a timeoutmedium

backend/Dockerfile

1 outbound call(s) with no timeout

requests has no default timeout, so a peer that accepts the connection and then says nothing holds the worker forever, and with a small worker pool a single slow dependency takes the whole service down without anything appearing to fail.

Fix: Pass timeout= on every call, or use a session with one configured.

Add a non-root USER to the imagemedium

backend/Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.