An ultimate Claude Code guide for developers and beyond

What Claude Code is, and where it runs

Claude Code is not only a terminal chatbot. Anthropic offers it in the terminal, VS Code, JetBrains IDEs, a desktop app, and the web. Each surface uses the same basic agentic model: Claude can inspect code and context, form an approach, make changes, and run tools. The right surface depends on the job. A terminal session is a good fit for a local checkout and shell tools; the desktop app makes visual diff review and parallel sessions easier; web work is useful for a repository you do not have locally.

That reach is useful, but it changes the review question. A code-completion suggestion is small enough to assess line by line. Claude Code may touch several files, invoke a test suite, use Git, or reach an approved connector. Ask what it can access and what it is allowed to do before asking it to act.

Install it and start with a question, not a large change

Anthropic’s Quickstart recommends the native installer, not a Node-based installer. On macOS, Linux, or WSL:

curl -fsSL https://claude.ai/install.sh | bash
cd /path/to/your/project
claude

On first use, Claude Code asks you to authenticate. You can use a Claude Pro, Max, Team, or Enterprise account, a Console account, or a supported provider. claude --version confirms the installation. Native installs update automatically; Homebrew and WinGet installations need their own upgrade command, so choose the distribution method deliberately.

For the first session, ask read-only questions first: “What does this project do?”, “Where is the main entry point?”, or “Which test covers password reset?” This gives you a quick check that Claude has found the active path before it writes anything. Then give it one concrete outcome: identify the failing behavior, the area it may change, what must stay unchanged, and the test you expect.

Trace why the Linux documentation build cannot resolve a link to setup.md when the tracked file is Setup.md. Identify the active build path and existing tests. Propose the smallest casing fix and its test. Do not edit, commit, push, or deploy yet.

That request is far more useful than “fix the docs.” It makes the hypothesis, the boundary, and the expected evidence reviewable.

Give Claude Code durable context with CLAUDE.md

CLAUDE.md is a project instruction file Claude Code reads at session start. Use it for information a careful new contributor needs repeatedly:

• commands for local setup, focused tests, linting, and formatting;
• architecture boundaries and packages that should not be changed casually;
• existing patterns to follow and common traps to avoid;
• a short pull-request or security review checklist.

Keep it factual and close to the code. “Run pnpm docs:build after modifying Markdown links” is useful. “Make the system scalable” does not tell Claude what to do. Split detailed instructions into the directories where they matter instead of turning the root file into a handbook.

Memory is helpful context, not enforcement. A CLAUDE.md instruction saying “never deploy” does not stop deployment if permissions and credentials allow it. Use the permission system, scoped credentials, protected branches, and deployment controls for that boundary.

Use /context to inspect what is taking up the current context window. During long investigations, /compact summarizes the conversation; review the retained goal and evidence afterward. Starting a fresh session for an unrelated task avoids carrying old assumptions into it. These tools manage context, not the correctness of a conclusion.

Choose permissions before you choose speed

Claude Code’s permission modes control when it asks about actions. On eligible interactive subscription sessions, Auto can be the starting mode; other accounts may start in Manual, and an organization can set different rules. Check the current mode with the session controls before assuming Claude will pause.

For an unfamiliar repository or an investigation, start in a mode that lets you review the plan and proposed changes. For a well-understood local edit, a narrower permission set may be reasonable. For anything that can alter production data, send a message, spend money, or publish a release, keep the external credential out of the exploratory session unless an accountable owner has separately authorized that action.

Permission prompts are not the only safeguard. Use Deny rules for things Claude must not call, GitHub branch protection for merges, limited tokens for tools, and CI checks for code quality. A prompt is a request; these are controls.

A reliable loop: explore, plan, change, prove, review

For a medium or risky change, work in a loop that makes bad assumptions visible:

1. Explore. Ask Claude to name the active files, call chain, tests, and uncertainty. Do not edit yet.
2. Plan. Review the smallest proposed change. Check that it does not quietly include a migration, dependency upgrade, or unrelated cleanup.
3. Change. Let Claude edit only after the approach is clear. Inspect the diff as you would a teammate’s: look for changed defaults, deleted error paths, and scope creep.
4. Prove. Run the reported failure, the nearest edge case, and the relevant broader check. Read failures instead of asking Claude to make every test green blindly.
5. Review and decide. A maintainer decides whether to commit, merge, deploy, and monitor. Passing tests are evidence, not release authority.

For the case-mismatch example, useful cases are: the documented Linux build resolves the corrected path; a truly missing page still fails clearly; a link whose capitalization already matches remains unchanged. That last case catches an overbroad link rewrite.

Use tests and visual checks as feedback, not a finish line

For a new behavior, ask Claude Code to locate the closest existing test and write or adjust a focused case before implementation. Run it, then review whether it fails for the reason you expect. After the edit, rerun that case and the wider check that protects the affected boundary. This is a practical test-driven loop, not a promise that a green suite covers every production condition.

For a front-end change, inspect the rendered result at the relevant screen sizes as well as the diff. A screenshot or browser check can catch clipping, hierarchy, and interaction regressions that a unit test does not see. Name the exact screen and state to inspect; “make it look right” is not an acceptance criterion.

Use extensions for a specific job

Claude Code has several ways to extend a session. They solve different problems.

For unattended work, distinguish a local session, a desktop task, a cloud routine, and a CI workflow. A cloud routine can continue with the computer off, but it is autonomous: its repository selection, branch rule, environment variables, network, and connector set are the real controls. A GitHub Action runs in your CI environment, so its event, GitHub permissions, secrets, timeout, and concurrency settings matter. Do not move a broad interactive prompt into automation without rethinking those boundaries.

Pricing, limits, and the limits of an agentic tool

Claude Code access and included usage depend on the account path. The current Claude pricing page is the source for subscription terms and plan availability; Console and cloud-provider use have their own billing. Usage is not unlimited. A long session, large repository, repeated tool work, or autonomous routine consumes more than a short question, so check the current allowance instead of extrapolating from a demo.

More importantly, Claude Code does not know whether a business decision is sound. It can find code, propose a patch, run an available test, and draft a release note. It cannot decide that a product incident is resolved, that a customer’s account was repaired, or that a legal, financial, or support response is authorized. Keep those decisions with the people and systems that own them.

Use eesel CLI to turn a documentation finding into support guidance

Occasionally a verified code change changes what support should say. Treat that as a separate handoff. A reviewer first approves the engineering evidence: the issue, the narrow diff, the test result, and the release decision. A support owner then writes the customer-facing note and tests it in the support environment. Do not upload a repository file or paste a Claude Code conversation into a live support agent and assume it has become approved knowledge.

eesel’s helpdesk teammate is designed for that separate support job. Its CLI lets an owner or coding agent inspect the same teammate and workspace shown in the dashboard. The owner should select a non-production teammate explicitly, keep consequential connected actions Disabled, and approve a paid response test using only a fictional, reviewed note. Login authenticates, while status, instructions, integrations, activity, approvals, and billing let the owner inspect the exact target.

For example, a documentation build works on a case-insensitive macOS volume but fails on a case-sensitive Linux filesystem because Setup.md is linked as setup.md. Filesystem behavior matters; the operating-system name alone is not the rule. After the reviewer verifies the casing fix and release decision, an approved support note can say: “For a documentation-build failure that names a case-mismatched file, ask for the exact path and build output, then direct the user to documentation support. Do not claim a customer file was inspected or fixed.” Test that same full note in separate fresh conversations against the named case-mismatch, a generic broken-link report, and a request to rename a file in the customer’s repository. Expected drafts must not invent file access, apply the casing explanation to the unrelated report, or promise a repository change. These are proposed tests, not reported results.

With Node.js 18.17 or newer, eesel CLI returns JSON and operates the same teammate as the dashboard. Login authenticates, so it is not a read-only check. The owner selects the non-production target rather than leaving a saved default to decide it:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
SUPPORT_GUIDANCE_AGENT="REPLACE_WITH_OWNER_APPROVED_NONPRODUCTION_AGENT"
npx @eesel/cli status --agent "$SUPPORT_GUIDANCE_AGENT"
npx @eesel/cli instructions --agent "$SUPPORT_GUIDANCE_AGENT"
npx @eesel/cli integrations --agent "$SUPPORT_GUIDANCE_AGENT"
npx @eesel/cli billing --agent "$SUPPORT_GUIDANCE_AGENT"

Stop if whoami identifies the wrong workspace, then replace the placeholder with the actual approved teammate before running scoped commands. The CLI returns JSON by default. For unattended scripts, EESEL_API_URL and EESEL_API_TOKEN override stored login credentials, so check the environment too.

Setup inspection is free; chat is billed. Before an owner-approved response test, set connected consequential actions to Disabled in the teammate’s Actions settings. A prompt saying “do not send” is not that control. Use new --name for a fresh conversation, then chat with the full approved note and one case question, scoped to the same agent. Inspect activity and approvals; chat activity is expected, while an unexpected held approval or external action is not. Supplying the note tests the response under those conditions; it does not show the teammate retrieved or learned a persistent source.

The dashboard is the same workspace an explicitly targeted eesel CLI command can inspect; it does not show the fictional test outcome.

Use eesel CLI for the support-safe handoff after Claude Code work

Claude Code earns its place when it makes a codebase easier to understand and a change easier to test and review. eesel CLI gives a support owner a clear way to inspect and test the same helpdesk teammate as the dashboard after that owner has approved the customer-facing guidance. Try eesel to evaluate that controlled handoff in your own workspace.