Why Your First Hour With Claude Code Decides Everything

Part 2: A clean install, five prompts, and one keystroke separate the developers who fly from the ones who click "approve" forever

Most 'Claude Code doesn't work for me' stories are really first-hour stories. You picked the wrong installer, skipped the trust dialog, or asked overview questions that burned half the context window. None of that is Claude Code's fault, and none of it is hard to fix. This article is the unrushed version of the first hour.

Summary: In this article: Most complaints about Claude Code trace back to a rushed first hour: the wrong installer, a missed trust dialog, prompts that burn the context window on overview questions. This is the unrushed version. You will install cleanly, run a first session, learn the five prompts that work on any codebase, memorize five commands, and master the one keystroke that runs the entire permission system. The theme underneath all of it is a single rule: verify before you trust.

Part 2 of "Claude Code, Day-to-Day," a 19-part guide to mastering Claude Code for working engineers.

If you are new to Claude Code this is the article to start with. The first article in this series is for everybody; this is for the new Claude Code user. If you know someone who wants to try Claude Code, this is the article for them. Have them read this one and then the first one. It might be a good review for the old Claude Code dogs too.

Claude Code Part 2 Companion Video:

A surprising number of "Claude Code isn't working for me" stories are really first-hour stories: wrong installer, skipped trust dialog, context window burned on overview prompts. None of that is hard to fix. This article is the unrushed version of the first hour.

None of this is hard. It is just not obvious, and most introductions skip it to get to the impressive demos faster. The setup steps do not look like learning; they look like chores. But they are the difference between a tool that feels unreliable and one that feels like a superpower.

There is one idea threaded through the whole hour, so name it now: verify before you trust. You will see it come up again at the install step, the trust dialog, the first diff, and the permission system. It is the same instinct every time.

Install the modern way, then prove it worked

Anthropic's recommended path is the native installer. Not npm. There is a reason.

On macOS, Linux, and WSL:

curl -fsSL https://claude.ai/install.sh | bash

On Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

The native installer drops a single signed binary at ~/.local/bin/claude (or %USERPROFILE%\.local\bin\claude.exe on Windows). No Node.js dependency. No shell-wrapper indirection. Most important, it auto-updates in the background. Open Claude Code tomorrow and you are silently on the latest release. That alone is worth choosing the native path over every alternative.

The other install routes all work. They are worth knowing mostly so you understand what you trade away. Homebrew (brew install --cask claude-code) and WinGet give a clean install and uninstall, but no auto-update: you run the upgrade by hand. The apt, dnf, and apk repositories use signed Anthropic packages with documented GPG fingerprints, the right answer for fleet deployments. And npm (npm install -g @anthropic-ai/claude-code) still works; it pulls the same native binary. Two warnings on the npm path: never run sudo npm install -g, because it creates permission errors that are annoying to clean up, and never run npm update -g, because update respects the original semver range and can strand you on an old version. Use npm install -g @anthropic-ai/claude-code@latest instead.

If you used Claude Code in the past, check what you actually have on disk before installing again.

which -a claude

More than one line of output means you have conflicting installs. The native binary at ~/.local/bin/claude is the keeper. Uninstall the rest.

A few requirements bite people. You need macOS 13.0 or later; the native binary uses load commands older macOS cannot handle. You need 4 GB of RAM, which matters on small cloud VPS instances: if the install prints Killed, the OOM killer ate it, so add swap or size up. On Windows native, the Bash tool relies on Git for Windows; without it, Claude Code falls back to a PowerShell tool.

Now the verification step that the rule demands. Do not assume the install worked. Prove it.

claude --version
claude doctor

claude --version confirms the binary is on your PATH. claude doctor runs the real check: auth status, terminal compatibility, plugin marketplace connectivity, the works. Run it once after install. Run it again any time something feels off.

You do not have to live in the terminal. The same engine and configuration power the VS Code extension and JetBrains plugin. They share your ~/.claude/ config, your skills, your CLAUDE.md files. The CLI is the foundation; the editor integrations are on top of it.

Read the trust dialog before you accept it

The very first time you run claude in a directory, two things happen, and both deserve your attention.

First, authentication. Claude Code requires a Pro, Max, Team, Enterprise, or Console API plan. If you only have a free Claude.ai account, you will be asked to upgrade. The billing is per-token on Console or per-seat on Max/Team/Enterprise.

Second, the project-trust dialog. Claude Code asks whether to trust this directory. This is not a formality to click past. Trust gates the auto-installation of marketplace plugins and the execution of project-defined hooks. Accepting trust means files like .claude/settings.json and .mcp.json take effect on your machine.

So apply the rule. Accept trust for repositories you own and understand. Do not accept trust for an arbitrary directory you cloned five minutes ago and have not read. That is exactly how a malicious project's .claude/settings.json would land hooks that run on your machine. Verify before you trust, literally, at the dialog box. Trust acceptance is saved per directory, so you answer once per project.

One footgun: if you start Claude Code in your home directory, trust acceptance is saved for your entire home directory. That is almost certainly not what you want. Always cd into the project root before running claude.

Your first session, and how not to lose it

There are three ways to invoke Claude Code:

# Interactive, what you'll do 95% of the time
claude

# One-shot interactive, in a directory
claude "explain this codebase to me"

# Headless, for scripts and CI
claude -p "run the tests and summarize failures" --print

Interactive is the default: you type, Claude responds, you keep going. The one-shot form opens an interactive session pre-loaded with your prompt. The headless form, with -p or --print, runs a single prompt and exits with no conversation, which is the form you wrap in shell scripts, GitHub Actions, or pre-commit hooks.

When you step away mid-task, your session saves automatically to disk under ~/.claude/projects/. To pick it up again, claude --continue (or claude -c) resumes the most recent session in the current directory, and claude --resume (or claude -r) opens a picker of past sessions. --continue is the daily driver: same project, keep going.

Build one small habit here. Once a project has more than a few sessions, the picker fills with auto-generated titles that all sound alike. Name your sessions instead: run /rename mid-session, or pass --name at launch with claude -n "auth-migration". Future you, scrolling the picker on Monday for Thursday's work, will thank present you for the thirty seconds it cost.

Your first ten prompts: bounded, not boundless

The hardest part of starting on a codebase you do not know is asking the right things. The wrong prompt either burns the context window on irrelevant detail or gives you a summary too vague to act on. Both feel like Claude Code is failing. Neither is Claude Code's fault.

Here are five prompts that earn their place on day one.

1. Overview, but bounded. Ask for a one-page overview: what the codebase does, the main entry points, the major directories, the test command. Then add the load-bearing instruction: don't read every file; use directory listings and the README. Without that line, Claude happily reads fifty files to be "thorough." With it, you get a useful summary that cost 5,000 tokens instead of 50,000.

2. Find the files that handle X. Ask Claude to find the files that handle, say, session timeout, list them with one-line descriptions, and not read them yet. This narrows the search cheaply. You read the ones you actually need on the next prompt.

3. Explain X, then point at the key files. Ask for a high-level explanation of how authentication works, then ask Claude to point you at the two or three files to read deeply. Explanation plus pointers beats either one alone: the explanation gives you the mental model, the pointers give you the next move.

4. What conventions does this project use? Ask Claude to look at three or four recent commits and a couple of source files in different directories, then describe the conventions for naming, error handling, test structure, and async patterns. Add the guardrail: don't generalize beyond what you can actually see in the files. That line keeps Claude honest instead of inventing plausible conventions.

5. Make a small, isolated change. Ask Claude to add a logging statement when a session expires: find the spot, make the change, show the diff, touch nothing else. Your first change should be small, reversible, and unambiguous. This is the prompt that teaches you what edits feel like, and if anything surprises you, it surprises you now, while one keystroke reverts it.

Five more are worth running to stretch different muscles. Ask Claude to run the test suite and summarize any failures. Ask it to find all the places a specific function is called. Ask it to explain a single confusing file line by line. Ask it to generate a shell command you would have to look up. Ask it to check whether a dependency is out of date. None of these are ambitious. All of them teach you something about how the tool moves.

Five commands to memorize before lunch

Most slash commands you learn over time. Five you should know by the end of your first session.

/help lists every slash command in the current session, including ones added by plugins and skills. Do not memorize commands; memorize /help.

/clear starts a fresh session in the same directory. The context window resets, your project memory and skills reload. Run it when you finish one task and start a different one. Do not let a single conversation grow forever; a crowded context makes the agent worse.

/context shows what is in the window right now, broken down by category with token counts. This is your diagnostic when something feels slow or Claude seems to be ignoring earlier instructions. It is verification, applied to the agent's own memory.

/memory lists every project memory file and rule file actually loaded for this session, with toggles for auto memory. Where /context shows what is in the window, /memory shows which of your config files made it in. The two together answer almost any "why is Claude doing this?" question.

/rewind restores files to an earlier checkpoint. Claude Code snapshots your files before every edit, so you can always roll back; the shortcut is pressing Esc twice. The first time something goes sideways and you /rewind to recover instantly is the moment Claude Code stops feeling like an experiment and starts feeling like a tool.

The Shift+Tab habit: telling Claude how much to trust it with

The single most important keystroke to learn in week one is Shift+Tab. It cycles through permission modes, and a permission mode is how you tell Claude Code, in effect, "I trust you with this much autonomy right now." This is the verify-before-you-trust rule turned into a control you can press.

There are four modes in the cycle. default asks before every tool call that could modify files, run commands, or make network requests. auto-approve skips those confirmations for read-only operations. plan first blocks all writes and commands until you explicitly approve a plan. bypassPermissions, available in headless mode only, runs everything without asking.

Press Shift+Tab and the status bar at the bottom of your prompt shows the current mode. Press again to advance. The muscle to build now is small but compounding: check the status bar before you send a non-trivial prompt. Glance, decide, send.

Most of week one will live in default, and that is fine. The goal is not to live in auto from day one. The goal is to know the keystroke and the four modes, so that on day three, when you are about to ask Claude to read forty files and explain the architecture, you have the instinct to press Shift+Tab until the status bar says plan first. People who never learn that instinct spend their whole Claude Code career one approve-click at a time, wondering why everyone else moves faster.

That instinct connects back to the central rule. Whatever mode you choose, the loop stays the same: you send a bounded prompt, Claude gathers context and proposes an action, and you verify the diff before it lands. Approve when it is right. Press Esc twice and /rewind when it is not.

Do this today

Your first hour, condensed into six concrete moves:

Install with the native installer. Skip npm unless you have a specific reason. Run claude doctor afterward and read its output.

Log in. If you only have a free Claude.ai plan, upgrade, because Claude Code is not included free.

Accept project trust for the repo you actually own, not your home directory, and read the dialog before you click.

Run the five overview prompts on a project you know well. Watch how Claude moves, and notice what lands in context.

Run /context and /memory and compare what loaded against what you expected. Surprises here are almost always fixable.

Press Shift+Tab until you have seen all four mode names in the status bar, then return to default.

That is the hour. If you skipped the install advice and you are on an older npm-installed version, take fifteen minutes now and reinstall with the native path. The auto-update alone is worth the switch.

The habit that compounds

Almost everything that goes wrong in someone's first week with Claude Code is a verification step that got skipped. An unverified install. An unread trust dialog. An approved diff nobody actually looked at. A context window nobody checked with /context.

So make the rule your default posture, not a chore. Verify before you trust is not about distrust. It is about staying in control of a fast-moving tool. Claude Code moves fast because you let it. You keep it useful because you stay in the loop.

Install it cleanly. Read the dialog. Watch the diff. Glance at the status bar. Do all of that, and the first hour compounds into a first week that actually gets things done.

This is Part 2 of "Claude Code, Day-to-Day," a 19-part guide to mastering Claude Code for working engineers.

About the Author — Claude Certified Architect

Rick Hightower is a former Senior Distinguished Engineer at a Fortune 100 company, focusing on delivering ML / AI insights to front-line applications, and a practitioner building multi-agent production systems. Rick is a Claude Certified Architect. Follow him on Medium for more hands-on agent engineering content. You can also book him to speak and train your team: Check out Rick Hightower's SpeakerHub.

Rick created Skilz, the universal agent skill installer that supports 30+ coding agents, including Claude Code, Gemini, Copilot, and Cursor, and co-founded the world's largest agentic skill marketplace. Connect with Rick Hightower on LinkedIn or Medium. Check out SpillWave, your source for AI expertise.

Anthropic Harness Engineering: Author Rick Hightower, AI systems practitioner and Claude Certified Architect, brings hands-on production experience building multi-agent systems at Fortune 100 scale.

Rick has been actively developing generative AI systems, agents, and agentic workflows since the release of ChatGPT.

Rick also wrote a Claude Certified Architect (CCA) series of articles that have a lot of useful information on writing agentic AI systems. Many ideas captured in the CCA and the exam prep Rick wrote echo what you see in this article. If you want to improve your ability to create well-behaved AI agents, studying for the CCA Exam is a good place to start.

CCA Exam Prep on Agentic Development

Claude Certified Architect: The Complete Guide to Passing the CCA Foundations Exam

CCA Exam Prep: Mastering the Code Generation with Claude Code Scenario

CCA Exam Prep: Mastering the Multi-Agent Research System Scenario

CCA Exam Prep: Structured Data Extraction

CCA: Master the Developer Productivity Scenario

Claude Certified Architect: Master the CI/CD Scenario

CCA Exam Prep: Mastering the Customer Support Resolution Agent Scenario

Get the complete reading list for CCA-F exam prep articles from this Claude Certified Architect Exam Prep list.

Rick also wrote a series on harness engineering and how to improve agentic systems.

Harness Engineering Articles

The $9 Disaster: What Anthropic's Harness Design Paper Teaches Us About Building Autonomous AI

Harness Engineering vs Context Engineering: The Model is the CPU, the Harness is the OS

LangChain Deep Agents: Harness and Context Engineering: Memory, Skills, and Security

Beyond the AI Coding Hangover: How Harness Engineering Prevents the Next Outage

LangChain's Harness Engineering: From Top 30 to Top 5 on Terminal Bench 2.0

Anthropic's Harness Engineering: Two Agents, One Feature List, Zero Context Overflow

OpenAI's Harness Engineering Experiment: Zero Manually-Written Code