The longer you let Claude Code run on its own, the more clearly you need to answer one question: if it gets something wrong, how far does the damage reach? The three tips in this part are three levels of autonomy, each paired with a way to contain the risk.
This is part seven of a series that walks through all 50 Claude Code tips in YK Sugi's claude-code-tips repo, and it opens the advanced group. It covers tips 31, 19, and 32: auto mode, isolated environments for long and risky work, and controlling Claude Code from your phone.
Auto mode is the sensible default for most people, containers are for work that needs complete freedom, and Remote Control belongs on only when you understand who could reach your session.
What is auto mode, and why turn it on?
Auto mode lets Claude decide whether a command is safe to run in context, instead of asking you to approve each one. Underneath, a second model acts as a classifier that reviews each action in your place and only stops to ask when something looks risky. You cycle to auto mode with Shift+Tab.
What auto mode fixes is mindless approving. When a command is too long to read carefully, or you are getting tired, you approve things without really thinking about them. A confirmation prompt that people click through on reflex protects no one, so I agree with the repo that auto mode is a good default. To make it the default, add this to ~/.claude/settings.json:
{
"permissions": {
"defaultMode": "auto"
}
}Two notes from the official docs. First, defaultMode set to auto only takes effect from user or managed settings, not from project settings. Second, from Claude Code v2.1.283, auto mode is already the built-in starting mode for terminal and VS Code sessions; on earlier versions it was the default only on Pro, Max, and Team plans. If you want to stay careful, you can still approve everything by hand; if you want complete freedom, move to a container as described below.
When do you need an isolated environment?
When you want to run a --dangerously-skip-permissions session, where you don't approve every little thing, and let Claude work on its own for a long stretch. The work that suits this is research or experimentation: long-running, and possibly risky. Auto mode still doesn't remove the risk or the need for approval entirely, so for work that needs complete independence, an isolated environment is still the answer.
There are two main routes. The first is a container; the repo author built safeclaw, a preset environment that makes containerized Claude Code sessions easy. The second goes further: setting up a whole machine that Claude Code fully controls, computer use included.
Isolation swaps the question "is this command safe?" for "if every command were wrong, what would I lose?" In a container, the answer is the container, not your disk. In part one, the setup script's cs alias is exactly claude --dangerously-skip-permissions; this is the one place I think that alias should be used.
Orchestrating a worker Claude Code in a container
You can have the Claude Code on your machine control another Claude Code running inside a container. The trick is using tmux as the control layer, in four steps:
- Your local Claude Code starts a tmux session.
- In that session, it runs or connects to the container.
- Inside the container, Claude Code runs with
--dangerously-skip-permissions. - The outer Claude Code uses
tmux send-keysto send prompts andcapture-paneto read output.
The result is a fully autonomous "worker" Claude Code that can run experimental or long-running tasks without you approving every action. When it finishes, your local Claude Code pulls the results back; if something breaks, it all stays inside the container's sandbox. If you read part five, this is the same tmux technique used for testing, except this time the thing being driven is an agent rather than a test.
Orchestrating multiple models from one place
Beyond Claude Code, you can run other AI CLIs in containers, such as Codex or Antigravity CLI. The repo author tried OpenAI Codex for code review and found it works well. You can of course run those CLIs directly on your machine.
What Claude Code adds is an interface smooth enough that you can just talk to it and let it handle the orchestration: spinning up different models and moving data between containers and the host. Instead of switching terminals and copy-pasting by hand, Claude Code becomes the central interface that coordinates everything. To me this fits best when you want a second opinion, such as having another model review code Claude just wrote.
How do you control Claude Code from your phone?
Remote Control lets you drive Claude Code from your phone, and it pairs very well with auto mode: kick something off, walk away, and check in from anywhere. There are two ways to use it.
The first: run /remote-control (or /rc for short) inside an open session, follow the instructions, and you drive that same session from your phone. Because it is the same session, you can move back and forth between phone and computer freely. The second: start a server that can create new sessions from your phone, not just attach to one you already have open:
claude remote-control --spawn=worktree --capacity=N--spawn=worktree gives each new session its own git worktree so they don't step on each other, and --capacity sets the maximum number running at once (the docs list a default of 32). With the cr alias from part one, that becomes cr --spawn=worktree --capacity=N.
Should Remote Control be on for every session?
No, unless you are running in a fully isolated environment. The repo author prefers the /rc method and turns it off when not using it, because an attacker who gets into your Claude Code session essentially has access to everything on that computer. The exception is an isolated environment: there, being able to start a Claude Code session from your phone anywhere, with your full dev environment behind it, is extremely convenient.
If you still want every new session to enable Remote Control automatically, turn on "Enable Remote Control for all sessions" in /config, or set "remoteControlAtStartup": true in ~/.claude/settings.json. It is off by default. One safety detail worth knowing: in project settings (.claude/settings.json), Claude Code honors false but ignores true, so a settings file committed to a repo can't turn Remote Control on for everyone who opens it.
Which level of autonomy should you choose?
| Level | Who approves commands | Fits |
|---|---|---|
| Manual approval | You | Sensitive work, when you want to see each step |
| Auto mode | The classifier, asking when risky | The default for everyday work |
Container + --dangerously-skip-permissions | No one; the risk stays in the container | Experiments, research, long-running jobs |
| A machine Claude fully controls | No one; isolation at the machine level | Deep automation, computer use included |
Start with auto mode, since it ends the click-through habit without asking you to build any infrastructure. Move to a container only when you have a specific job Claude needs to run for hours with nobody watching, and keep Remote Control on permanently only when that session lives in an isolated environment.