Claude CodeFailure Modes

Claude Code anti-patterns: what to stop doing

In brief

The failure-mode companion to every Claude Code setup guide. CLAUDE.md that's too big, MCP servers left running, sessions you never close, skipping Plan Mode, asking quick questions in the main thread — here's what each one costs you and how to fix it.

6 min read·

Contents

♡Sign in to save

Most Claude Code guides tell you what to set up. This one covers what to stop doing. The patterns below are common, each one has a real cost, and most of them are fixable in under five minutes.

Anti-pattern 1: A CLAUDE.md that never gets trimmed

CLAUDE.md is where you put project context, coding standards, and instructions Claude should follow. Teams add to it over time and rarely remove anything. By month three, it's often 400+ lines of accumulated rules, some of which contradict each other and half of which Claude can't meaningfully act on.

The cost: every Claude Code session reads CLAUDE.md in full at the start. A bloated CLAUDE.md means more tokens consumed before Claude writes a single line of code, and more noise in the context that dilutes the instructions that actually matter.

The fix: treat CLAUDE.md like a codebase. Review it quarterly. Remove rules that are no longer relevant. Consolidate rules that overlap. The effective limit is around 200 lines — past that, you're adding noise, not context. See CLAUDE.md maintenance for the full process.

Signal you've hit this: Claude starts ignoring specific rules from CLAUDE.md. That's usually a sign the file is too long and the relevant instruction is getting crowded out.

Anti-pattern 2: Expensive MCP servers always running

MCP servers extend Claude Code's capabilities — connecting it to databases, APIs, external tools. The problem: every connected MCP server adds tokens to every context window, even when Claude doesn't need to use it for the current task.

A team with 8 MCP servers configured might have 3–4 relevant to any given task. The other 4 are burning context space for free.

The cost: when context usage climbs past roughly 10% from MCP overhead, Claude Code switches into tool search mode — it has to actively scan its available tools before using them, which adds latency and token use.

The fix: connect only the MCP servers you actually use for the current project. For servers used occasionally (a database tool you need for data migrations but not daily coding), remove them from the default config and add them when needed. Use Skills for simpler integrations — they're lighter weight than full MCP servers for repeatable tasks.

The "money pit" pattern: A team that connected every available MCP integration "because we might need it" and then wondered why their Claude Code sessions were running slow and expensive. The overhead was entirely from tools sitting idle.

Anti-pattern 3: Asking quick questions in the main session thread

You're partway through a coding task. You have a quick question — should I use a class or a function here, what does this error mean, how does this library work. You ask it in the main thread.

The cost: that question and its answer now sit in your main session's context permanently. The next message Claude writes processes everything including the tangent. If you do this five times in a session, you've added significant dead weight to every subsequent response.

The fix: use side chat (⌘+; on Mac, Ctrl+; on Windows). Side chat pulls context from the main session so Claude understands where you are, but the conversation doesn't add back to the main thread. Ask your question, get your answer, close it. The main session stays clean.

This is what side chat was specifically built for. Most people who have it available don't use it because they don't know it exists.

Anti-pattern 4: Skipping Plan Mode

The instinct when you have a coding task: open Claude Code, describe what you want, let it run. This works for small tasks. For anything involving multiple files or non-obvious architecture decisions, skipping Plan Mode costs more time than it saves.

The cost: Claude starts coding based on its first interpretation of your request. When that interpretation is slightly off — different file structure than you wanted, different pattern than your codebase uses, different approach than you had in mind — you spend the next several turns correcting it. Each correction processes the entire preceding session.

The fix: use Plan Mode first for multi-file tasks. Ask Claude to outline its approach before it writes a single line. You'll catch misalignments in 2 minutes that would otherwise take 20 minutes to untangle. For simple single-file tasks, Plan Mode is overkill — skip it. For anything that touches more than two files or has architectural implications, it pays for itself.

Ultraplan note: For complex tasks, Claude Code's Ultraplan uses a separate cloud planning call to generate a comprehensive implementation plan before any coding starts. Worth using when you're about to kick off a large feature.

Anti-pattern 5: Sessions you never close

Claude Code sessions accumulate in the sidebar. Developers often have 10–20 old sessions sitting open from tasks completed days ago.

To be clear: idle sessions don't cost money. You're not billed for sessions just sitting there. The issue is cognitive — you end up reopening the wrong session, continuing work in a stale context, or getting confused about which session has what state.

The fix: close sessions when work is done. The new session sidebar lets you filter by status — completed tasks should be archived. For sessions that produced useful output (a design decision, a working prototype, a complex debugging trace), export or summarize what you need before closing. Claude Code sessions aren't permanent memory.

Anti-pattern 6: Not using deferred tool loading

By default, Claude Code loads all available tool schemas at session start so it knows what it can do. For sessions with many tools configured, this is significant upfront context overhead even if most tools never get called.

Deferred tool loading changes this: tools are only loaded into context when Claude actually needs them. The first call to a tool triggers loading; subsequent calls that session are fast.

How to enable it: Add this to your Claude Code settings file (~/.claude/settings.json):

{
  "deferredToolLoading": true
}

Or toggle it in the Claude desktop app under Settings → Claude Code → Performance.

Most teams with more than 5–6 tools configured see a meaningful session startup improvement. Particularly useful if you have several MCP servers configured — they only load if and when Claude decides to use them.

Anti-pattern 7: CLAUDE.md instructions that contradict each other

Happens naturally as teams grow: one developer adds "always use TypeScript interfaces for object types," another adds "prefer type aliases for union types," and six months later both instructions are in CLAUDE.md pointing in different directions.

The cost: Claude follows one instruction, ignores the other, and the output is inconsistent. Different developers get different behavior from what should be a shared standard.

The fix: CLAUDE.md should have one owner — the person responsible for keeping it consistent. When new instructions are added, the owner reviews them for conflicts with existing rules. The quarterly audit process in CLAUDE.md maintenance catches accumulated contradictions before they cause persistent inconsistency.

The summary

Anti-pattern	What it costs	Fix
CLAUDE.md never trimmed	Token overhead + ignored rules	Quarterly audit, 200-line limit
Too many MCP servers	Slow sessions, tool search mode	Connect only what you use
Questions in main thread	Accumulating context noise	Use side chat (⌘+;)
Skipping Plan Mode	Costly misalignment corrections	Plan first for multi-file tasks
Sessions never closed	Navigation confusion (no cost)	Archive when work is done
Deferred loading off	High session startup cost	Set deferredToolLoading: true
Contradictory CLAUDE.md rules	Inconsistent behavior	Single owner, regular review