Harness & Memory

You've built three things. You've also felt the friction — re-explaining context, full-window warnings, forgetting what worked last week. This page is the fix. You'll learn the layer around Claude (the harness) and the system that lets Claude remember you between sessions (auto-memory), plus the small set of habits that separate someone fighting the tool from someone cooperating with it.

0 / 0 steps

Why You're Here

If you worked through the three exercises, you hit some version of these:

Claude asking permission for the same command every single time
"Context window almost full" warning in the middle of a good session
Re-explaining the project, the stack, or your preferences for the fourth time
Digging through old terminal scrollback to remember what approach you tried last Tuesday
Claude reading 30 files to answer one question, and now the conversation is sluggish

Page 1 taught you the foundation — CLAUDE.md at the project root, plus a context/ folder with PROJECT.md and JOURNAL.md. Those are project files you maintain by hand (with Claude's help). This page is the next level: a separate, harness-level memory system that Claude maintains for you, configuring the harness so it stops asking permission for safe things, and using subagents to keep your main conversation lean.

Model vs. harness. Claude is the model — the thing that generates text. The harness is everything around it: your terminal window, the permission system, the tools it can call, hooks that fire on events, settings files, memory. When people say "Claude won't do X," nine times out of ten they mean "my harness isn't set up to let Claude do X." Once you understand the difference, you stop fighting the model and start configuring the harness.

I recognize at least two of those frictions. Let's fix them.

Auto-Memory — Claude Remembers You

Claude Code has a built-in memory system that persists across every conversation in a project. It's separate from the context/JOURNAL.md you maintain by hand. You don't write it. You tell Claude things, and Claude writes them for you.

Where it lives: C:\Users\[you]\.claude\projects\[encoded-project-path]\memory\

Inside that folder is a MEMORY.md index and a bunch of individual .md files, one per memory. Claude reads this folder at the start of every conversation in that project. You can open the files and edit them yourself — they're just text.

Four types of memory (Claude decides which type based on what you're saving):

user — who you are, your role, what you know, how you like to communicate
feedback — corrections and preferences ("don't do X," "keep doing Y")
project — ongoing goals, deadlines, decisions specific to this project
reference — pointers to external stuff ("bugs are tracked in Linear project ACME")

How to save a memory: just tell Claude.

Remember that I prefer TypeScript over JavaScript for new files.

Remember that our production database is Postgres 15, not MySQL.

How to forget:

Forget the thing about TypeScript. I'm back on plain JS for this project.

How to see what Claude remembers:

What do you remember about me and this project?

Project JOURNAL.md vs. harness auto-memory. You now have two memory systems and that's fine — they answer different questions. context/JOURNAL.md lives in the project. It travels with the codebase. It's the record of what happened on this project — "we finished the email backend today, next up is OAuth." Auto-memory lives in your user profile. It does not travel with the codebase. It's the record of who you are and how to work with you — "my clients are Spanish-speaking HVAC shops," "I prefer terse responses." Different scopes, different lifetimes, different homes.

Told Claude to remember something about me. Confirmed with "what do you remember about me?"

Opened the memory folder in File Explorer and saw the files Claude wrote. They're just text.

The Harness — settings.json, Permissions, Hooks

Claude Code reads a settings file on startup. Two locations:

Global (applies everywhere): C:\Users\[you]\.claude\settings.json
Project (just this folder): [project]\.claude\settings.json

Project settings override global settings. Start global and only drop project-specific overrides when you have a real reason.

Permissions — stop getting asked the same question every time.

By default, Claude asks before running most shell commands. That's good. But after the tenth "yes, run npm install" prompt, you want to allowlist the safe ones. Example global settings.json:

~/.claude/settings.json { "permissions": { "allow": [ "Bash(npm install)", "Bash(npm run *)", "Bash(git status)", "Bash(git diff *)", "Bash(git log *)", "Read", "Grep", "Glob" ] } }

Now Claude runs those without asking. Still asks for anything destructive — rm, git push, git reset --hard, editing files outside your project. That's the point.

Don't allowlist things that can't be undone. Never add rm, git push --force, git reset --hard, database drops, or anything that writes outside your project directory. Those prompts exist for a reason. The two seconds you save aren't worth the bad Tuesday when Claude misreads a file and nukes something you needed.

Hooks — run scripts on events.

Hooks are shell commands the harness runs when certain things happen: before a tool call, after Claude stops, when you submit a prompt. Common uses:

Play a sound when Claude finishes a long task (so you can tab away)
Run your linter after every file edit
Log every bash command to a file for audit
Block edits to files you've marked as protected

Hooks are a rabbit hole. You don't need them on day one. File the concept away and come back when you notice yourself repeating the same post-Claude action manually every session — that's when a hook pays for itself.

I know where settings.json lives. I allowlisted a few safe commands I use constantly.

Slash Commands & Skills

Slash commands are shortcuts you type inside a Claude conversation. They start with /. The essential ones:

/clear — restart the conversation, drop all context. Use this OFTEN.
/compact — summarize the conversation so far and drop the raw history. Useful when you want to keep going but the window is tight.
/init — scaffold a CLAUDE.md for a project that doesn't have one yet.
/review — have Claude review the pending changes on your current branch.
/help — list everything available.

Skills are slash commands that come with their own instructions. They're like little pre-built recipes. /review is a skill. /init is a skill. You can install more, and you can write your own.

When to write a custom skill. If you find yourself giving Claude the same multi-paragraph instructions at the start of every session ("review this code for X, Y, Z using these conventions"), turn it into a skill. Next time, you just type /my-review and Claude already knows what to do. Custom skills are folders of instructions under ~/.claude/skills/ — ask Claude to build one for you when you need it.

The /clear habit. This is the single most important habit in this tutorial. Claude's context window is finite. Every file read, every tool call, every long response eats space. When the window fills, things slow down and eventually crash. /clear resets it in one second.

Use it:

After a big file read or multi-file search
When you switch tasks ("OK, new topic...")
After 45+ minutes of heavy work
Any time things feel sluggish

The cost of /clear is ten seconds of re-reading your CLAUDE.md and auto-memory. The cost of a crash is the whole session.

I typed /help and saw the list. I know /clear is the important one.

Subagents — Delegate the Heavy Reading

Sometimes the right next step is "read 30 files and tell me where we call the QBO API." If Claude does that in your main conversation, those 30 file contents are now in your context window. Two more tasks like that and you're full.

A subagent is a fresh, separate Claude instance with its own context. Your main Claude delegates the task, the subagent does the heavy reading, and comes back with a short summary. The raw file contents never touch your main conversation.

Analogy: Your main Claude is the project manager. Subagents are interns you send to the library. They come back with one-paragraph answers, not stacks of photocopies.

How to trigger one: just ask.

Use a subagent to find every place we talk to the QBO API and summarize the pattern.

Delegate to an Explore agent: what does our auth flow look like end to end?

When to use a subagent:

Any task that requires reading more than a handful of files
Researching how something works across the codebase
"Find all the places where..."
Running several independent searches in parallel

When NOT to use one:

Tasks that need the context you've built up in the current conversation
Single-file edits
Anything interactive that needs back-and-forth

I know when to say "use a subagent" instead of doing it in the main thread.

MCP Servers — One Paragraph

MCP stands for Model Context Protocol. It's how Claude Code talks to outside services — Gmail, Google Calendar, Drive, Slack, databases, custom APIs. You add an MCP server to your settings, authorize it once, and now Claude can "read my inbox" or "create a calendar event" directly.

Why you care: every time you've copy-pasted something from Claude into Gmail, or asked Claude to draft an email you then sent manually, an MCP server would have done it for you. Same for pulling client data out of a Google Sheet, scheduling a meeting, or dropping a file into shared Drive.

This is a full tutorial on its own. For now, just know:

MCP servers live in settings.json under an mcpServers block
Anthropic publishes servers for Gmail, Calendar, and Drive
Third parties publish servers for Slack, Notion, Linear, Postgres, and more
You can write your own — that's how custom middleware tools get hooked into Claude

When you're ready, ask Claude to walk you through adding one. The Gmail server is a good first one — immediate payoff, low risk.

I know what MCP is and roughly when I'd want one. Parked for later.

A Working Rhythm

The habits that separate a smooth Claude Code session from a frustrating one. None of these are complicated. They're just the things you forget until they bite you.

The rhythm:

Start in the right folder. cd into your project, then claude. Claude reads the right CLAUDE.md and the right auto-memory.
If this is a new project, /init.
Say what you're doing in one sentence. Claude plans, you approve.
Delegate reads of more than a few files to a subagent.
/clear between tasks. Not between messages — between tasks.
When you catch yourself repeating a preference, say "remember that..." and move on.
At the end of the session, ask Claude to update context/JOURNAL.md with what happened.

Signs you're losing the plot:

Responses are getting slow — /clear
Claude keeps forgetting something you told it this session — say "remember that" to save it to auto-memory
You're scrolling scrollback to find something — that's a JOURNAL.md update you should have done last session
Same permission prompt for the fifth time — allowlist it in settings.json
You gave a five-paragraph instruction and Claude only followed the last paragraph — break it into smaller steps

Pruning. Memory gets stale. Every month or two, skim your auto-memory folder and delete anything that's no longer true. Same for JOURNAL.md in your projects — if an entry from four months ago isn't serving you, move it to context/archive/ (or delete it). Memory is supposed to reduce load, not become its own maintenance burden.

I have a mental model for when to /clear, when to delegate, and when to save memory.

You're done with the series.

Open a terminal, cd into whichever project is on your mind, type claude, and build the thing.

Back to the beginning

Harness & Memory

That's the Whole Series.

You're done with the series.