Your first Claude Code session: the core loop, CLAUDE.md, /init, and resuming work

Welcome to the OCDevel Claude Code podcast. This is episode one, and it's the on-ramp.

Here's the shape of the whole show before we start, because it matters for how you should listen. We're climbing one ladder, rung by rung, over about thirty episodes. The bottom rung is where most people are today: one developer, one Claude Code session, driving it by hand and pressing enter on every step. The top rung, the place we're walking toward, is a pipeline that runs itself. You file a GitHub issue from your phone, and a wired-up loop implements the feature, opens a pull request, reviews its own work, fixes what it broke, runs the tests, and ships to production while you're somewhere with no laptop. Claude as the senior engineer on a one-person team. Every episode moves you one concrete step up that ladder, and nothing skips ahead.

Today is rung one. By the end of this episode you'll be productive in a single session: you'll understand the core loop you're actually driving, you'll have a project memory file that Claude reads every time, you'll know how to generate that file automatically, and you'll know how to walk away and pick the exact same conversation back up tomorrow. We're clustering several fundamentals into one fast starter, because you don't need a whole episode on any single command to get working. You need the handful that get you moving today.

A quick note on timing so this episode ages honestly. As of this recording in mid-2026, Claude Code is on the two-point-one line, and there was a meaningful change earlier this year worth knowing about. Anthropic switched the recommended install from the old Node package over to a standalone native installer. The native installer has no dependencies, doesn't need Node or the package manager, and updates itself quietly in the background. The old package install still works and is fully supported, but it's no longer the path they steer you to. There's also a model routing detail that's easy to get wrong: the default model depends on your plan. If you're on a Max, Team Premium, or Enterprise pay-as-you-go plan, or on the raw API, you default to Opus four-point-eight. If you're on Pro or a standard Team seat, you default to Sonnet four-point-six. And underneath all of that, Claude Code quietly routes the small background work, things like summarizing or naming, to Haiku, the cheap fast model. The mental model most developers settle into is simple: Sonnet is your daily driver, Opus is for the genuinely hard problems, Haiku is the high-volume grunt work you never think about. One catch worth writing down: Opus four-point-eight needs a recent build, so if you want it, check your version and update first.

Let me start there, with install and first launch, because it's thirty seconds and then we never talk about it again. On a Mac, Linux, or Windows Subsystem for Linux, you pipe the install script from claude dot a-i into bash. On Windows proper there's a PowerShell one-liner. If you live in Homebrew, there's a cask for it, though note Homebrew won't auto-update you, so you'll run an upgrade yourself now and then. Then you go into any project directory and type the word "claude" to start an interactive session. The first time, it sends you to the browser to log in, and after that your credentials are remembered. If you ever need to switch accounts, there's a slash login command. That's the whole setup. You're now sitting at a prompt inside your repo.

Now the part that actually matters, the thing this whole show is built on: the core loop. When you give Claude Code a task in plain English, it runs a loop with three blended phases, over and over, until the job is done. First it gathers context, reading and searching your files to understand the code. Then it takes action, editing files and running commands. Then it verifies, running your tests or checking the output, and course-correcting if something's off. Anthropic's own framing is that Claude decides what each step needs based on what it learned from the last step, chaining dozens of actions together and correcting along the way. The loop adapts to the task. A simple question might only need the gather phase. A real bug fix cycles through all three, several times.

Here's the concrete version, the example straight out of the docs. You say "fix the failing tests." Claude runs the suite to see what's actually broken. It reads the error output. It searches for the relevant source files, opens them, edits them to fix the issue, then runs the tests again to confirm. Each tool result feeds the next decision. You didn't tell it to run the tests first or which files to open. You stated the goal, and the loop figured out the path.

The single most important thing I can teach you in this episode is that you are inside that loop, not outside it. This is not a prompt box where you type a wish, hit enter, and pray. It's a conversation you can interrupt at any moment, and learning to steer mid-flight is the difference between fighting the tool and flying it. There are two moves. If Claude is heading the wrong direction and you want it to stop right now, press the escape key. That cancels whatever it's doing and hands control back to you. If you don't need to stop it, but you want to add a correction, just type your note and press enter. It doesn't interrupt the running action; Claude reads your message the moment the current step finishes and adjusts before its next move. The docs give a perfect little example. You say "fix the login bug." Claude starts investigating. You watch and realize it's looking in the wrong place, so you type, "that's not quite right, the issue is in the session handling," and Claude redirects. When the first attempt isn't right, you don't start over. You iterate.

Now, what keeps this from being terrifying is the permission system, the safety gate built into the loop. It's tiered, and the tiers are sensible. Read-only actions, like reading a file or searching, never ask for permission; they just happen. Anything that runs a shell command asks you first, and you can say "yes, and don't ask me again" for that exact command in that project. Anything that modifies a file asks you first too, and there "don't ask again" lasts until the end of the session. So out of the box, Claude can look at anything freely, but it cannot change a file or run a command without your say-so the first time.

Pair that with one more safety net: checkpoints. Before Claude edits a file, it quietly snapshots the old version. If an edit goes sideways, you tap the escape key twice to rewind to a previous state, or you just ask Claude to undo it. These checkpoints are local to your session and separate from git, and here's the important boundary: they only cover file changes. They can't un-deploy something or un-write a database row. That's exactly why Claude still asks before running commands that reach outside your files. So the posture I want you in for episode one is this: let Claude read freely, review its edits, and lean on rewind instead of fear. You can drive aggressively because you can always back up.

One more piece of the loop you'll touch constantly: permission modes. There's a keyboard shortcut, Shift plus Tab, that cycles through them, and you'll use it all day. Default mode asks before edits and commands, which is where you start. Auto-accept-edits mode stops asking about file edits so Claude can move fast on routine changes, while still checking with you on riskier commands. And tapping Shift-Tab one more time gets you into plan mode, which is read-only: Claude investigates and writes you a plan, but touches nothing until you approve it. Plan mode is your best friend for anything non-trivial, and we'll spend real time on it in a later episode. For now just know the shortcut exists and that it's how you dial the guardrails up and down on the fly.

So that's the loop: you state a goal, Claude gathers and acts and verifies, you steer with escape and with typed corrections, the permission prompts gate the dangerous parts, and checkpoints let you rewind. Everything else in this show is built on top of that one pattern.

Let's give Claude a memory. Right now, everything you tell it lives in one conversation and evaporates when that conversation ends. The fix is a file called CLAUDE dot md, your project memory. It's plain markdown that you write, and Claude reads it into context at the start of every single session. Think of it as the place you write down anything you'd otherwise have to re-explain every time. The build command. The test command. Your conventions. Where things live. The "always do this, never do that" rules.

It helps to be precise about how this differs from just telling Claude something. A one-off instruction in a conversation is gone next session, and it can even get lost mid-session when the context fills up. A line in your memory file gets reloaded automatically, every time, forever. There's a good rule of thumb from the docs for when a thing earns a place in that file: when Claude makes the same mistake twice, when a code review catches something Claude should have known, when you find yourself retyping the same correction you typed last session, or when a new teammate would need that same piece of context. If it passes one of those tests, write it down.

One thing to internalize early, because it saves you confusion later: this file is context, not enforced configuration. Claude reads it and tries hard to follow it, but there's no guarantee of strict compliance. It's an instruction to a smart collaborator, not a rule the system mechanically enforces. If you have something that absolutely must happen every time, like running the linter before a commit, a line in the memory file is the wrong tool, because Claude might forget. The right tool is a hook, which actually enforces the action regardless of what Claude decides. We've got a whole episode on hooks coming; for now, just hold the distinction. Memory file for guidance, hook for hard rules.

Where do these files live? There's a small hierarchy, and it loads from broadest to most specific. At the top, an organization can ship a managed policy file that applies to everyone and can't be turned off. Then there's a user-level file in your home claude folder that applies to you across every project. Then the project file, which sits in your repo root, or inside a dot-claude folder in the repo, and gets shared with your team through source control. And finally a local file you can keep just for yourself by adding it to your gitignore. They all stack together; the more specific ones don't replace the broader ones, they add to them. There's also a nesting behavior worth knowing: a memory file deeper in your directory tree loads on demand when Claude actually reads files in that area, while the ones above where you launched load up front. That nesting is its own topic we'll come back to, but it's good to know it exists.

What actually goes in the file? Be specific, because vague instructions are noise. The docs put it well: write "use two-space indentation," not "format code properly." Write "run the test command before committing," not "test your changes." Write "API handlers live in the source api handlers directory," not "keep files organized." Specifics Claude can act on. Platitudes it can't. And what does not belong are long multi-step procedures or instructions that only matter for one corner of the codebase. Those go somewhere else, either into a skill or into a path-scoped rule that only loads when Claude touches matching files. We'll cover both of those down the road.

Now the part people get wrong: size. Keep each memory file under about two hundred lines. This isn't a style preference, it's mechanical. The file loads in full every session no matter how long it is, so every extra line eats context and, past a point, actually reduces how well Claude follows any of it. There's roughly a budget of a hundred and fifty to two hundred instructions before adherence starts to slip, and the system already spends some of that before you write a word. So the discipline is ruthless. For every line, ask: would Claude get this wrong without it? If Claude already does the right thing on its own, the instruction is just noise, and noise costs you. One nice trick: block-level HTML comments in the file get stripped out before anything is sent to Claude, so you can leave notes for your human teammates that cost zero context.

How do you add to memory without hand-editing? A few ways. You can just tell Claude in conversation, "always use pnpm, not npm," or "the API tests need a local Redis running," and it will save that. If you specifically want it in the project memory file, say "add this to CLAUDE dot md." And there's a slash memory command that lists every memory file currently loaded in your session, lets you open any of them in your editor, and shows you what Claude can actually see right now. That last part is more useful than it sounds; we'll get to why in a minute.

There's a newer wrinkle in the memory story that's worth a beat, because it changes the picture from "memory is just the file I write." Recent versions add automatic memory. Alongside the file you write, Claude keeps its own notes, per repository, learning build commands and debugging insights and preferences it picks up as you work. You'll see little "writing memory" and "recalled memory" notes go by in the interface. So there are now two systems working together: the memory file, which is you telling Claude your standards and workflows, and auto memory, which is Claude recording what it learns. It's on by default in recent builds, and you can toggle it from that same slash memory command. You don't have to manage it actively today, but know it's there so you're not surprised when Claude remembers something you never wrote down.

Okay. Writing that memory file by hand from scratch sounds like a chore, and it would be, so you don't. You run the slash init command in your project root. Claude analyzes your codebase and writes a starter memory file for you: the build commands, the test instructions, the conventions it can discover by reading your code. For a typical TypeScript and Next.js project, a good generated file is short, well under that two-hundred-line ceiling, organized with markdown headers, and it'll capture your stack in a line, the dev and build and test and lint commands, where your routes and components and database migrations live, and the style conventions it detected, like two-space indents or named exports.

A couple of things make slash init safe and pleasant to use. First, it won't clobber an existing file. If you already have a memory file, init suggests improvements instead of overwriting it, so you can re-run it anytime as your project grows. Second, there's a newer guided flow you can opt into with an environment variable, where init asks which things you want it to set up, explores the codebase with a subagent, asks you follow-up questions to fill the gaps, and then shows you a reviewable proposal before it writes a single file. And if your repo already has one of those other agent instruction files, the kind other tools use, init will read it and fold the relevant parts in.

But here's the key habit: init gives you a draft, not a finished file. It writes down what it can discover by reading code. Your job is to add what it can't possibly know. The deploy quirk. The one test that's flaky. The "never touch the legacy folder" rule. The fact that you use pnpm and not npm. So the real move is: run init, then read what it produced, delete anything Claude already gets right on its own, and add the handful of things only a human on your team would know. That refined file is worth more than any amount of clever prompting later, because it's there every session without you lifting a finger.

Now let's make your work survive you closing the laptop. Sessions in Claude Code are saved continuously to local files as you work, so you can always come back to one after you exit, or even after you clear the screen. But, and this matters, every new session you start begins with a completely fresh context window. It does not remember your last conversation unless you explicitly resume it. So the question becomes: how do you get back into the conversation you had yesterday?

There are a few entry points, and the difference between them is worth getting straight. The simplest is claude dash dash continue, or just dash c, which reopens the most recent session in your current directory with zero fuss, no picking, no IDs. If you want to choose, claude dash dash resume, or dash r, opens an interactive picker showing your past sessions, each row with a name or summary, how long since you touched it, how many messages, and which git branch it was on. You can also resume from inside a running session with the slash resume command, so you can hop between conversations without quitting. And there's even a way to jump back to the session that created a particular pull request, which gets genuinely useful later in the show.

Hold onto one conceptual distinction here, because it'll save you a headache. Resuming reopens the same conversation under the same identity and appends your new messages to it; the entire history and all the context come back. That's different from forking, which copies the history into a brand-new session so you can try a different approach without disturbing the original. And both of those are different from starting fresh, which is either a brand-new session or clearing the current one, giving you an empty context window while the old conversation stays saved and resumable. So: resume to continue the same thread, fork to branch off and experiment from a known-good point, start fresh when the current conversation has gotten cluttered and you want a clean slate.

Two small quality-of-life things on top. You can name your sessions, which turns a meaningless string of characters in the picker into something like "auth-refactor" that you can actually scan for. You can name one at startup, or rename it mid-session, and accepting a plan in plan mode will even auto-name the session from the plan's content. And if you ever need to find where a conversation physically lives, the transcripts are stored as line-delimited JSON under your home claude folder, organized by project and session, kept for thirty days by default. You won't touch those often, but it's reassuring to know your work is just sitting there on disk.

Let me tie all of this together into the day-one workflow you can actually copy. This is the sequence, start to finish.

You clone your repo, change into it, and type "claude" to start. First run, you log in through the browser. You do a quick sanity check, confirming your version is recent enough for the model you want, and you can see your model and account at a glance and switch models if you need to. Then you run slash init, and Claude scans the project and writes you a starter memory file with your Next.js stack, your dev and build and test and lint commands, and your directory layout. You open that file and tune it: trim what Claude already gets right, and add what it can't discover, like "use pnpm," "API handlers live in the app api directory," "run the tests and the linter before committing," "never edit the legacy folder."

Now, before you let it loose on a real change, drop into plan mode with Shift-Tab and say something like, "read the api directory and understand how we handle auth sessions, then plan adding email validation to the registration endpoint." You read the plan, refine it in conversation, and accept it. Then you give it the real task, and the trick to a good task is specificity plus something to verify against. Instead of "fix the bug," you say, "users can submit the registration form empty; write a failing test first, then add input validation to fix it, and run the tests after." Even better, hand Claude concrete test cases right in the prompt, the input and the expected output, so it has a clear target to check its own work against. That single habit, giving Claude something to verify against, lifts the quality of what comes back more than almost anything else.

Then you review. This is the discipline that separates people who trust the tool from people who get burned by it. Don't blind-accept a wall of edits. Read the diff. Approve or reject change by change. If something's off, you already know the moves: type a correction and press enter to steer, press escape to stop, tap escape twice to rewind a bad edit. When you're happy, you commit conversationally, just asking Claude to commit with a good message, maybe asking it to make a branch first. And the next day, you type claude dash dash continue and you're right back in the same conversation, full context intact, no re-explaining. That's the loop of your working day.

Which brings us to the one pitfall you will absolutely hit, probably this week, so let's name it and learn to recognize it before it costs you. The failure mode is context degradation, and it usually shows up in one of two forms.

The first form is the never-ending session. You open one Claude session in the morning and keep it running all day across three unrelated tasks. By the afternoon, the quality has quietly fallen off a cliff. Claude starts forgetting instructions you gave it earlier, repeating mistakes you already corrected, ignoring rules that are right there in your memory file. What happened is the context window filled up, and the automatic compaction that kicks in to make room summarized away the early detail. The docs are direct about this: your requests and key code snippets are preserved, but detailed instructions from early in the conversation can get lost. How do you recognize it? Claude re-asks things it clearly knew an hour ago, it drifts from your conventions, or you notice it compacting frequently. There's a slash context command that shows you exactly what's filling the window; if it's near full, that's your signal.

The fix is a habit, not a setting. Clear the conversation between unrelated tasks. The old one is still saved and resumable, so you lose nothing, and the new task gets a clean window. When you want to keep a thread but shed the bulk, compact it with a focus instruction, telling Claude what to keep. And here's where the memory file earns its keep: anything that must persist should live in that file, not in chat, because the project memory file is re-read and re-injected after a compaction, while loose conversation detail is not. So the rule "always use pnpm" survives a compaction if it's in your memory file, and might not if you only said it once in conversation.

The second form is the bloated memory file. The init output tends to come out a little fat, and then over weeks you keep piling on instructions until you've blown past that two-hundred-line ceiling and adherence drops. Stale rules are actually worse than missing ones, because two contradictory lines make Claude pick one of them more or less at random. You recognize this when your memory file has crept well over two hundred lines, when Claude starts ignoring rules, or when you spot guidance that contradicts itself. The fix is the same ruthless trimming we talked about: if you can't explain why a line is there, delete it. Move path-specific or procedural content out into rules or skills. And periodically run that slash memory command to confirm which files are actually loaded, because if a file isn't on that list, Claude can't see it, and you may have been talking to a memory file Claude was never reading.

There's a close cousin to this worth thirty seconds, because beginners reach for it to stop the permission prompts: the temptation to turn the guardrails off entirely, either with the skip-permissions flag or by hammering "accept all." Please resist it this early. The better move, which we'll build out properly in the next episode, is to allow only the specific, trusted commands you actually repeat, like your test command and your commit command, in your settings file, and otherwise stay in default or auto-accept-edits mode and lean on checkpoints. The prompts feel like friction on day one. They're also the thing standing between you and an unreviewed bad edit, and you have rewind for when one slips through anyway.

So let's mark where you are. You can install and launch Claude Code, and you understand the model situation well enough to pick the right one. You understand the core loop, gather, act, verify, and more importantly you know you're inside it, steering with escape and with typed corrections, gated by permission prompts, backed up by checkpoints. You can give Claude a durable memory with a tight, specific memory file, generate a first draft of it with slash init, and refine it with the things only you know. You can walk away and resume the exact same conversation tomorrow, and you understand the difference between resuming, forking, and starting fresh. And you can spot the one pitfall, context going stale, in both its forms, and you know the habits that fix it: clear between tasks, compact with focus, keep the memory file lean, and put what must persist where it'll actually survive.

That's rung one. You're a solo developer driving one session by hand, and now you're driving it well. Next episode we climb to the settings file, permissions, and plan mode in real depth: how to stop the prompt fatigue the right way, how to scope what Claude can do safely, and how to look before you leap on anything that matters. We're one rung up. The laptop is still very much in your hands, but the climb has started.