The Working Directory & Your First Edits

Tier 0 · Total Beginner 9 min read

In your first session you created a file from scratch. The more common job is changing a file that already exists — fixing a line, updating a value, adding a function. This page explains the box the agent works inside (the working directory) and walks you through making and reviewing your first edit.

The working directory is the agent’s world

When you run claude from a folder, that folder becomes the working directory — the agent’s sandbox. By default, it reads and writes files inside that folder and its subfolders, and not outside it. This is deliberate. It means an agent you started in ~/my-website isn’t poking around in your photos or system files.

A few things follow from this:

Start the agent in the project you want to work on. If you launch from your home folder, it sees everything in your home folder. If you launch from a specific project, it sees only that project. Narrower is safer and clearer.
You don’t have to tell it which files exist. The agent can list and search the directory itself. Ask “where’s the main config file?” and it’ll go look rather than make you paste a path.
It reads on demand. Claude Code doesn’t load your whole project into memory up front. It opens files as it needs them, which is why it can work in large projects without choking.

Let’s make a real edit

We’ll set up a tiny project with one file, then ask the agent to change it — and, crucially, review the change before accepting it.

Create a project folder with a starter file. In your terminal:
Terminal window
```
mkdir ~/edit-practice
cd ~/edit-practice
printf 'Hello, World\nThis is my first project.\n' > hello.txt
```
You now have a folder with one file, hello.txt, containing two lines.
Start a session in that folder:
Terminal window
```
claude
```
Let it look first. Before changing anything, ask the agent to read what’s there:
```
What does hello.txt currently say?
```
It opens the file and reports the two lines back. Letting the agent read before it writes is a good habit — it works from the real content, not an assumption.

Ask for a specific change:

In hello.txt, change "Hello, World" to "Hello, Claude Code" — leave the second line alone.

Reading a diff before you approve

Here’s the part that matters most. When the agent edits an existing file, it doesn’t silently overwrite it. It shows you a diff — a side-by-side of what’s there now versus what it wants to change it to — and waits for your approval.

A diff typically marks removed lines and added lines so you can see exactly what’s changing. For our edit you’d see something like the old line being removed and the new line being added, with the untouched second line shown for context.

Read the diff before you approve. This is your safety check. Confirm three things:

It’s changing the right file.
It’s changing only what you asked — not “improving” the second line you told it to leave alone.
The change is actually correct.

If it all looks right, approve it. If it overreached — say it also “tidied up” a line you didn’t mention — reject it and clarify. You’re the reviewer; the agent is the one proposing.

Verify the result

After approving, confirm the change really took:

Show me hello.txt now.

It should read Hello, Claude Code on the first line and the second line unchanged. You can also check outside the agent — open the file in any text editor, or in the terminal. The edit is a normal file change; nothing magic, nothing hidden.

Scope discipline: ask for the change you want, not the cleanup you don’t

One habit that pays off immediately: tell the agent the specific change and explicitly fence off the rest. “Fix the typo in the heading — don’t touch anything else” gets you a clean, reviewable diff. A vague “clean up this file” invites the agent to rewrite things you liked, producing a sprawling diff you can’t safely review. Narrow asks → small diffs → easy review. (Tier 1’s prompting page goes deep on this.)

Next: Permissions & Safety Basics — those approve/deny prompts you’ve been clicking, what “bypass mode” is, and why “confirm before anything destructive” is a rule worth keeping.