Sign in and run your first prompt

The REPL is waiting and your instinct is to throw the ticket at it immediately. Hold that thought for ninety seconds. There are two small steps between you and useful work, and the second one — what you choose to say first — sets the tone for how much you’ll trust the tool by lunchtime.

Authenticating

On a fresh install the first thing Claude Code does is get you signed in. It opens a browser, you authorize the session, and you land back in the terminal already logged in — there’s nothing to copy-paste if the browser flow completes. If you’re ever on a headless box where no browser can open, or you want to switch accounts later, the in-session commands handle it:

/login     # start the sign-in flow (or switch accounts)
/logout    # drop the current credentials

That’s the entire ceremony — with one prerequisite worth knowing before you hit it: Claude Code needs a paid plan (Pro, Max, Team, Enterprise, or a Console/API account). The free Claude.ai tier doesn’t include it, which is the one way this step quietly stalls for a brand-new user. The current list of supported account types and provider setups lives in the authentication docs — that’s the page to check if your sign-in doesn’t behave. What matters for the chapter is that, once you’re through it, you’re at a live prompt with the agent able to act.

Make your first prompt a question, not a command

Here’s the move that separates people who trust the tool from people who get burned in the first ten minutes: don’t open by asking it to change anything. Open by asking it to explain. You’ve just landed in an unfamiliar repo; so has the agent. A read-only question costs you almost nothing and shows you exactly how it gathers context before you ever let it write:

> what does this service do, and where are the HTTP routes defined?

  ⎿ Read package.json, src/server.js, src/routes/                    (3 files)

  It's a small Express API for processing payments. The entry point is
  src/server.js, which mounts route modules from src/routes/ — there's
  payments.js, refunds.js, and a health stub in index.js. Tests live in
  test/ and run with `npm test` (node:test). No database; state is in-memory.

Watch what that single turn bought you. The agent went and read files — you can see which ones — and came back with a map of the project: the entry point, where routes live, how tests run. You’ve learned the lay of the land for your ticket, and you’ve learned something more useful: how this agent behaves when it needs context. It reads first, then answers. That read-then-act rhythm is the thing you’re really evaluating, and you got to evaluate it on a question where a wrong answer couldn’t hurt you.

Lead with a write instead — “add a health endpoint” as your very first words — and you’d be trusting a tool you’ve watched do nothing yet, on a codebase it hasn’t shown you it understands. Cost yourself one read-only question first and that trust is earned instead of assumed.

You now know where the routes live and how the tests run — which is exactly what you need to hand it the actual ticket. Time to make the first real change.