3.5 Session Habits That Keep You Safe

You've run a session. Before the training wheels come off in Chapter 4, this lesson installs the habits that let you move fast without moving reckless — because an agent with file access and command execution deserves the same respect as any powerful tool: not fear, procedure.

What you will learn

• Run the pre-flight and post-flight checklists that bracket every session.
• Set permission boundaries deliberately instead of clicking through them.
• Know the handful of in-session commands that manage the session itself.
• Recognize the three risk patterns that cause virtually all agent mishaps.

Builder principle

Fast is a byproduct of safe. The builder who knows what is recoverable can experiment without confusing a checkpoint for complete protection.

The bracket: pre-flight and post-flight

Every session, both lanes, no exceptions:

Pre-flight (30 seconds):

• pwd — I'm in the right project, and it's under ~/builds.
• git status --short — I understand every tracked and untracked path; valuable work is committed or backed up.
• I can say the session's goal in one sentence. (Can't? Not ready — write the brief first.)

Post-flight (60 seconds):

• git diff reviewed — I've seen what changed, not just heard about it.
• Result tested by me, as a user, per my "done means."
• Reviewed paths staged explicitly and committed — or selected tracked paths restored only after inspecting their diffs.
• git push — locked the door on the way out.
• One journal line: what worked, what didn't.

That's 90 seconds of ceremony buying you a clear recovery boundary. It does not reverse writes to remote services, databases, or files Git never tracked.

Permissions: gates, not speed bumps

When Claude Code asks "may I run this command / edit this file," that's a gate, and you're the gatekeeper. The professional move is a quick three-part read:

1. What is it trying to do?
2. Where — inside this project, or reaching outside it?
3. Reversible? Tracked file edits may be recoverable; untracked, ignored, destructive, installed, networked, and external-system actions need a separate plan. Slow down and identify the actual undo before approving.

As trust builds, Claude Code lets you pre-approve categories of routine actions so the gates you do see are the meaningful ones. That's the right evolution — reduce noise, never attention. What you're building toward (Chapter 9) is codified guardrails via hooks and settings, where your policy runs automatically. For now: read the gates.

The three patterns behind almost every mishap

1. Wrong room — session started in the wrong directory; agent edits files you didn't mean to expose. Killed by: pwd in pre-flight.
2. No snapshot — uncommitted work meets a sweeping change; no way back. Killed by: git status in pre-flight.
3. Rubber-stamping — approving gates on autopilot, including the one that mattered. Killed by: the three-part read, plus keeping sessions short enough that attention survives.

Managing the session itself

A few commands operate on the conversation rather than your files — learn these now, they appear in every future chapter:

Command	What it does	When
/clear	Wipes conversation context, fresh start	Between unrelated tasks — stale context pollutes (Lesson 2.2)
/usage	Shows plan allowance or API token estimates	Check before and after large sessions; use the Console for authoritative API billing
/help	Lists available commands	When you forget the others
++esc++	Interrupts the agent mid-action	The moment you see it heading somewhere wrong — steer early, don't wait
/exit	Ends the session	Post-flight time

The deeper skill behind /clear: one task, one context. When the site's done and you're switching to the newsletter draft, clear. You're managing the whiteboard now — that's Lesson 2.2 turned into muscle memory, and Chapter 5 builds a whole discipline on it.

For subscription plans, /usage shows plan-limit bars and activity rather than a billable session charge. For API users, its dollar figure is computed locally from token counts and is an estimate; authoritative billing lives in the Claude Console.

Secrets: the one non-negotiable

API keys and passwords never go in briefs, commits, or chat. Customer or personal data requires permission, minimization, and an approved environment; do not paste it into a model by default. If a build needs a key (Chapter 8 will), an environment variable or .env listed in .gitignore reduces source-control leakage only. It does not hide the value from local processes, shell commands, hooks, MCP servers, transcripts, the model, or provider systems allowed to receive it. Classify data as public, internal, confidential, or regulated; check authorization plus current provider retention/training controls; redact or use synthetic data. Regulated or client-confidential data stays out unless your organization has approved the controls.

Try it now

Run one complete bracketed session, end to end:

1. Full pre-flight in quick-win.
2. Session goal: Add a short "Now Learning" section to my site listing three things from this course, styled to match.
3. During: read every gate with the three-part read. Interrupt once with ++esc++ just to feel the brake, then let it continue.
4. Full post-flight, including the journal line.

Do this bracket every session for the next week and it stops being a checklist — it becomes how you work.

Check your understanding

• Recite the pre-flight from memory. What risk does each item kill?
• What's the three-part read at a permission gate?
• When do you /clear, and which Chapter 2 concept is it managing?
• Where do secrets live, and where do they never live?