How Claude Code Thinks
The foundation every senior engineer needs first — how Claude Code actually executes, persists knowledge, and is configured.
Claude Code isn't a chatbot — it's an agent running a continuous gather → act → verify loop. This article explains exactly how that loop works, what drives tool selection, why Claude sometimes gets stuck, and how a single prompt becomes a multi-step execution plan.
Every Claude Code session starts with a context window load sequence — system prompt, environment info, CLAUDE.md files, and MCP tool schemas. Understanding what lives in that window and how it fills up helps you avoid the two most common problems: context exhaustion and stale instructions.
Claude Code doesn't fumble through your codebase — it uses specialized tools for different kinds of discovery. Learn how Glob, Grep, and Read work together, why Claude avoids Bash for file operations, and the orientation strategy Claude uses when dropped into a large unfamiliar repo.
Plan Mode separates the gather phase from the execution phase — Claude reads and reasons freely, but cannot edit files. Use it to align on approach before a single line is changed. This article covers how to enter it, what Claude can and cannot do inside it, and when it's worth the overhead.
Claude Code automatically creates a checkpoint for every user prompt — a snapshot you can rewind to at any time. This article explains what checkpoints track, what they miss, your five restore options, and how checkpoints relate to git.
Claude Code's context window resets between sessions — but auto memory persists what matters to disk. This article explains the ~/.claude/projects/ directory structure, the four memory types, MEMORY.md as the index, and how to instruct Claude to remember or forget anything.
Claude Code resolves configuration through five layers — from enterprise-managed policies down to your personal user settings. Higher layers win over lower ones, but arrays merge instead of replace. This article walks through each layer, what it controls, and how to think about override scenarios.
CLAUDE.md is loaded at every session start — every byte costs tokens. This article covers the exact content that belongs in CLAUDE.md, what to leave out, effective structural patterns, and the token economics that should shape every decision you make about it.
When a single CLAUDE.md grows unwieldy, two mechanisms let you split it cleanly: @import for always-relevant content, and .claude/rules/ for domain-specific rules that load conditionally based on file glob patterns. This article covers the syntax, patterns, and when to use each.
CLAUDE.md contains suggestions — Claude follows them, but they can be overridden at runtime. True enforcement comes from two mechanisms: permissions (allow/deny lists for tools) and hooks (shell commands that run at lifecycle events). This article explains the difference and tells you which to use for which purpose.
CLAUDE.local.md is a gitignored project file for personal developer instructions that shouldn't pollute the team's shared CLAUDE.md. This article covers what it's for, why it should stay out of git, practical use cases, and how it sits in the overall configuration cascade.
Good memory architecture is the difference between Claude that feels like a collaborator and Claude that re-introduces itself every session. This article covers how to structure project memories for lasting usefulness, when memories go stale, team memory patterns, and why wrong memories are worse than no memories.