Before learning how to use Claude Code, know what it is: a terminal-based coding agent that can inspect projects, propose plans, edit files, and run approved commands; Claude.ai is a conversational application, so the operating risks are different.

Anthropic’s setup guidance covers supported environments, authentication, and internet access, and features can change, so check the official page when you start.［1］ For the general AI safety workflow, see the beginner’s process for checking AI output; this guide explains how to use Claude Code safely with read-only exploration, explicit permission, diff review, and human control of tests and release decisions.

Key Takeaways

Try Claude Code first in a disposable or separately backed-up repository.

Begin with read-only exploration and a written plan.

Keep permission prompts enabled and inspect every diff and command.

Run tests yourself and decide when a change is ready to commit or share.

How to use Claude Code safely in a project

Claude.ai is suited to conversation, document work, and drafting. Claude Code runs from a terminal and can work with the local project context. It can also be invoked non-interactively with CLI flags and can integrate with tools, which makes its permissions and environment especially important.［2］

Do not infer that an account, region, model, or feature available in Claude.ai is automatically available in Claude Code. Check the current official access and authentication requirements for the surface you intend to use.

Step 1: Prepare a safe test project

Do not start by pointing an agent at production, a home directory, a repository containing secrets, or a worktree with uncommitted user changes. Create a small fixture with one source file, one test, and a clear expected change. Keep it outside the Blog repository for a first run.

Before launching the tool:

Confirm the current directory with pwd.
Inspect git status --short.
Check that .env, credentials, private keys, customer exports, and build secrets are absent or explicitly denied.
Record the expected files and tests.
Decide what the agent is not allowed to do, such as network calls, dependency installation, commits, pushes, or deployment.

Never paste API keys, passwords, tokens, private certificates, customer data, or an entire confidential codebase merely because the agent can read files. Anthropic’s current FAQ describes local project handling and permission controls, but the exact account and organization policy still matters.［3］

Step 2: Install and authenticate from the official source

Follow Anthropic’s current getting-started instructions. The documented installation may use a package manager or another supported installer; do not copy an old command from a blog post without checking the official page. Avoid sudo npm install -g and keep credentials in the supported credential store.

After installation, use the provider’s diagnostic command if the guide recommends it. Confirm which account and provider the session will use. Do not put API keys directly into a prompt, shell history, Markdown file, or screenshot.

Step 3: Start with read-only exploration

Open the fixture directory and ask a question that cannot change it:

Explain this small project. Identify the entry point, the validation rule, the existing test, and any assumptions. Do not edit files, run network commands, install dependencies, or create commits. Tell me what you would inspect next.

Read the answer and compare it with the files yourself. An agent can misunderstand an entry point or miss a generated file. This first pass also tests whether the working directory and tool permissions are what you expected.

This official English-UI example from Anthropic’s VS Code guide shows a read-only question about selected code. It does not prove that the session is in plan mode or that the Blog repository was inspected.

Step 4: Request one bounded change

Once you understand the project, ask for a small change with acceptance criteria:

Add validation for an empty username in src/validate.js. Keep the existing error format. Update or add the smallest relevant test. Do not change dependencies, public APIs, unrelated files, or Git history. Before editing, show the plan and the files you intend to touch.

A good task has a defined target, a narrow file set, a test condition, and explicit exclusions. Do not combine a refactor, dependency upgrade, formatting sweep, and feature request in one first task.

Step 5: Review permissions and the diff

Keep the default permission prompts while learning. Plan mode is useful for discussing an approach before edits; it does not make an unsafe command safe. Review each proposed file edit and command:

Is the path inside the intended fixture?
Does the command read, write, delete, install, or contact a network service?
Could the command expand a glob beyond the target?
Does the diff preserve the existing API, error handling, and security checks?
Did the agent touch a generated file, lockfile, config, or secret unexpectedly?

Never use --dangerously-skip-permissions as a shortcut. If a permission request is unclear, deny it and ask the agent to explain a safer alternative. MCP tools and external integrations deserve the same review as shell commands; only allow the specific tool and scope required.

This official example shows a proposed docstring diff with explicit Yes/No permission choices. It does not show a test run or approve the change for another repository.

Step 6: Run tests, inspect the tree, and control external actions

Ask the agent to propose a test command, then inspect it before running. Prefer deterministic, local tests first. After the command finishes:

Read the exit status and relevant output.
Run the test yourself when the result affects a release or security decision.
Inspect git diff --check and git diff.
Run git status --short and confirm the file list.
Check for new dependencies, generated artifacts, logs, or secrets.
Exercise a normal case, an edge case, and a failure case.

A green test is evidence for the tested behavior, not proof that the agent understood the full business rule. Ask a human owner to review changes that affect authentication, permissions, payments, data retention, migrations, concurrency, or production paths.

Keep Git and external actions human-controlled

You may ask Claude Code to explain a commit or prepare a patch, but keep commit, push, pull request, deployment, database migration, and message-sending decisions under your normal review process. The agent should not infer permission from a vague request such as “finish this task.”

If the working tree already contains user changes, do not ask the agent to clean, reset, rebase, or discard them. Save a known snapshot, work in an isolated branch or fixture, and inspect the exact diff before any handoff.

What goes wrong most often with Claude Code?

The agent reads the wrong directory

Stop and check pwd, the repository root, and the file list. Do not continue based on a plausible explanation from the wrong project.

The agent proposes a broad refactor

Reject the plan and restate the smallest behavior change, target files, and tests. A broad diff is harder to review and easier to approve accidentally.

A command asks for network or elevated permission

Deny it unless the dependency and destination are explicitly required, trusted, and approved. Never reveal a secret to make the command succeed.

The test passes but the behavior is wrong

Add an acceptance test for the actual invariant, inspect the diff, and compare with the original requirement. Ask for a counterexample rather than another confident explanation.

Claude Code is unavailable

Check supported locations, account authentication, provider configuration, and network requirements separately. A VPN can only test a permitted network-path issue; it cannot grant account, model, billing, or feature eligibility. See how to separate Claude’s regional limits from account and network issues.

Treat a handoff as a new permission boundary

The end of an agent session is not the end of the review. Before handing a patch to another person, write down the fixture or repository path, the exact files changed, the commands run, the tests that passed, and the checks that were not possible. Include any generated files, dependency changes, warnings, and assumptions that could affect a later run.

Keep the approved diff separate from the agent’s conversation. A transcript can explain intent, but the files and command output are the evidence a reviewer can reproduce. If the patch is copied into another worktree, re-check the target branch, status, ignored files, permissions, and secrets instead of assuming the first environment’s boundary followed it.

Stop when the fixture is too close to production

Move back to a disposable project if the task needs production credentials, customer data, deployment access, destructive commands, or a broad network permission. A realistic fixture should demonstrate the behavior you want to test without carrying the consequences you are trying to avoid.

If the agent cannot explain why a command is needed, what it can change, and how to recover from failure, do not approve it. Ask for a smaller read-only inspection or a plan with a narrower file set. The safest default is to preserve the current tree and make the next decision explicit.

For a useful handoff, distinguish facts from recommendations. Record the starting commit or file snapshot, the intended acceptance criteria, and the commands that actually ran; do not replace those with the agent’s summary. If a test was skipped because a dependency, platform, or credential was unavailable, name that limitation so the next reviewer does not mistake an untested path for a passed one.

Before sharing the patch, inspect the smallest relevant diff and then inspect the full status. Confirm that ignored files, temporary logs, local configuration, and generated output are not being carried into the next environment. A reproducible handoff should let another person review the change without granting the agent broader access.

If the change affects authentication, permissions, payments, data retention, migrations, concurrency, or a production path, add an owner review to the handoff. The agent can prepare evidence and a narrow patch, but it should not become the approver of a decision whose consequences it cannot observe.

For ordinary changes, the same rule can be lightweight: name the reviewer, point to the acceptance test, and state whether the next action is review, merge, deployment, or rollback. Explicitly separating those actions prevents “finished” from being mistaken for permission to change an external system.

Record this handoff even when the change looks small. Hidden local configuration or an untested recovery path can turn a safe patch into an unsafe deployment. The next action must be explicit, and no agent summary can replace that decision.

Treat a denied permission as part of the evidence, not as an obstacle to work around. Record the command or tool, its intended purpose, the capability you refused, and the narrower substitute. Do not repeatedly rephrase the same network, write, deletion, or privilege request until a prompt looks harmless. If a read-only command can answer the question, use it; if not, stop and hand the unresolved decision to the person who controls that boundary.

For every approved command that can change state, define recovery before execution. Identify the files, service, database, or remote object it may affect; decide how you will detect partial completion; and make sure the rollback does not depend on the same missing credential or broken path. After execution, verify the target state directly instead of relying only on the agent’s summary or exit code.

Keep denied and approved actions separate in the handoff. A later reviewer should be able to see that a test passed locally while a deployment, migration, network call, or production readback was never authorized. This prevents an incomplete verification boundary from being retold as a complete result.

Summary

Claude Code is most useful when the project boundary and permission boundary are explicit. Start in an isolated fixture, explore read-only, plan a small change, review every permission and diff, run tests, and keep Git and production actions under human control.

Anthropic’s data-retention guidance is a separate account and policy boundary from the local permission prompts described in this workflow.［4］

FAQ

Is Claude Code the same as Claude.ai?

No. They are related products with different surfaces and capabilities. Claude Code operates in a terminal and can interact with a local project.

Can I let Claude Code modify a production repository?

Do not make that the default. Use a safe worktree, least privilege, backups, review, and a normal release process. Production credentials and secrets should not be exposed to a coding agent.

Should I use Claude Code plan mode for every task?

Use it whenever the scope, file set, permission, or risk is not obvious. Even without a formal plan mode, ask for a plan before editing.

Can Claude Code commit or open a pull request?

It may support Git workflows, but technical ability is not authorization. Keep commit, review, push, and deployment approval in your team’s process.

Does a successful test prove the patch is safe?

No. Test results cover the cases you ran. Review permissions, dependencies, secrets, side effects, and untested failure paths separately.

Disclaimer: This article is general information, not legal, financial, employment, or professional advice. Review commands before running them.

Sources:

Anthropic — Set up Claude Code — https://docs.anthropic.com/en/docs/claude-code/getting-started
Anthropic — CLI reference — https://docs.anthropic.com/en/docs/claude-code/cli-usage
Claude Help Center — Claude Code user FAQ — https://support.claude.com/en/articles/14554922-claude-code-user-faq
Anthropic — Data retention practices for covered models — https://support.claude.com/en/articles/15425996-data-retention-practices-for-covered-models

Sources checked 23 August 2026.

Related Articles:

How to Use Claude Code: A Beginner's Guide