Last, I wrote about the configuration sprawl problem in Claude Code¹. Stale artifacts are piling up across projects. API keys are buried in conversation caches. Permissions are drifting without any centralized view. Settings files silently corrupted by heredocs and oversized entries.

The response told me what I already suspected: a lot of people have this problem. Very few are doing anything about it.

So here’s what I built to fix it.

The moment that started this

I was running Claude Code across about a dozen active projects and maybe twenty more in various states of abandonment. I wanted to answer a simple question… what MCP servers do I have configured across all my projects, and are any of them still pointing at things that no longer exist?

There was no way to answer that question without manually opening every .mcp.json and every settings.json across every project directory. One at a time. By hand.

I did it once. Then I built a tool so I’d never have to do it again.

Claude Toolkit

Claude Toolkit² is a desktop application for managing, cleaning, and securing your Claude Code configuration files. It runs on Windows and macOS, built in .NET MAUI, a real native app, not an Electron wrapper consuming 400MB of RAM to display a file tree.

The core workflow is simple… scan, review, act.

1. Scan your system to discover every .claude directory, every .mcp.json, every .claude.json, every configuration artifact Claude Code has created.
2. Review what you’ve got… components, permissions, security findings, and settings health.
3. Act on what needs to change… clean stale artifacts, fix corrupted settings, rotate exposed secrets, tighten permissions.

Here’s what each piece actually does and why it exists.

Artifact discovery: seeing the full picture

The first problem is visibility. You don’t know what you have.

Claude Toolkit scans your filesystem and builds an inventory. Every .claude directory, every standalone config file, is organized by project with size, last access time, and a component breakdown.

Each artifact gets classified by what’s inside it: settings files, MCP server configs, skills, hooks, commands, project context files, conversation caches, logs, and credentials. You can see at a glance which projects have active, meaningful configuration and which are carrying 15MB of stale conversation cache from a session you ran two months ago.

Stale artifacts — anything not accessed in 30+ days — get flagged in amber. Not deleted automatically. Flagged. Because the decision to clean should be yours, made with full context.

The scan across my own system, the first time I ran it, found 88 artifacts totaling 361MB. A third of that was stale. I had .claude directories in projects I’d forgotten I’d used Claude Code on.

Security scanning: finding what shouldn’t be there

This is the feature that pays for itself immediately.

The security scanner analyzes every file in every discovered artifact and looks for hardcoded secrets. OpenAI API keys. GitHub personal access tokens. AWS credentials. SSH private keys. Database connection strings. Generic passwords and bearer tokens.

Findings are classified by severity — Critical, High, Medium, Low — with the file path, line number, a redacted preview of the value, and a specific recommendation for remediation.

The key distinction the scanner makes: safe-to-clean files versus config files. If a secret is found in a conversation cache or log file, that’s a file you can clean without breaking anything. The scanner will replace the secret with [REMOVED] and move on. If a secret is found in an mcp.json file, that’s different; the config needs that value to function. The scanner flags it but doesn’t touch it, and tells you to move the secret to an environment variable.

My first security scan found 32 critical findings. Four of them were API keys in conversation caches I didn’t know existed. Those keys were still active.

That alone justified building this tool.

Settings validation: fixing the silent corruption

Claude Code’s settings files accumulate problems that don’t cause visible errors but degrade your configuration over time.

The settings validator checks every settings.json and settings.local.json across all your projects for specific classes of issues:

• Oversized permissions: entries that exceed 200 characters. These are almost always accidental. A git commit message that got captured as a permission string. A heredoc that ended up in the allow list. The validator catches them and suggests a clean replacement. A 2,847-character permission string that starts with Bash(git commit -m "🤖 Generated with Claude... gets suggested as Bash(git:*).
• Embedded heredocs: multiline content that got pasted into what should be a single-line permission entry. Same cause, same fix.
• Stale paths: permissions that reference directories or files that no longer exist. You moved a project, renamed a folder, or deleted a directory, but the permission entry still points at the old path.
• Duplicates: the same permission string appearing multiple times in the same file. Harmless but noisy.

Most of these have auto-fix options. Select the issues, click fix, and confirm. The validator writes the cleaned settings back. No manual JSON editing required.

The permissions matrix: the feature I wish existed from day one

This is the one that changes how you think about Claude Code configuration.

The Permissions Manager loads every settings file across all your projects and displays them in a matrix. Rows are permission strings. Columns are files. Each cell shows the state: Allowed, Denied, or Not Set.

For the first time, you can see, in a single view, what Claude Code is allowed to do across your entire environment.

You can see that Bash(git:*) is allowed globally and in Project A, but not set in Project B. You can see that WebFetch(domain:*) is denied at the global level but allowed in one specific project. You can see which projects have blanket Read permissions and which have scoped paths.

You can filter by permission type, search by text, or toggle “show differences only” to see just the permissions that vary across projects.

And you can edit directly in the matrix. Change a permission state, add new permissions, remove old ones, and apply a permission to all files at once. Click Apply Changes, confirm, and every affected settings file gets updated.

Before this, managing permissions meant opening individual JSON files in a text editor and trying to hold the full picture in your head. That works for two projects. It doesn’t work for twelve.

Skills editor and MCP configuration

These are the creation tools… for when you need to build a new configuration rather than clean an existing configuration.

The Skills Editor creates and edits skill files with Markdown and YAML frontmatter. It has templates for common categories — code review, testing standards, API design, documentation style, security best practices — and a live preview so you can verify formatting before saving. Nothing revolutionary, but a meaningful improvement over editing Markdown files in a text editor without any awareness of the expected structure.

The MCP Editor manages server definitions in .mcp.json files. It has presets for common servers — filesystem access, GitHub, GitLab, SQLite, PostgreSQL, Brave Search, Puppeteer, and more — so you can add a new MCP server by selecting a preset, naming the instance, and entering the required environment variables. Custom servers are supported for anything not in the preset list.

Both tools exist because configuration creation should be as structured as configuration management. Knowing the expected format of a skill file or MCP config shouldn’t require reading documentation every time.

The Project Context Editor

CLAUDE.md files are one of the most impactful parts of Claude Code’s configuration; they tell Claude about your project’s tech stack, conventions, key files, and constraints. They’re also one of the most neglected, because there’s no structured way to create or maintain them.

The Project Context Editor provides Markdown editing with live preview, template insertion for common sections, and a starting template if you don’t have a CLAUDE.md yet. It’s a small tool, but it removes the friction that keeps people from creating and maintaining the file that arguably has the most influence on Claude Code’s effectiveness in their project.

Why a native desktop app

I’ll be direct about this choice because I know it’s unusual.

Claude Code is a CLI tool. Most tooling built around CLI tools is also CLI. There’s a reasonable argument that this should be a command-line utility with JSON output.

But the core use case is reviewing and deciding. You need to look at scan results, evaluate which artifacts are stale, compare permissions across projects, and review security findings in context. These are visual, comparative tasks. They benefit from a real UI with panels, tables, filters, and context menus.

The permissions matrix alone, rows of permissions against columns of files with state indicators, is fundamentally a GUI concept. Trying to render that in a terminal is a worse experience for everyone.

.NET MAUI gives me native performance on Windows and macOS from a shared codebase, without the memory overhead of a web runtime packaged as a desktop app. The app runs, does its job, and doesn’t consume resources while you’re doing something else.

For my Linux users… don’t feel left out. I will soon post a version using my OpenMaui Linux platform, which I wrote for .NET Maui, which means you will have a native app for your distro, too.

What’s next

Next, I’ll publish the operational playbook… the maintenance cadence and best practices for Claude Code power users. Weekly scans, monthly security reviews, the permissions philosophy that keeps config from drifting, and the security practices that keep secrets out of config files in the first place.

Claude Toolkit is the enabling tool. The playbook is the system that makes it work.

Because tools without process are just software you installed once and forgot about.

And we already have enough of that problem with .claude directories.