Three things I deleted from my Claude Code setup this month (and one I almost did)

Quick Answer (June 2026): Over four weeks I deleted three pieces of my Claude Code setup that looked productive and were not: a custom statusline script, a wrapper around the Anthropic MCP server, and a blanket Edit autoaccept on my repo root. The one I almost cut, then kept, was per-project CLAUDE.md. Cutting the first three made my flow faster. Cutting CLAUDE.md would have cost me a week.

My Claude Code config got fat in May. Not in lines of code. In things I had to think about when something broke.

This is the cleanup log. June 2026. Not a guide. Field notes.

The setup before

I work out of one repo at a time, usually on a 16 inch MacBook, mostly Go on the backend and a Next.js frontend my cofounder owns. Claude Code is my primary pair, Cursor is the fallback for refactors that need a UI. I have been on Claude Code since the December 2025 build with the redesigned /settings.

My .claude/settings.json at the start of May had 38 lines. By June 1 it was 71 lines. None of the additions were features. All of them were hedges against something that bit me once.

That is the smell. Config grows because of one bad afternoon, not because of a real workflow shift.

Thing 1: the custom statusline

I had a Python script in .claude/statusline.sh that printed model name, cumulative token count for the session, and a tiny git branch indicator. About 40 lines, parsed JSON on every prompt.

# .claude/settings.json (the bad version)
"statusLine": {
  "command": "python3 .claude/statusline.sh",
  "refreshInterval": 200
}

It looked cool the first day. Then for three weeks I had a slow flicker in the bottom bar that broke me out of every long compile cycle. The token count, the thing I wrote it for, was never the reason I stopped working. I always stopped because I doubted the diff, not because I doubted the spend.

Deleted the whole block. Statusline back to the default. Two days later I had not missed it once. The official statusline docs at Anthropic's Claude Code settings reference recommend keeping the bar minimal for exactly this reason. I should have read that first.

Lesson, no nuance: if the dashboard you built does not change what you do, it is taxing you, not informing you.

Thing 2: my MCP wrapper

I had wrapped the Postgres MCP server in a small Node process that injected our staging connection string and intercepted writes. The wrapper logged every query to a sidecar file. Idea was paranoia: I did not want Claude Code accidentally DELETEing from a staging table I cared about.

Three problems showed up.

The wrapper broke on the FastMCP 2.4 release (May 18, 2026). Tool list calls started returning before the wrapper finished its init. Half my sessions opened with the Postgres tool missing entirely.

The sidecar log was never read. Not once, in six weeks. I had no review ritual for it. It was a vault I filed receipts into and never opened.

Third, Claude Code already prompts on every destructive SQL. The wrapper was reinventing a confirmation flow that the parent process did better.

I replaced the whole wrapper with two lines:

// .mcp.json
"postgres": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://..."]
}

Direct server, native confirmation prompts, no wrapper. I lost the logs I never read and gained back about 1.5 seconds per session start. The 30 day log I wrote on running MCP servers in production here on this journal is the longer version of why bare servers are usually fine.

Thing 3: blanket Edit autoaccept on the repo root

This is the one I am most embarrassed about.

I had this in .claude/settings.local.json:

{
  "permissions": {
    "allow": ["Edit", "Write"]
  }
}

No path prefix. Wildcard on Edit and Write for the whole working directory.

It did not bite me. It almost did.

On June 4 I asked Claude Code to rename a column in a migration. It correctly identified that the column also appeared in a hand-written changelog file at the repo root, and updated it. Good. It also pattern-matched the same string in our .env.example placeholder values and updated those too. Less good. The diff was visible, I caught it, I undid it before commit. But I had not been asked. The autoaccept skipped the moment where I would have said no.

Replaced with a scoped allowlist:

{
  "permissions": {
    "allow": [
      "Edit(src/**)",
      "Edit(internal/**)",
      "Write(src/**)",
      "Write(internal/**)"
    ]
  }
}

Dot files, env templates, migrations, configs, all now prompt. The friction is real, about 6 extra Enter presses per session. The blast radius is smaller. Trade I will take every day.

This was the same instinct that drove the keepers-vs-deleted subagents post earlier this month: default to less surface area, expand only when a specific pain shows up.

The one I almost cut: per-project CLAUDE.md

My CLAUDE.md is 84 lines. It documents the repo's module layout, the testing conventions, the lint rules we actually enforce, and three patterns I want Claude Code to never propose.

For about ten days in late May I thought it was dead weight. Claude reads it on every session, the prefix tokens add up, and I could not point to one specific moment where the file had saved me.

Then I switched branches to a hotfix on a service I had not touched since February. Cold cache, half remembered conventions, two new MCP servers since I last shipped here. The CLAUDE.md for that service caught me up in 30 seconds. Without it I would have spent 15 minutes hunting the same context out of git log and tests.

That is the trick with CLAUDE.md. It pays out on the days you are not in flow, not the days you are. If you only measure during flow days you will delete it. Do not.

The shape of a cleanup

Looking back at the four decisions, the pattern is plain.

Keep things that compound on bad days. Cut things that flatter you on good days.

The statusline, the wrapper, the wildcard permission. All three looked like control. None of them returned a moment I would point at. CLAUDE.md does not look like much. It is the only one that paid out when I needed it.

My settings.json is back down to 41 lines. I have not added one this week.

FAQ

Is a custom statusline always a bad idea?
No. If you genuinely act on what it shows you, keep it. The test is whether you can name a moment in the last week where you changed direction because of the bar. If you cannot, delete it.

Should I always run MCP servers bare instead of wrapped?
Mostly yes for solo or two-person teams. Wrappers make sense when you have a real audit requirement (compliance, regulated data) and someone whose job it is to read the audit log. Otherwise the wrapper is theater.

Is allowlisting Edit(src/**) enough?
It is enough for me because my repo cleanly separates code from config. If yours does not, lean smaller. Allow specific subdirectories you trust, prompt for everything else.

How long should CLAUDE.md be?
Long enough that a teammate who has never seen the repo could open a PR after reading it. Mine is 84 lines. Some are 300. The cost of an extra 50 lines of context is real but tiny compared to the cost of bad first suggestions on a service you are cold on.

What about hooks?
I removed two hooks this month too. A PostToolUse formatter that was redundant with my editor's format-on-save, and a Stop notification that fired during long compile cycles and trained me to ignore notifications. Hooks are powerful and dangerous. Same principle: keep what compounds, cut what flatters.

Did you use any AI to write this post?
First draft was me, in a long Notes file on the train back from a client. Final pass was in Claude Code, asking it to fact check the FastMCP 2.4 release date and clean up the code blocks. I left the prose untouched because I want the post to sound like the messy notes it started as.

Sources and further reading

• Claude Code settings reference (June 2026 docs)
• Claude Code permissions and tools (June 2026 docs)
• Model Context Protocol server reference
• DevMoment, MCP server in production: 30 day log (June 21, 2026)
• DevMoment, Claude Code subagents I kept vs deleted (June 20, 2026)

p.s. The hardest delete is always the one you wrote three weekends ago. Plan to delete it from the first commit.