Advanced

By default, Claude Code asks for your permission before doing anything potentially destructive: editing files, running terminal commands, making network requests. You approve or reject each action. This is fine when you are watching, but it slows things down if you want to let an agent run unattended.

There are two ways to give Claude more autonomy.

The first is the sandbox. Claude Code has built-in OS-level sandboxing that restricts where it can write files and which network domains it can access. When the sandbox is enabled, Claude can run commands freely within those boundaries without asking for permission each time. Enable it by typing /sandbox in Claude Code. You can configure exactly which directories are writable and which domains are reachable in your settings file.

The second is Docker sandboxing. If you want even stronger isolation, run Claude Code inside a Docker container. The agent gets a completely separate environment where it can build, install packages, and run code without any risk to your actual machine. Useful if you are letting agents run overnight or in parallel on tasks you have not fully vetted.

Codex handles this differently. In the Codex config.toml file (which you set up during installation), the sandbox_mode setting controls how much freedom Codex has. The options range from workspace-write (can only write inside your project folder) to stricter modes that require approval for every file change. The approval_policy setting controls whether Codex asks before acting.

Imagine an agent called pdf-searcher whose job is to go through handwritten lab notes, transcribe them to text, and search for a particular measurement. Rather than sequentially loading each PDF one by one, you can tell Claude to spawn several copies of the agent and run them in parallel across all the files at once.

Example prompt: "Spawn 6 of the pdf-searcher agents and parallelize them across the scans in the lab notes subfolder."

After the subagents finish, Claude can review their work and catch mistakes. It is always good practice to have Claude check its own output. Even better: have a completely different model check Claude's work. For example, Claude derives an analytical result while Codex verifies it numerically with Mathematica.

Claude accessing your Wolfram engine (Mathematica) is just one example. There is a wide range of external tools that LLMs can access to extend their capabilities. The way they communicate with these tools is called the Model Context Protocol, or MCP.

A few examples. Slack MCP servers let a research group communicate with a shared Claude instance. Calendar tools let Claude manage your schedule. You can set up an automation where Claude sends you a text message if there are ever any arXiv papers that match your interests (i.e. it is autonomously finding papers for you). New MCP servers are appearing all the time.

If you can think of it, you can probably build it. Setting up a group website, an onboarding portal, a text-to-speech AI that makes restaurant reservations for you. You describe what you want and iterate with Claude until it works without ever touching any code.

If you have never used Git before, here is the short version: Git tracks every change you make to the files in a particular folder. It keeps a complete history, so you can always go back to an earlier version if something breaks. It also lets multiple people (or multiple agents) work on the same project without overwriting each other's work.

You do not need to learn Git commands. Claude can handle all of it for you. Tell it to initialize a repo, commit your changes, create a new branch, or push to GitHub, and it will run the right commands. What matters is understanding the concept, not the syntax.

The most useful Git concept for working with AI is branches. A branch is a parallel copy of your project. You can create a branch, let an agent do a bunch of work on it, and then decide whether to keep those changes or throw them away. The original version of your project is untouched until you explicitly merge the branch back in.

This solves the problem of cluttered planning files. Each task gets its own branch. The agent creates its plan, does the work, and marks tasks as done, all on that branch. Your main project stays clean. When the task is finished, you merge it in and delete the branch.

For collaboration, Git lets multiple people push and pull changes to a shared repository on GitHub. You can have one person working on the analysis while another person's agent is cleaning the data on a separate branch. When both are done, you merge everything together. Claude can help resolve any conflicts that come up.

Every file Claude reads costs tokens. If your project folder has hundreds of files and Claude tries to read all of them to orient itself, you will burn through your budget fast and the context window will fill up with irrelevant material.

The fix is to be deliberate about what Claude sees. Keep a short summary in your CLAUDE.md that describes the project structure: which files are important, what each folder contains, and where to look for specific things. Think of it as a table of contents. When Claude needs to find something, it reads the summary first and then opens only the files it actually needs.

You can also tell Claude explicitly which files are "hot" (actively being worked on, should be read carefully) and which are "cold" (reference material, only open if specifically needed).

Sometimes you are in the middle of a productive session and want to try something without risking the current conversation thread. Claude Code lets you fork a conversation: it creates a copy of the entire session up to that point, and you continue in the new copy while the original stays untouched.

Useful when you want to test a different approach, try a risky edit, or let an agent explore an idea you are not sure about. If the fork works out, you keep it. If not, you go back to the original and nothing was lost.

Hooks let you attach custom actions to specific events in Claude Code. Every time Claude runs a tool, starts a session, submits a file edit, or finishes a task, a hook can fire. The hook can be a shell script, an HTTP request, a prompt sent to another model, or even a subagent.

Why is this useful? A few examples. Set up a hook that runs your test suite every time Claude edits a file, so you catch issues immediately. Have a hook that sends a Slack message when an agent finishes a long-running task. Add a hook that blocks Claude from writing to certain files unless a specific condition is met.

Hooks are configured in your settings file (.claude/settings.json for project-level, or ~/.claude/settings.json for global). You specify the event you want to hook into, an optional matcher to filter by tool name, and the action to run.