How to start Claude Code in terminal: the order matters more than the settings

On this page#

• Before you install anything
• The steps
• A working configuration
• Scope
• Before editing
• Implementation rules
• Validation
• Completion report
• What to skip
• First real task
• FAQ

Before you install anything#

To start Claude Code in a terminal safely, install it from the official Claude Code documentation, open a terminal, change into the repository root, verify the repository state, and run claude. That order matters because Claude Code inherits the directory, files, instructions, and permissions available when the session starts.

Claude Code is an agentic coding tool that can inspect a repository, propose changes, edit files, and run approved commands from a terminal session. Anthropic’s official overview explains the product; the operational detail that deserves more emphasis is that the working directory defines the agent’s initial boundary.

Starting from the wrong directory is not a cosmetic mistake. It can expose unrelated files, hide repository instructions, and make commands run against the wrong project. A carefully tuned model cannot compensate for a badly chosen execution boundary.

Before installation, decide four things:

• Which repository Claude Code may inspect.
• Which commands are safe to run without improvisation.
• Which files contain secrets or generated output.
• Which checks define an acceptable change.

For a real repository, “the command completed” is not validation. The repository’s tests, type checks, lint rules, generated-file policy, and architectural invariants are the validation system.

The right mental model is:

| Weak setup | Operational setup | |---|---| | Start the agent, then explain the project | Enter the correct repository, inspect its state, then start | | Grant broad access to avoid interruptions | Grant only the access required by the current task | | Ask for a feature immediately | Ask for analysis and a plan before edits | | Trust a plausible diff | Require repository-native checks | | Put every preference into global settings | Keep repository rules inside the repository |

Global settings should control personal defaults. Repository-specific facts belong in a repository-level CLAUDE.md, where they can be reviewed and updated with the code.

Photo by Boris K. on Pexels.

The steps#

Use this sequence every time: enter the repository, establish a clean baseline, read the project’s instructions, start Claude Code, constrain the task, and verify the result. Each step prevents a different failure mode, so collapsing them into “open a terminal and type claude” removes the controls that make an agent dependable.

1. Install Claude Code using the official documentation.
   This prevents stale installation commands, unofficial packages, and platform-specific guesses from becoming part of your setup.

2. Open your terminal and change into the repository root.
   This prevents Claude Code from treating a parent directory, home directory, or nested package as the project boundary.

   cd /path/to/your/repository

3. Inspect the current repository state before starting the agent.
   This prevents pre-existing work from being mistaken for agent-created changes.

   git status --short

   If the output is not empty, do not blindly clean it. Determine which changes are yours and tell Claude Code they must be preserved.

4. Read the repository’s local instructions and validation commands.
   This prevents the agent from inventing conventions that the codebase already defines in README.md, CONTRIBUTING.md, package scripts, build files, or CLAUDE.md.

5. Start Claude Code from that same terminal and directory.
   This prevents a mismatch between the repository you inspected and the repository the agent receives.

   claude

6. Begin with a bounded analysis request, not an unrestricted implementation request.
   This prevents premature edits based on an incomplete understanding of the dependency path.

7. Review the diff and run the repository’s own checks before accepting the work.
   This prevents fluent explanations from substituting for evidence.

This is the durable answer to how to start Claude Code in terminal: the launch command is simple, but the pre-launch state makes the session trustworthy. For additional setup patterns, use the agent setup hub.

A working configuration#

Put stable repository instructions in a root-level CLAUDE.md, keep them short enough to remain authoritative, and name exact checks instead of writing vague guidance. The configuration below is intentionally conservative: it tells Claude Code what must remain true, where to look, what not to touch, and how to report completion.

# Repository operating instructions


![Close-up of colorful programming code on a blurred computer monitor. — illustrating how to start claude code in terminal](/blog/how-to-start-claude-code-in-terminal-2.jpg)
*Photo by Al Nahian on [Pexels](https://www.pexels.com/photo/computer-program-on-computer-screen-7325498/).*

## Scope
- Work only inside this repository.
- Preserve all pre-existing uncommitted changes.
- Do not modify unrelated files.

## Before editing
- Read README.md and CONTRIBUTING.md if present.
- Inspect the relevant implementation, tests, and call sites.
- State the proposed file scope before making changes.
- Ask before changing public APIs, schemas, or dependencies.


![A programmer working on code with a laptop and monitor setup in an office. — illustrating how to start claude code in te](/blog/how-to-start-claude-code-in-terminal-3.jpg)
*Photo by Jakub Zerdzicki on [Pexels](https://www.pexels.com/photo/close-up-of-programmer-typing-code-on-laptop-36496927/).*

## Implementation rules
- Prefer the smallest change that satisfies the request.
- Follow existing naming, structure, and error-handling patterns.
- Do not add compatibility layers unless the task requires one.
- Do not rewrite generated files manually.
- Never read, print, copy, or commit secrets.

## Validation
- Use the repository's documented test, lint, type-check, and build commands.
- Run the narrowest relevant check first.
- Run broader checks only when the change can affect broader behavior.
- Do not claim success when a required check did not run.

## Completion report
- Summarize the behavior changed.
- List the files changed.
- Report each validation command and its result.
- Identify remaining risks or checks that still require a human.

Each block has one job:

• Scope protects existing work and limits collateral edits.
• Before editing forces discovery before implementation.
• Implementation rules preserve local architecture and sensitive data.
• Validation makes the repository—not the agent—the judge.
• Completion report separates completed evidence from unresolved risk.

Do not paste undocumented commands into this file merely because another project uses them. Replace the validation language with the exact commands already defined by your repository. The Claude Code overview describes the agent’s capabilities, but your repository must define what correctness means locally.

Teams that want a fuller operating model can use PairFoundry’s Agent Operating Kit. If you are still establishing the basics, start with the free foundations track; the broader pack overview is useful when comparing reusable workflows.

What to skip#

Skip setup steps that create ceremony without strengthening the execution boundary, repository context, or validation evidence. Most Claude Code terminal tutorials overemphasize personalization and underemphasize working-directory discipline. That priority is wrong for production repositories because attractive defaults do not protect invariants.

Do not waste time on:

• A giant global instruction file. Repository rules drift, conflict, and become invisible when buried in personal configuration.
• Dozens of aliases before the first session. An alias cannot rescue a launch from the wrong directory.
• Broad automatic command approval. Fewer prompts are not worth an unclear mutation boundary.
• Copying another repository’s checks. Validation commands are executable project knowledge, not generic preferences.
• An elaborate prompt persona. “Act as a senior engineer” is weaker than naming the files, constraint, acceptance criteria, and forbidden changes.
• Starting from your home directory. This expands context for no useful reason and makes path assumptions harder to audit.
• Requesting a large feature as the first task. Large tasks hide whether navigation, instructions, and verification are configured correctly.
• Treating the VS Code terminal differently. It is still a terminal; the current directory and repository state still control the session.

The official Claude Code documentation should remain the source for installation and supported product behavior. Your local operating rules should cover the gap between “the tool runs” and “the change is acceptable here.”

First real task#

Make the first task a read-only repository orientation that produces a checkable map of one real behavior. Do not begin with a refactor, dependency upgrade, or broad cleanup. The goal is to verify that Claude Code can find the correct code path, recognize project instructions, and identify the relevant validation commands before it edits anything.

Use a prompt like this:

Do not edit files yet.

Trace how [specific behavior] enters the system, which modules transform it,
where its invariants are enforced, and which tests cover it.

Then report:
1. the relevant files and their roles;
2. the execution or data flow;
3. the invariants that must remain true;
4. the narrowest validation commands for a change in this area;
5. any ambiguity that must be resolved before implementation.

Choose a behavior tied to current work: request authentication, configuration loading, a queue transition, a database write, or error propagation. Avoid “explain the whole repository.” A bounded trace reveals whether the agent understands the real dependency path without giving it permission to create a noisy diff.

After reviewing the map, give one small implementation task with explicit acceptance criteria. Require a proposed file scope first, preserve existing uncommitted changes, and compare the final git diff with the pre-session git status.

That is when the Claude Code terminal becomes useful: not when it launches, but when its actions are constrained by repository state and verified by repository-native evidence.

Related reading#

• Claude Code MCP config: a working configuration, explained line by line
• Cursor setup — the setup that survives a real repo

FAQ#

How to run claude Code via terminal?#

Install Claude Code through the official documentation, open a terminal, cd to the repository root, check git status --short, and run claude. Start with a bounded request so the agent inspects the relevant code and validation path before editing.

How to launch Code from terminal?#

If “Code” means Claude Code, navigate to the intended project and run claude. Do not launch from a broad parent directory. If “Code” means Visual Studio Code, that is a different command and product; confirm which tool you intend to launch.

How do you start a new claude Code session in the terminal?#

Open a new terminal session, enter the correct repository root, inspect its current Git state, and run claude. Recheck the directory and uncommitted changes every time; a new session should not inherit assumptions from the previous task.

How to activate claude Code in VS Code terminal?#

Open VS Code’s integrated terminal, confirm it is positioned at the repository root, run git status --short, and then run claude. The integrated terminal does not change the operating model described in the official overview.

How do I run my Code in terminal?#

Use the run, test, or build command defined by your repository rather than asking Claude Code to guess. Check the project documentation and scripts, run the narrowest relevant command, and distinguish running your application from launching the Claude Code agent itself.