claude-config-dashboard

A local, zero-dependency dashboard for understanding your Claude Code setup and configuration across all of your projects — at a glance.

It reads the config Claude Code already keeps on your machine (~/.claude.json and ~/.claude/) and serves a single-page dashboard in your browser. Your config data never leaves your machine — no telemetry, no account, no upload. Anyone you share it with sees their own setup. (The only outbound requests the page makes are for the Poppins font + Phosphor icon CSS from public CDNs, purely for styling — it falls back to system fonts/labels offline. A Content-Security-Policy restricts the page to those two CDN origins, and the Phosphor CSS is version-pinned with subresource integrity.)

Styled with the Datarails design system, with a built-in Clean ↔ Datarails theme toggle.

What it shows

| Tab | Contents | |-----|----------| | Overview | Clickable inventory cards (projects, skills, MCP, plugins, agents/commands, hooks, memory), active model & effort (incl. a rules summary), and a Usage section — tokens, sessions/messages, daily-activity chart, per-model usage, and a "when you work" hour-of-day chart — computed live from your session transcripts (incrementally cached), not from Claude Code's stale-prone stats-cache.json | | Projects | Every project Claude Code knows about — last used, last-session cost, token usage, lines added/removed, duration, MCP servers, and flags (own CLAUDE.md, .claude/, allow-listed tools). Sortable + searchable. Each row has a history chip that opens that project's past conversations and lets you resume one in the tool of your choice, plus a 🧠 memory count — open the row to read the memories Claude keeps for that project. | | MCP Servers | claude.ai connectors grouped by Connected vs Needs authentication, local servers (transport + command + where used), plugin-provided servers, and project-scoped / .mcp.json servers. Each server row has a Manage action: move/copy its definition between global and project scope, enable/disable a committed .mcp.json server's per-project approval, or delete it (recoverable). | | Skills | Skill usage counts + last-used and your on-disk skill definitions (user-scope and per-project). Each definition can be moved between scopes, copied into another project, or deleted (recoverable — quarantined, not erased) — individually via a per-row Manage action or in bulk via multi-select. | | Agents | Your subagents, custom slash commands, and output styles (user-scope and per-project), each shown with its scope and a move between user and project scope | | Plugins | Installed plugins (version, scope, install date, enabled), and configured marketplaces | | Workflows | Multi-agent workflow runs grouped under the request that launched them, with per-workflow run times, phases, and sub-agents | | Settings & Hooks | Configured hooks, account/org/plan, config paths, your raw settings.json, and the instruction layers that get injected into your prompts (global CLAUDE.md + each rules/ namespace and the refs/ docs it points at) |

Wherever the dashboard shows a file or folder location, it's clickable: it opens a beautified, in-browser preview — JSON gets syntax-highlighted, Markdown (CLAUDE.md, SKILL.md) renders with a Raw/Rendered toggle, and directories become browsable. You can copy the contents or pop the file open in your OS's default app.

Conversation history & resume

The history chip on each Projects row lists that project's saved conversations (read straight from the transcripts Claude Code keeps in ~/.claude/projects/) — opening prompt, where it ran (CLI / Desktop / VS Code), when it was last active, how many prompts you sent, git branch, CLI version, and any pull requests it opened (linked). For any conversation you can:

• Copy claude --resume <id> — the universal way to resume in any terminal.
• VS Code — opens the project in VS Code and copies claude --resume <id>; press Ctrl+` and paste to resume in the integrated terminal. (VS Code has no way to auto-run a command in its terminal on open.)
• VS Code panel — resumes the exact conversation in the Claude Code chat panel instead (open that folder as the workspace first, or it starts fresh).
• Terminal — opens a new terminal in the project folder and runs claude --resume <id> for you (true one-click resume). Falls back to copying the command if it can't launch.
• Warp — opens Warp in the project folder and copies the resume command, so you just paste (Warp's URL scheme can't auto-run a command).
• Desktop app — opens a new Code session in the folder (the desktop app can't yet resume by ID).

Most launches just hand a URL scheme (claude-cli://, vscode://, claude://, warp://) to your OS. The one exception is the Terminal button's one-click resume: it asks the local server to run claude --resume <id> in a new terminal (the only way to resume a session by id in a terminal). That endpoint is POST-only, refuses any session id that isn't a real transcript for that project, and only ever launches the fixed claude binary — see Privacy.

Memories, rules & agents

Beyond settings.json, Claude Code keeps several on-disk surfaces the dashboard now surfaces:

• Memories — the file-based memory Claude keeps per project under ~/.claude/projects/<project>/memory/ (a MEMORY.md index plus one fact per file). Each Projects row shows a 🧠 count; open the row and the drawer lists every memory grouped by type (user / feedback / project / reference), each clickable into the preview.
• Rules & refs — the instruction-injection layers under ~/.claude/rules/<namespace>/ (an index.md catalog, triggers.md / triggers.local.md phrase tables, and role-based .setup-meta.json) plus the ~/.claude/refs/<namespace>/ docs they point at. The Settings & Hooks tab summarizes each namespace (catalog / trigger / refs counts, per-role entries) with a clickable chip for every file.
• Subagents, slash commands & output styles — the markdown definitions under ~/.claude/{agents,commands,output-styles}/ (global scope) and each project's .claude/{...}/ (project scope), listed on the Agents tab with their model, tools, and scope.

All of these are read straight from disk and open in the same read-only, allow-listed preview as everything else — nothing leaves your machine.

Run it

You only need Node.js (which you already have if you run Claude Code).

# from this folder
node claude-dashboard.js

It scans your config, starts a local server on http://127.0.0.1:4317, and opens your browser. Hit ↻ Re-scan any time to pick up config changes. Ctrl+C to stop.

Options

node claude-dashboard.js              # scan + open the dashboard
node claude-dashboard.js --json       # print the scanned data as JSON and exit
node claude-dashboard.js --port 5000  # serve on a specific port
node claude-dashboard.js --no-open    # start the server but don't open a browser
node claude-dashboard.js --help

It honors CLAUDE_CONFIG_DIR if you've relocated your Claude config.

Sharing it with others

It has no runtime dependencies, so sharing stays simple:

• Nicest (recommended): publish to npm so anyone can run it with no install:

  npm publish            # one-time, from this folder

  then they just run:

  npx claude-config-dashboard

• No npm? Send them the whole folder (claude-dashboard.js + the lib/ and public/ directories next to it), or a tarball built with npm pack — they unpack it and run node claude-dashboard.js. (The dashboard is a small set of plain Node files with no node_modules, but claude-dashboard.js loads its ./lib/* modules and serves its UI from ./public, so both folders need to sit alongside it — copying the single file won't run.)

Everyone who runs it sees a dashboard of their own local Claude Code setup.

Privacy

• 100% local. No data is sent anywhere.
• File previews are read-only and restricted to your Claude config tree + tracked project folders; the server refuses to read anything outside that allow-list.
• Account UUIDs are intentionally omitted from the UI; only your email / org / plan are shown (useful when you're looking at your own machine).
• The --json output and the dashboard reflect only what Claude Code already stores locally.
• The dashboard can edit your Claude Code config — plugins, permissions, settings (model / effort / output style / env / statusLine), hooks, marketplaces, memory facts, MCP servers, and scope-moves for skills / subagents / commands / output styles — plus open files, resume sessions, and launch agent tasks. Every one of these is a POST-only action you trigger yourself: /api/open, /api/resume, /api/agent-task, /api/marketplace, /api/plugin-enablement, /api/permission, /api/setting, /api/object-setting, /api/definition, /api/skill, /api/memory, /api/mcp, /api/hook. Everything else the server exposes is read-only.
• Every POST endpoint sits behind the same guards: the server binds to loopback only, checks the Host header against an allow-list (DNS-rebinding defense), rejects foreign Origin headers (CSRF defense), caps request bodies at 64 KB, and strictly validates every field per endpoint — file/path inputs are re-checked against the same allow-list as previews.
• All config writes funnel through one engine with a fixed safety contract (atomic writes, a one-time .ccdash.bak snapshot per file, corrupt files refused, deletes quarantined) — see How it works.
• The terminal launchers (/api/resume, /api/agent-task) only ever run the fixed claude binary, and any free text goes into a task file the agent reads — never onto a command line — so they can't be steered to run anything else. /api/resume additionally validates that the session id is a real transcript for that project before launching.

How it works

A small zero-dependency Node program (claude-dashboard.js + the lib/ modules):

1. Locates ~/.claude.json + ~/.claude/ (or CLAUDE_CONFIG_DIR).
2. Reads settings.json, plugins/installed_plugins.json, on-disk skills, subagents / commands / output styles, rules/ + refs/, per-project memory/, hooks, and the per-project telemetry Claude Code caches. Usage stats (tokens, sessions, daily activity) are computed from the session transcripts themselves with an incremental per-file cache (~/.claude/.ccdash-usage-cache.json), falling back to Claude Code's stats-cache.json only when no transcripts exist.
3. Serves a vanilla-JS single-page app (Poppins + Phosphor load from CDN with graceful offline fallback) that fetches the scan from a tiny built-in /api/data endpoint. File previews are served read-only from an /api/file endpoint that is allow-listed to your ~/.claude config tree and the project folders Claude Code already tracks — it will not serve files from anywhere else on disk (your home dir, ~/.ssh, system files, etc.). Conversation headers come from a read-only /api/sessions endpoint that reads only the transcript directory under your ~/.claude config tree (the project path is encoded into a single non-traversable segment, so it can't be used to escape that tree).
4. Applies edits through a single write engine (lib/configwrite.js), fed by the config endpoints (/api/marketplace, /api/plugin-enablement, /api/permission, /api/setting, /api/object-setting, /api/definition, /api/skill, /api/memory, /api/mcp, /api/hook). Settings-file writes follow one contract: strict-parse the JSON, mutate exactly one key, write atomically (temp file + rename) — unknown keys and indentation round-trip verbatim, the first edit to a file snapshots a one-time <file>.ccdash.bak you can revert to, and a file that doesn't parse is refused, never clobbered. File moves (skills / subagents / commands / output styles) never overwrite an existing destination, and a skill "delete" quarantines the folder into ~/.claude/.ccdash-trash/ (recoverable) rather than erasing it. MCP edits stay inside ~/.claude.json (a server definition is relocated verbatim between global and project scope, never re-authored from typed text) and never rewrite a project's committed .mcp.json — enabling/disabling a committed server only toggles your local approval arrays, and a deleted definition is preserved in a .ccdash-trash/ breadcrumb. Repo-scoped writes only ever target the repo's main checkout — never its ephemeral worktrees. The launch endpoints (/api/open, /api/resume, /api/agent-task) sit outside the engine: they open a path in your default app or run the fixed claude binary in a new terminal (/api/resume validates the session id against the project's transcripts first; /api/agent-task writes your prompt to a task file the agent reads — free text never lands on a command line).

No build step, no node_modules. Theme preference persists in localStorage.

License

MIT