Everyone’s talking about prompting. About agentic workflows. About which model is fastest, cheapest, and most capable?
Nobody’s talking about what gets left behind.
The invisible accumulation
If you’ve used Claude Code on more than a couple of projects, you already have this problem. You just don’t know it yet.
Every project gets a .claude directory. Inside that directory: settings files, MCP server configs, skill definitions, hooks, commands, conversation caches, logs. Some of it’s critical. Some of it’s stale. Most of it, you’ve never looked at after the initial setup.
Now multiply that by ten projects. Twenty. Fifty.
You’re sitting on a sprawl of configuration artifacts that nobody, including you, is managing.
Where it actually breaks
Here’s what the sprawl looks like in practice.
Permissions drift. You started a project with tight permissions. Claude asked for file access. You said yes. It asked for bash execution. You said yes. It asked for web fetch. You said yes. That was three months ago. Those permissions are still wide open. You’ve moved on to other things. The settings file hasn’t.
Now repeat that across every project you’ve touched. You have no centralized view of what permissions exist where, what’s allowed globally versus locally, or whether any of it still makes sense.
Hardcoded secrets in places you forgot exist. You pasted an API key during a Claude Code session. It ended up in a conversation cache file. That conversation is long over. The key is still there, sitting in a JSON file inside a .claude directory you haven’t opened since January.
This isn’t hypothetical. Run a grep for sk- or ghp_ across your .claude directories sometime. The results are educational.
Settings corruption. Claude Code’s settings files store permissions as JSON arrays of strings. Those strings are supposed to be clean permission entries like Bash(git:*) or Read(~/projects/my-app/**). What actually ends up in them? Git commit messages. Heredocs. Entire paragraphs that got accidentally pasted into a permission prompt. Permission strings that are 2,000+ characters long because something went sideways during an interactive session.
The settings file still loads. Claude Code doesn’t complain. The corruption just sits there, silently bloating your config.
Stale artifacts everywhere. That demo project from two months ago? Still has a .claude directory with 15MB of conversation cache. The experiment you abandoned? Still carrying MCP server definitions pointing at services you’ve since decommissioned. The prototype that became a real project? Running on config decisions you made before you understood what you were building.
None of this is urgent. All of it is accumulating.
The actual risk
The security angle alone should get your attention.
API keys in conversation caches aren’t protected by .gitignore patterns you set up for environment files. They’re inside .claude directories that most people don’t even know to exclude. If you’ve ever committed a .claude directory to version control, and plenty of people have, you may have pushed credentials to a remote repository without realizing it.
But the deeper risk is operational. When your permissions are scattered across dozens of settings files with no central view, you can’t answer basic questions about your own environment. What can Claude Code do in this project? What bash commands has it been granted access to? Is the global config overriding the project config or the other way around?
If you can’t answer those questions quickly, you’re not managing your AI tooling. Your AI tooling is managing you.
This is technical debt, and we’re pretending it doesn’t exist
The industry conversation around AI-assisted development is almost entirely focused on capability. What can the model do? How do I get better outputs? What’s the best way to structure a prompt?
These are valid questions. They’re also the easy questions.
The hard question is: what does the maintenance surface look like for AI-augmented development environments, and who’s responsible for it?
Traditional development tools have decades of ecosystem support around configuration management. Package managers have lockfiles. IDEs have settings sync. CI/CD pipelines have config-as-code. There are entire product categories built around managing the operational surface of development workflows.
AI coding tools have... nothing. You get a .claude directory, a few JSON files, and the assumption that you’ll manage it yourself. Which means you won’t.
The uncomfortable parallel
You’ve seen this pattern before.
Docker adoption in the early days followed the same curve. Everyone was excited about containers. Nobody was thinking about image sprawl, orphaned volumes, or dangling networks. It took years before tools like docker system prune became part of the standard workflow, and longer still before orchestration platforms handled cleanup automatically.
We’re in the “nobody’s thinking about cleanup” phase of AI-assisted development.
The configuration artifacts are accumulating. The security surface is expanding. The permissions are drifting. And the industry is too busy shipping new capabilities to notice.
What this actually requires
This isn’t a “be more careful” problem. Being more careful doesn’t scale across dozens of projects, multiple machines, and months of accumulated config state.
This requires tooling.
You need automated discovery, something that can scan your filesystem and tell you every .claude directory, every config file, every artifact that Claude Code has created across all your projects. You need security scanning that can find hardcoded secrets in conversation caches and config files before they end up in a commit. You need settings validation that catches the corrupted permission entries and oversized strings that silently degrade your config. You need a permissions matrix, a single view that shows you every permission across every project so you can see drift and act on it.
And you need a maintenance cadence. Weekly scans. Monthly security reviews. Regular cleanup of stale artifacts.
This is boring work. It’s also the work that separates people who use AI tools from people who operate AI tools sustainably.
What’s next
I built something.
It’s a desktop application called Claude Toolkit, and it does everything I just described… artifact discovery, security scanning, settings validation, permissions management, bulk cleanup with backups. It runs on Windows and macOS, and it exists because I got tired of managing this problem manually across my own projects.
Next, I’ll walk through what it does and why I built it as a native desktop app instead of yet another CLI tool.
For now, go look at your .claude directories. Count them. Check the sizes. Grep for API key patterns.
The sprawl is already there. The question is whether you’re going to manage it or let it manage you.