rigswig

See everything your coding agent loads before you type, and where each piece came from.

Start here: getting started — install it, three commands, and what each one tells you.

Screenshots of an invented setup, rebuilt with docs/demo/make-demo.sh and taken with docs/demo/shoot.mjs.

A coding agent's harness is everything around the model: instruction files (CLAUDE.md, AGENTS.md, GEMINI.md, rules), subagents, skills, commands, hooks, MCP servers, plugins, permissions and the model setting, spread across user, project, local and managed scopes. rigswig reads all of it for a repo and shows what a session there actually gets, which scope decided each setting, what is overridden, and roughly how much context it costs before you type a word.

Status: 0.2, pre-1.0. rigswig status, rigswig audit and the local page, rigswig ui, work for every harness in the table below. rigswig usage reads Claude Code's session logs only, for now; the other harnesses are next. See docs/ROADMAP.md.

rigswig is a single binary written in Rust. Install it with cargo install rigswig (crates.io; add --no-default-features for a build with no network code), with npx rigswig or npm install -g rigswig (npm: the package installs the right prebuilt binary for your platform), or download it for macOS, Linux or Windows from the releases, each with a SHA256SUMS line to check it against. On macOS or Linux, brew install overfocus/tap/rigswig installs the same release binaries through Homebrew (the tap). From a checkout:

cargo run -- status --repo path/to/repo          # a summary
cargo run -- status --repo path/to/repo --json   # everything, as schema/harness.schema.json describes
cargo run -- ui --repo path/to/repo              # the same as a page on 127.0.0.1, behind a random token
cargo run -- compare repo-a repo-b               # what differs between two repos, one harness
cargo run -- compare path/to/repo --tools claude-code,codex   # or between two harnesses on one repo
cargo run -- check --repo path/to/repo --max-tokens 40k        # for CI: exit 1 when the budget is passed
cargo run -- check --repo path/to/repo --strict               # or when the reading was incomplete/ambiguous
cargo run -- check --repo path/to/repo --baseline rigswig-baseline.json   # only new warnings/failures are debt
cargo run -- status --repo path/to/repo --without layer:user   # what-if: the totals without some items
cargo run -- audit --repo path/to/repo                          # ranked findings, each with a saving and a fix
cargo run -- audit --repos '~/code/*'                           # fleet: each user-scope item against every repo
cargo run -- audit --github owner/repo                          # a public GitHub repo, in memory, without your setup
cargo run -- audit --archive repo.tar.gz                        # the same for an archive you downloaded, offline
cargo run -- usage --repo path/to/repo                          # what past sessions here invoked, metadata only
cargo run -- audit --repo path/to/repo --usage                  # findings that know what the sessions called

--without is an exact file-backed simulation: the adapter resolves again with those files absent, so a shadowed winner returns and warnings, package contributions and budgets are recomputed. A selection which shares a settings file with unselected items is refused rather than deleting those siblings; structured config-item simulation remains on the roadmap.

check --json is a versioned baseline file. Save and review one, then add --baseline <file> to carry existing warnings and failing checks while rejecting only new debt; fixed debt is reported and dropping a previously failing check is refused. rigswig reads but never writes the baseline. See docs/BASELINES.md.

rigswig audit turns the numbers into a to-do list: user-scope agents and skills that nothing in the repo references, plugins switched on everywhere that the repo's files don't call for, instruction files over budget, sentences repeated across layers, paths and scripts the instructions name that don't exist, and permission rules that have piled up or allow too much. Each finding carries its evidence, the tokens it would save (computed like --without) and a proposed change. Fleet mode answers the question a single repo can't: which repos need each user-scope item, so it can move to those repos' project scope. The page runs both too, with a progress bar, and lets you filter the findings and jump from one to the items it names. See docs/AUDIT.md.

The page is local: it listens on 127.0.0.1 only, answers only requests that carry its token and the right Host, loads nothing from anywhere else, and stops after 30 minutes without a request. It is read-only unless started with --allow-writes, which lets it turn plugins and project MCP servers on and off, each with a preview (the file, the diff, the budget before and after), a backup and undo: see docs/WRITE-MODE.md.

Guarantees

These are the point of the tool, and they will be enforced by tests:

• No network unless you ask. rigswig sends no telemetry and makes no request, except one: --github owner/repo downloads that public repo's archive from codeload.github.com, only in the run you give it to, or for each GitHub audit you start on a page launched with ui --allow-github (GitHub repos). Build with --no-default-features for a rigswig with no network code at all.
• No model calls. Everything it shows is read from files on your machine.
• Read-only by default. Nothing is ever written unless you start the page with rigswig ui --allow-writes (write mode).
• An MCP server. rigswig mcp serves the five read-only surfaces as MCP tools over stdio, so a harness can ask rigswig about a checkout from inside its own session — Claude Code, Cursor, Gemini CLI, DeepSeek-CLI, VS Code and anything else that launches stdio servers (the server and its registration).
• In your editor. A thin VS Code / Cursor extension: the bill and the audit's findings in the status bar, a refresh/open toolbar on the page panel, and the read-only page itself. It spawns the CLI you already have; it starts nothing in write mode and never opts a run into session logs (the extension and its logic tests).
• No secrets. MCP server env, headers and args, URL paths and inline hook code are never printed or served.
• Session logs only when you ask, and only their metadata. No command opens a session log unless the run asks for it: rigswig usage or rigswig audit --usage, never the page or the MCP server. Even then, rigswig reads only ids, times, the working folder, models, token counts, and the names of the agents, skills and MCP servers that were called. It never keeps, prints or serves message text, thinking, tool inputs or tool results (what is read, field by field). This replaces the earlier "No transcripts" promise (what changed). (Claude Code's auto-memory index, MEMORY.md, is read and counted in every run because it loads into every session.) The one look a run makes without asking is the default picker's is-a-session-live check: file names, kinds and modification times of a session folder and the harness home, never a file's contents — with one whitelisted exception: Hermes's per-terminal session records (~/.hermes/terminal-sessions/*), tiny gateway state files parsed only for their cwd field (the folder a session runs in — nothing else is kept, and anything bigger than a record is refused), written once at spawn, with freshness joined to the home's own live activity, so a launched session can be attributed to its repo for as long as the home shows one, without any log being opened. Only a fresh artifact that names this repo can influence interactive status / ui (--no-session keeps that pick evidence-only); activity known only at machine scope is evidence in tools, and check, audit, compare and MCP always use the repo's own evidence. A remote reading carries none of it — it has nothing from this machine.
• Private folders stay private. List them in ~/.rigswig/private.json ({"private": ["~/notes"]}): rigswig refuses them as a repo, and audit --repos skips them.

Harnesses

Harness-agnostic: each harness is an adapter that reads its own files into one shared data model.

Related tools

Other tools work on the same question, and are worth a look: harness-map (Codex and Claude Code, with a what-if mode), whatloads (Claude Code's context bill), claude-config-auditor (lint and CI), and Claude Code's own /context.

Licence

Apache-2.0.