knobs.cc
// every knob Claude Code gives you, where it lives, what it's set to, which layer wins.
the problem
Claude Code's config surface is sprawling. Discovering
what's set, and which layer wins, is hard.
Six precedence layers. Three settings files. Environment variables that quietly override them. CLI flags that override those. Enterprise MDM policy that overrides everything.
When something doesn't behave the way you expect, which layer is to blame? knobs.cc lays it all out in one place, against the running claude process you point it at — not just the files on disk.
// ~/.claude/settings.json { "includeGitInstructions": true, "permissions": { "defaultMode": "plan" } } // .claude/settings.json (project) { "permissions": { "defaultMode": "acceptEdits" } } // shell env (process) CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS=1 // so what's actually in effect right now? // ── permissions.defaultMode → "acceptEdits" (PROJ) // ── includeGitInstructions → false (ENV)
catalog · live
Every documented Claude Code knob, synced from upstream.
Three catalogs wired into the inspector today — the rest queued.
Eight catalog files generated from upstream Claude Code docs and JSON Schema, regenerated weekly and on every doc change. All eight ship in v0 and feed read_catalog; the inspector reads three of them today, the rest are queued as UI consumers under #10.
[last upstream sync · 2026-05-14 · catalog-drift.yml]
precedence
Seven layers, highest wins.
The same model the inspector renders against.
For every key, knobs.cc walks all seven layers, records who contributed what, and shows you the winner plus the chain it shadowed. Array fields (like permissions.allow) merge with per-element provenance instead of last-write-wins.
the app
Pre-release. No signed installer yet.
Runs end-to-end from source today.
A Tauri 2 desktop app — React/Vite frontend, narrow Rust backend with four read-only commands. No fs, shell, or process plugins. No writes to your config files. Read-only is a v1 boundary, not a stepping stone.
clone · git clone github.com/AlteredCraft/knobs-cc
install · npm install
run · npm run tauri dev
attach · pick a running claude session from the topbar, or point at a project directory
// what's wired in v0 read_settings_layers → 6 real precedence layers per-leaf provenance array-merge for permissions read_runtime_layer → same-UID claude processes cwd · argv · environ read_catalog → upstream-derived reference loaded once at boot read_shell_env_vars → filter knobs.cc's own env against catalog names notify::Watcher → live settings-changed events to the UI
deep dives
Non-obvious mechanics, written down.
Mid-level technical writeups of how things actually work — less terse than the README, less exhaustive than the spec.
How env vars shadow settings keys
The env layer pretends to be a file layer. A nine-entry mapping at catalog/env-settings-map.json is the only place where the OS-env world bridges to the settings-key world — with type coercion and polarity inversion as pure data.
Grounding the inspector in a real claude process
Why project, cli, and env can't be resolved against knobs.cc's own working directory — and what reading another process's cwd / argv / environ via sysinfo lets you do honestly.
contribute
Early days. Issues over PRs.
What's useful right now
Corrections to the inventory — the catalog is upstream-driven, but the inventory captures things upstream doesn't (yet). Missing knobs you've spotted in the wild. Inspector UX feedback once you've run it. Design opinions on hero flow, hook-graph rendering, the deferred Goals view.
What's not useful yet
Substantial code PRs without an issue first — let's talk about the shape before you write it. spec/roadmap.md is the source of truth for what's slated and what's deferred.