How to Use Claude Code Agents: Setup, Tools, Permissions, and Sandbox Workflow

To use Claude Code agents well, treat Claude Code as an agent loop rather than a chat window: start it inside the repository you want changed, give it clear project instructions, connect only the tools it actually needs, keep permissions tight, and run execution inside an isolated runtime when the workflow moves beyond low-risk local edits. That is the difference between a helpful coding session and an expensive, messy one.

If your main question is broader than Claude Code itself, start with What Are Coding Agents? for the architecture view. If you are deciding between tools first, compare Claude Code vs Cursor. This guide is narrower: how to use Claude Code agents in practice.

What people usually mean by “Claude Code agents”

Most developers searching for “Claude Code agents” mean one of two things:

1. Claude Code itself acting as an autonomous coding agent.
2. Multiple specialized agents, tools, or subagents working inside a Claude Code workflow.

Both are valid. Claude Code already behaves like an agentic coding tool: it can inspect a repository, edit files, run commands, and react to results. Anthropic also documents related building blocks such as MCP tool integrations, hooks, and subagents, which is why the term often shows up in the plural.

The practical model is simple:

• Claude Code is the host workflow.
• The model handles planning and next-step decisions.
• Tools provide file access, commands, browsers, APIs, and external systems.
• Permissions decide what Claude is allowed to do without asking.
• A sandbox gives you a safe place to run code and tool execution.

If you keep those five layers separate, Claude Code becomes much easier to operate reliably.

Step 1: Install Claude Code and start in the right directory

Anthropic documents Claude Code as an installable CLI. The standard install path is:

npm install -g @anthropic-ai/claude-code
claude

The important detail is not just installation. Start Claude Code from the repository you want it to work on. Claude Code reads the current directory, local project instructions, and any project-scoped tool configuration from there.

If the repo is new, run:

/init

That generates a starter CLAUDE.md file for project-specific instructions. Use it for things Claude should remember every session: preferred test commands, coding standards, architecture boundaries, review expectations, and files it should treat carefully.

This matters more than most users expect. A Claude Code agent without repository-specific instructions is usually not underpowered. It is under-specified.

Step 2: Give the agent a task it can actually execute

Claude Code works best when the task includes a concrete outcome and a verification step.

Good examples:

• “Add rate limiting to /login, update tests, and run the affected test file.”
• “Refactor the billing service to use the new client, then run unit tests for that package.”
• “Review this PR diff for security and correctness issues.”

Weak prompts are usually vague in exactly the wrong way:

• “Improve this code.”
• “Make the app better.”
• “Check the project.”

Agentic coding tools do better when the finish line is explicit. If you want autonomy, define success. If you want exploration, define scope.

Step 3: Configure only the tools you need

Claude Code uses the Model Context Protocol for external tools. In practice, that means MCP servers are the extension surface for browsers, databases, issue trackers, GitHub, code runners, and internal services.

The most common setup command is:

claude mcp add playwright -- npx -y @playwright/mcp@latest

That gives Claude browser automation tools. Anthropic’s MCP docs and quickstart cover the same pattern for other servers.

The key operating rule is restraint: do not attach every tool you might someday want. Attach the smallest toolset that matches the job. Too many tools increase startup noise, widen the action surface, and make tool selection less predictable.

For most repository work, a sensible starting set is:

• local file and shell access
• one browser tool if web QA is required
• one issue or docs tool if the task depends on an external system

Everything else should earn its place.

Step 4: Use permissions deliberately, not as an afterthought

One of the biggest differences between a safe Claude Code workflow and a reckless one is permission discipline.

Claude Code exposes permission controls because tool execution is the real risk boundary. Reading a file is one thing. Running install scripts, deleting directories, or accessing external services is another.

Use /permissions early in a project, especially if the session may:

• write to many files
• run shell commands
• install packages
• access secrets or internal systems
• call MCP tools with side effects

The right setup depends on the job:

• For exploratory debugging, ask-before-run is usually the safer default.
• For repetitive, well-scoped repo work, allow rules can reduce interruption.
• For high-risk commands or sensitive paths, deny rules should stay explicit.

This is also where many teams make the wrong optimization. They remove friction by opening permissions too widely, then try to recover control with prompt wording alone. That is backwards. Prompting is guidance. Permissions are enforcement.

Step 5: Understand the actual agent loop

Claude Code feels powerful when you understand what is happening under the hood.

The loop usually looks like this:

1. Claude reads the task and project context.
2. It plans the next useful step.
3. It reads files or calls tools.
4. It edits code or executes a command.
5. It checks the output.
6. It revises the plan based on what happened.
7. It stops when the requested outcome is complete.

That loop explains why agent workflows are different from normal chatbot usage. The model is not only generating code. It is coordinating state across tools, files, command output, and intermediate failures.

For real repository work, the most important parts are usually not the first answer. They are the recovery steps after the first test failure, lint error, or environment mismatch.

Step 6: Use subagents when specialization helps

Claude Code now includes subagent support because one general-purpose agent is not always the best fit for every task.

Subagents make sense when the workflow benefits from specialization, for example:

• one agent for implementation
• one agent for code review
• one agent for documentation
• one agent for test investigation

This does not mean every project needs a swarm. In small repositories, multiple agents can add overhead faster than they add value. But for teams with repeatable handoffs, subagents are useful because they let you encode narrower instructions and responsibilities.

The operating principle is the same one good engineering teams already use: separate roles when the boundaries are clear enough to be useful.

If you cannot explain why a second agent exists, you probably do not need it.

Step 7: Use hooks for control and auditability

Hooks are the right answer when you want Claude Code sessions to trigger predictable checks at specific points in the workflow.

Examples:

• run formatting after file edits
• log file changes after write operations
• block commands touching protected paths
• send events into a local audit trail

Hooks matter because they make the workflow less dependent on the model remembering every policy every time. If a step must always happen after a category of action, automate that boundary instead of hoping the session prompt is enough.

This is especially important once Claude Code becomes part of a repeatable team process rather than a one-off individual tool.

Where Novita fits in a Claude Code agent stack

Claude Code is the agent interface. It is not the whole stack.

Once a team uses Claude Code seriously, two separate infrastructure questions appear:

1. Which model backend should handle the reasoning?
2. Where should tool execution actually run?

Those are exactly the places where Novita fits naturally.

Use Novita LLM API for backend flexibility

Novita documents an Anthropic-compatible endpoint for Claude Code-style workflows. That means you can keep the Claude Code interaction pattern while pointing the model traffic at Novita-hosted models instead of only one default route.

The standard environment pattern is:

export ANTHROPIC_BASE_URL="https://api.novita.ai/anthropic"
export ANTHROPIC_AUTH_TOKEN="<your-novita-api-key>"
export ANTHROPIC_MODEL="qwen/qwen3-coder-480b-a35b-instruct"

That setup is useful when you want to benchmark different coding models without rebuilding your tool layer.

It also creates a more natural path for teams that want Claude Code ergonomics but not a single-model operating assumption. The interface stays familiar; the backend becomes testable.

Use Novita Agent Sandbox for execution isolation

The second half of the problem is execution.

A Claude Code agent that only reads and writes small local files is one thing. A Claude Code agent that runs commands, installs packages, launches browsers, downloads dependencies, or touches production-like systems is another.

That is where an isolated runtime stops being optional and starts being part of the design.

Novita Agent Sandbox is positioned for exactly this layer: isolated environments for code execution, filesystem work, browser automation, and long-running agent workflows. In other words, it covers the part of the stack where side effects happen.

The clean mental model is:

• use Claude Code for the agent workflow
• use Novita LLM API for model routing and experimentation
• use Novita Agent Sandbox for safe execution boundaries

Keeping reasoning and execution separate is usually the better long-term architecture.

A practical open-model option inside the same workflow

Once you have Claude Code working well, the next question is usually not “Can this use agents?” It is “Which backend is worth paying for every day?”

This is where open-weight coding models become interesting in a very practical way. If your team likes Claude Code’s interface but wants cheaper experimentation or more provider flexibility, an open model can be the right next benchmark.

One credible candidate is Qwen3-Coder-480B-A35B-Instruct through Novita’s Anthropic-compatible route. You do not need to treat it as a guaranteed replacement for Claude on every task. You should treat it as a serious coding-model option that belongs in the same evaluation set as closed alternatives.

That is the natural shift many teams make:

• keep the agent workflow
• keep the tools
• keep the permissions model
• change the backend and compare real task outcomes

If the work is dominated by repository navigation, straightforward implementation, and tool calling rather than frontier-level reasoning, an open model can be competitive enough to justify the test.

This is one of the more useful things about the Novita setup: it lets you compare that question inside a familiar Claude Code workflow instead of turning the benchmark into a migration project.

Common mistakes when using Claude Code agents

Most failures come from workflow design, not from the idea of agentic coding itself.

Giving the agent broad goals without a finish line

If you want reliable outcomes, specify the deliverable and how to verify it.

Attaching too many tools

More tools do not automatically make Claude smarter. They usually make routing noisier.

Treating permissions as a UX annoyance

Permissions are the control plane for side effects. They should be tuned, not bypassed.

Running risky actions directly on a developer machine

If the agent is doing browser automation, package installs, or repetitive command execution, use an isolated runtime.

Confusing one useful demo with a production workflow

A Claude Code demo can look good in five minutes. A production workflow needs policy, auditing, runtime isolation, and model choice discipline.

Recommended workflow for most teams

If you want a pragmatic default, use this order:

1. Start Claude Code in the target repository.
2. Run /init and make CLAUDE.md useful.
3. Attach only the MCP tools needed for the task.
4. Configure /permissions before broad execution.
5. Use a sandbox when the workflow executes real code or browser steps.
6. Benchmark at least one alternate backend through Novita before standardizing cost assumptions.

That sequence keeps the system understandable. It also keeps you from mixing product ergonomics, model quality, tool sprawl, and runtime safety into one blurry decision.

FAQ

Is Claude Code itself an agent?

Yes. Claude Code is an agentic coding workflow rather than a plain code-completion tool. It can inspect files, edit code, run commands, and react to tool results.

Do I need MCP to use Claude Code agents?

No. Claude Code is useful with local repository access alone. MCP becomes important when you want external tools such as browsers, databases, APIs, or issue systems.

When should I use a sandbox with Claude Code?

Use one when the workflow runs code, installs packages, launches browsers, or performs repeated side-effecting actions you do not want executed directly on the host.

Can Claude Code use models through Novita?

Novita documents an Anthropic-compatible setup for Claude Code-style workflows, so you can keep the Claude Code interface while routing model requests through Novita-hosted models.

Should I use multiple subagents right away?

Usually no. Start with one agent and add subagents only when the specialization is clear enough to reduce confusion rather than create it.

Recommended Articles

• Claude Code Plugins: How MCP Tools Extend Claude Code with External Capabilities
• Claude Code Supported Models in 2026: Which One Should You Use?
• What Are Coding Agents? How They Work and How to Build One

Sources checked August 24, 2026: Anthropic Claude Code overview, Anthropic Claude Code settings and permissions, Anthropic Claude Code hooks, Anthropic Claude Code subagents, Anthropic Claude Code MCP, Novita Claude Code guide, and Novita Sandbox overview.