Anthropic · Coding assistant

Claude Code

Understanding a failure often means following it across several files: the code that sends a request, the code that catches the error and the test that claims to cover it. Claude Code can help trace that route. Anthropic’s coding assistant reads project files, edits code and runs development commands from a terminal, so you can ask a question and then work on the answer in the same session. It is a practical option when Claude access already fits your team and you want help moving between an explanation of the code and a change you can test.

Ready guideDocumentation checked Sep 30, 2026

In this guide 7 sections

01Fit

Is it for you?

When it helps

Tracing a bug across the files involved, rather than reading each file in isolation
Adding or improving a test once you know which behavior it needs to check

When to choose something else

Source code that your organization does not allow the selected model service to process
Treating an approved tool call or one passing test as enough to release a change. The project’s wider checks and review still apply

02Requirements

Before you start

A project you can inspect, a terminal and an internet connection
A supported operating system, including macOS 13+, supported Linux distributions or Windows 10 1809+. Check the setup guide for hardware and platform details
Claude Code access through an eligible Claude plan, a Console account or a supported provider

Cost and access

Installing the program does not by itself provide model access. Subscription and API-backed sessions have different allowances and billing, so check which account Claude Code is using. The cost guide explains the arrangements and how to keep track of usage.

Check current access and pricing

03Setup

Set it up

01
Use the installer for your terminal
The command below is the official installer for macOS, Linux and Windows Subsystem for Linux, or WSL. Native Windows users should use the PowerShell or CMD instructions in the quickstart. As with any installer that downloads a script, review it before running it.
Terminal command
```
curl -fsSL https://claude.ai/install.sh | bash
```
Official instructions
02
Check the installation
Open a new terminal and run claude --version. If it prints a version number, your shell can find the program. Keep that number with any notes about your setup, especially if you later need to investigate a change after an update.
Terminal command
```
claude --version
```
Official instructions
03
Sign in from your project
Run claude in the project directory and complete sign-in. Before requesting an edit, open /permissions to see the active mode. Depending on the version and settings, some modes can approve actions automatically; the session’s actual configuration determines which actions will pause for you.
Terminal command
```
claude
```
Official instructions

04Using Claude Code

Why did a failed request look successful?

The synthetic client in client.mjs treats every HTTP response as a ticket. When the service returns 503, its error body travels back as if it were successful data. Follow that value through the code with Claude Code, then change the client so its caller gets a useful rejection instead.

Included example files

A small support-service project

Synthetic code, logs, a deliberately stale runbook, and six support tickets. The JavaScript uses Node.js 22+ with no packages or network calls. Product accounts and model access are separate.

client.mjs
client.test.mjs
checks/client-contract.test.mjs

Download starter ZIP

Unpack the starter and run the two baseline tests. Then run the client contract below. Its expected rejection is missing in the original implementation. Open the stubbed response: it sets ok to false, status to 503, and counts body reads. This is an isolated contract test, not a real request to a service.
Open Claude Code in the starter folder. Use its permissions controls to inspect the active mode; Plan mode can explore without editing source, but it is not a substitute for an operating-system isolation boundary. Send the request and compare its explanation with the actual return statement.
Approve the focused change only after the proposed behavior is clear. The status check belongs before response.json(), so an error page is not treated as ticket data. Ask for a regression test matching the project’s Node test style, then run the baseline and contract checks yourself. Inspect every changed file.

Baseline: successful calls

node --test client.test.mjs retry.test.mjs

HTTP error contract

node --test checks/client-contract.test.mjs

What to ask

Trace readTicket in client.mjs using the 503 response in checks/client-contract.test.mjs. Explain what its caller receives today and why the baseline happy-path test misses the problem. Propose a minimal change that rejects non-OK responses with an error containing the status, before reading the JSON body. Keep the successful return value and transport errors unchanged. Wait for approval before editing, and do not weaken the supplied contract test.

The artifact you are working toward

A client that separates HTTP failure from ticket data

Keep client.mjs and the regression test together. This minimal implementation is a comparison target, not an observed Claude response. It leaves transport exceptions untouched.

Illustrative result to compare

export async function readTicket(fetchTicket) {
  const response = await fetchTicket();
  if (!response.ok) throw new Error(`HTTP ${response.status}`);
  return response.json();
}

What the example should show

The 503 test now rejects with HTTP 503, and its JSON reader is never called.
The original 200 response still returns the ticket object.
Add a rejected transport case and check that the same exception reaches the caller; swallowing it would hide a different failure.

The test passes after changing the expected result

That moves the goalposts. Restore the supplied contract and ask why the implementation does not meet it.

The proposed client retries the 503

Retry policy is a separate decision about deadlines and repeatable operations. This walkthrough only fixes how an unsuccessful HTTP response is reported.

What you can take from this example

You can follow a failed response from the stub to the caller and explain why the new branch belongs before body parsing. Adapt the error type and status policy to your real application rather than copying the synthetic contract unquestioned.

The included baseline tests and evaluation script were checked locally. The deliberately failing contract tests demonstrate the defects in the starter. No AI product was installed or run for these examples; model responses and reviews will vary.

05Next steps

Go deeper

Keep the instructions you find yourself repeating

After a few similar jobs, you may notice that the same context is missing each time: where the client tests live, how to run them or what the project expects callers to receive. Those details are useful candidates for reusable instructions. The operational-skills guide explains how to turn a recurring task into something another person can understand and the assistant can repeat.

Read the guidance

Taking a code investigation into incident work

A source-level explanation can identify a plausible failure, but an incident also raises questions about what happened in the running service and whether it has recovered. The evaluation guide shows how to compare an assistant’s account with separate checks you control. It includes the cases where the available information leaves recovery unresolved.

Read the guidance

06Alternatives

Other options to consider

Codex: Try the same investigation with Codex if OpenAI access and tooling already suit the project
Pi: Consider Pi when you need a different provider or want to customize the tools and instructions the assistant uses

07Evidence and scope

Sources and review

Product behavior is based on the linked official documentation. This walkthrough uses an authored synthetic starter project. Its baseline tests and local checker were checked; no installation, model response or product performance was independently tested for this guide.

Documentation checked Sep 30, 2026

Back to all tool guides