Running Claude Code unattended without regretting it

Start with the machine, not the flags

Every guardrail below is easier when the agent runs on a machine that holds nothing else. On your laptop, “allow all” means your email, your password manager, your production credentials, and your photos. On a dedicated machine with one repository and one scoped token, “allow all” means that repository and that token. Anthropic's own guidance is that the bypass mode belongs in an isolated environment. Put the agent in one and the rest of this page gets simpler.

Claude Code's permission modes

Claude Code has four modes. Pick one per task, not one forever.

• default. Asks before file edits and shell commands. Right for interactive work. Wrong for overnight.
• acceptEdits. Edits files in the working directory without asking. Still asks before shell commands. A good middle setting for refactors where the tests are the judge.
• plan. Reads and thinks but changes nothing. Use it to get a plan you review before the real run.
• bypassPermissions. No prompts at all. This is the unattended mode. Only use it on an isolated machine with the deny rules below in place.

Set the mode when you start.

claude --permission-mode acceptEdits

Or make one the default for a project in its settings file, which you can commit so the whole team shares it.

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Deny rules work in every mode

This is the part most people miss. Permission rules layer on top of the mode, and a deny rule blocks the action even in bypass mode. That makes deny rules the real safety net for unattended runs. Allow rules pre-approve things you would say yes to every time, so the agent does not stall on them.

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push origin HEAD:*)"
    ],
    "deny": [
      "Bash(git push:*--force*)",
      "Bash(git push origin main:*)",
      "Bash(rm -rf:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)"
    ]
  }
}

Read the deny list as a policy, because that is what it is. No force pushes. No pushing to main. No recursive deletes. No outbound requests the agent invents. No reading secrets files. Adjust it to your project, but keep a deny list on every unattended machine.

Hooks for the rules a pattern cannot express

Some rules depend on context. A hook runs a script before a tool call and can approve, block, or change it. A common one blocks any command that mentions a production hostname, whatever the command is.

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./scripts/block-prod.sh" }
        ]
      }
    ]
  }
}

The script reads the tool call from standard input and exits with a non-zero code to block it. Keep hooks small and boring. A hook that can fail in a way nobody notices is worse than no hook.

Git is your best guardrail

Settings inside the agent are one layer. The repository is a second layer that does not care which agent is running.

• Protect main. Require a pull request and a green CI run to merge. Then a rogue push cannot land anything.
• One branch per task. The agent starts on a fresh branch and pushes only that branch.
• Give the agent a token that can push branches and open pull requests, and nothing else. No admin scope. No delete scope. A fine-grained GitHub token scoped to one repository does this.
• Tests are the judge. If the suite fails, the pull request stays red and you see it in the morning.

Credentials: least, and separate

Never put a personal credential on an unattended machine. Make a separate account or token for the agent with the smallest scope that lets it do the task. Staging, not production. Read-only where read is enough. If the agent needs to sign in to a service through a browser, sign in to a test account. Rotate the token when the project ends.

Headless runs with a ceiling

For a scripted task, the print mode runs one prompt and exits. Give it a turn limit so a confused agent cannot loop all night.

claude -p "Fix the failing tests in packages/api and open a PR" \
  --permission-mode acceptEdits \
  --max-turns 60

Log the output to a file. In the morning you want to read what it did, not guess.

The same rules for Codex

Codex CLI separates two questions. When does it ask for approval, and what can it touch. For an unattended task inside one repository, the combination is never ask, and write only inside the workspace.

codex -a never -s workspace-write exec "Fix the failing tests and commit"

Codex also has a flag that removes both the approvals and the sandbox. Treat it exactly like Claude Code's bypass mode. Isolated machine or not at all.

The never list

Whatever tool you use, an unattended agent should not be able to do any of these. If your setup allows one of them, fix that before the first overnight run.

• Push to a protected branch or force push anywhere.
• Read or send a secret it did not need for the task.
• Touch production data, even to read it.
• Spend money. No cloud consoles, no payment pages, no ad accounts.
• Send messages to people. Not email, not chat, not social.
• Delete anything outside the working tree.