Your first Claude Code session, step by step

The best first session is on a project you know, with one small job you can check yourself. You learn more from watching it work on code you understand than from a demo.

Start it in the project folder

Claude Code works on the folder you start it in, so go there first:

cd ~/code/my-project
claude

Above the prompt it shows its version, the model and the folder. Everything it does in this session starts from here: it can read anything inside, and it asks before going outside.

Ask before you change anything

Your first message should be a question, not a task:

what does this project do, and how is it laid out?

Watch what happens. It does not answer from memory. It lists folders, opens the README and the main files, searches for names, and only then answers. That is the AgentAgentA model that uses tools in a loop, deciding each next step from what the last one returned, until the task is done. loop: it gathers what it needs, acts, and checks, with each step chosen from the one before.

Follow up with what you actually need to know: where is the login handled? or trace a request from the form to the database. If the answer is wrong, say so plainly. It is a conversation, and a correction costs less than starting again.

When you already know the file, name it with @:

explain the retry logic in @src/api/client.ts

The @ puts the file into your message, so it does not have to search. Typing @ alone opens a list of paths to pick from. A screenshot works too: drag it into the terminal, or paste with Ctrl+V (Alt+V on Windows).

Give it one small, checkable change

Pick something you could do yourself in 10 minutes and can test:

the signup form accepts an empty email. reject it with a message under the field, and add a test for it

Say what is wrong, what right looks like, and how to check it. That last part matters most: a test it can run is how it knows it is done, instead of guessing.

Before it changes a file, Claude Code may show you the change and ask. Whether it asks depends on the permission mode, shown under the prompt. Press Shift+Tab to cycle through them; Manual asks before every edit and command, which is the right way to learn what it does. Permissions covers the rest.

Read the change, then run the tests

Read every change it shows you, the way you would read a colleague's pull request. You are the reviewer. When it is done, ask:

run the tests and show me what changed

If a test fails, it reads the failure and tries again. If it is going the wrong way, press Esc to stop it at once, or type a correction and press Enter while it works: it reads your message before its next step.

Commit what you read

Git works through plain requests:

commit this with a message that says why

It writes a message from the change and commits. Push and merge only when you have reviewed the result; asking it to create a pr makes a pull request through the GitHub command-line tool, if you have it set up.

When it goes wrong

Each message you send marks a checkpoint, and Claude Code keeps a copy of every file its edit tools change after it. Press Esc twice with the prompt empty, or type /rewind, pick one of your earlier messages, and restore the code, the conversation, or both.

That safety net has holes. It tracks only changes made by its edit tools, so a file deleted or moved by a shell command (rm, mv) is not restored. A command that changed a database, called an API or pushed to a server cannot be rewound at all. That is why the permission mode matters more than the undo button, and why committing working states to Git is still worth doing.

Finish the session cleanly

When the task is done, type /clear before starting the next unrelated one. It starts a fresh conversation, so old details stop crowding the new task. Your files and commits stay as they are. /exit or Ctrl+D twice leaves Claude Code; claude --continue brings back the last conversation in this folder.

Next, read how it works, then the best practices that make longer tasks go right.