Autonomous-Run Safety in Claude Code: Sandboxing, Prompt-Injection Defense, and Audit Logs

Big one first, and it is fresh. Yesterday evening, June twelfth, Anthropic got a directive from the US Commerce Department ordering it to suspend all access to its two most capable models, Fable 5 and Mythos 5, for any foreign national. Here is the kicker. To actually comply, Anthropic had to disable both models for every customer on the planet, not just foreign nationals. They publicly confirmed compliance this morning, June thirteenth.

The government's stated rationale is national security, plus a method of jailbreaking that bypasses Fable 5's safeguards. The original order came in a letter from the Commerce Secretary to Dario Amodei back on June first. Anthropic says it disagrees with the order. They call the vulnerability narrow and non-universal, and they say they're working to restore access as soon as possible.

Why do you, sitting in Claude Code, care? Because Fable 5 had only just landed for us on June ninth, in version two point one point one seven zero. You could pick it with the model command, at ten dollars per million input tokens and fifty per million output. And days later it's gone. The good news is that every other Anthropic model is unaffected. Opus 4.8, Sonnet, and Haiku all stay up. So the concrete action is simple. If your model was set to fable, switch it back to Opus 4.8 with the model command, and you're back in business.

Now, item two, and this is the one that's right on theme for today's safety episode. Claude Code shipped versions two point one point one seven two through one seven six over June tenth to twelfth, and it's almost all autonomous-run safety hardening. The headline setting is a new managed one called enforce-available-models. It lets an admin lock the model set for unattended runs. The allowlist now also constrains the default model, a disallowed default falls back to the first allowed model, and crucially, user or project settings can no longer widen a managed list. Alongside that, alias model picks can no longer be redirected to blocked models through environment variables, and the fast command refuses to toggle outside the allowlist.

There's more in there for unattended runs. Sub-agents can now spawn their own sub-agents, nested up to five levels deep. They fixed background agents reading the wrong directory's MCP config on a pre-warmed worker. They fixed web-fetch domain wildcard rules that never matched subdomains, and file permission rules with mid-pattern wildcards that were silently rejected at startup. So the action item is, run claude update to one seven six, have your admins set enforce-available-models with an allowlist, and re-check any web-fetch domain rules or wildcard file permission rules that may have been quietly failing.

If you want the deeper background on sandbox-escape history and Anthropic's zero-trust-for-agents guidance, hold that thought, because the tutorial today walks straight into it.

Okay. Today we're building the gate. This is Act Two, supervised automation, and the whole question of this episode is the one you have to answer before you ever let Claude run unattended. Not how do I make it run by itself. We've been climbing toward that. The question is, what do I put up first so that when it runs by itself, a bad day stays a small day?

Here's the frame I want you to carry through the whole hour. There are three pillars. Sandboxing, prompt-injection defense, and audit logs. And they map onto three enforcement layers. The reason you need all three, and not just your favorite one, is that they fail differently. A wall that's strong against one attack is paper against another. So you stack them.

Let me give you the single most important sentence in the entire permissions documentation, because everything else hangs off it. Permission rules are enforced by Claude Code, not by the model. Instructions in your prompt or your CLAUDE-dot-em-dee file shape what Claude tries to do, but they do not change what Claude Code allows. Read that twice. The model's desires and the harness's permissions are two different things. And that gap is the whole game for unattended runs. A prompt injection can change what the agent wants to do. It cannot change what the harness permits.

The docs spell out the defense-in-depth version of this. Permission deny rules block Claude from even attempting to access a restricted resource. That's the first wall. The model never even tries. Then sandbox restrictions prevent Bash commands from reaching resources outside defined boundaries, even if a prompt injection bypasses Claude's decision-making. That's the backstop. It holds even when the model has been hijacked. And then audit logs are the third thing. They don't stop anything. They're the record for afterward, so you can prove exactly what happened.

So lay it out in one line. Deny rules are the first wall, where the model never tries. The sandbox is the operating-system backstop, which holds even if the agent's been talked into something. And the audit log is your receipt. Three pillars, three layers, three different failure modes covered.

Quick date context so you know where we are in mid-twenty-twenty-six. The GitHub Action prompt-injection vulnerability, which we'll dig into, was patched in claude-code-action version one point zero point nine four this June. Auto mode shipped back in March. And the built-in Bash sandbox, the one you reach with the slash-sandbox command, is now a first-class documented feature. So all three pillars are mature enough to actually lean on.

Let's start with pillar one. Sandboxing.

The native Bash sandbox does something genuinely nice for your workflow. Here's how the docs put it. The Bash sandbox lets Claude run most shell commands without stopping to ask permission. Instead of approving each command, you define which files and network domains commands can touch, and the operating system enforces that boundary for every Bash command and its child processes. So you trade prompt fatigue for a boundary. Instead of clicking yes forty times, you draw a box once and the OS guards it.

How it's enforced depends on your platform. On macOS it uses the built-in Seatbelt mechanism, so there's nothing to install. On Linux and on WSL2 it uses bubblewrap for filesystem isolation, plus a tool called socat as the network relay. Now hear this clearly. WSL1 and native Windows are not supported. If you're on Windows, you run Claude Code inside WSL2 for this to work at all. To install the Linux pieces, on Debian or Ubuntu you apt-get install bubblewrap and socat, and on Fedora you dnf install the same two. There's an optional seccomp filter you can add by installing the Anthropic sandbox-runtime package globally. Ripgrep is already bundled. And if you're not sure what you're missing, the slash-sandbox panel has a Dependencies tab that tells you.

One Ubuntu gotcha worth its own breath, because it'll bite you on twenty-four-oh-four and later. The default AppArmor configuration blocks bubblewrap from creating user namespaces, which is exactly what it needs. Check the sysctl value for apparmor-restrict-unprivileged-userns. If that comes back as one, you need to add an AppArmor profile that grants the user-namespace capability to the bwrap binary, then reload AppArmor. If your sandbox mysteriously won't start on a fresh Ubuntu box, that's almost always the cause.

Now, enabling it. You run slash-sandbox and you get a panel with three tabs. Mode, Overrides, and Config. When you pick a mode there, it writes to your settings-dot-local-dot-json, which is the file that does not get committed, so it's a per-machine choice. If you want it on everywhere, you set sandbox-enabled to true in your user-level settings file in your home directory.

There are two sandbox modes, and you have to keep them straight. The first is auto-allow. In auto-allow, sandboxed Bash runs without prompting, because the operating-system boundary substitutes for the prompt. The second is regular permissions, where sandboxed commands still go through the normal permission flow. And here's the crucial bit that trips people up. Sandbox auto-allow mode is not the same thing as the permission auto mode. They are independent, and they're combinable. You can run permission auto mode with the sandbox in regular mode, or any other mix. Two separate dials.

Even in auto-allow, the sandbox isn't a free-for-all. Explicit deny rules are still respected. A command like rm or rmdir targeting your root, your home, or other critical paths still prompts. Content-scoped ask rules, like an ask rule on git push, still force a prompt. The one thing auto-allow skips is a bare Bash or Bash-star ask rule, which gets bypassed for sandboxed commands. That behavior comes from a default setting named auto-allow-bash-if-sandboxed, which is true out of the box.

Let's talk about filesystem isolation, because the defaults here have a sharp edge. By default, writing is limited to your working directory and its subdirectories, plus the session temp directory. So a sandboxed command cannot write your bash-rc, cannot write into bin. Good. But reading. By default, reading is allowed across the entire computer, except for directories you've explicitly denied. And here's the nuance the docs call out directly, and that I want burned into your memory. This default still allows reading credential files such as your aws credentials and your ssh directory. You have to add them to deny-read to block them. Say that back. The sandbox does not block credential reads by default. If you do nothing, a sandboxed command can read your cloud keys. That is the single most surprising default in this whole system, and we'll come back to it when we talk about prompt injection.

The settings live under a sandbox filesystem section, with keys for allow-write, deny-write, deny-read, and allow-read. That last one, allow-read, lets you re-allow a specific spot inside a region you've denied. And these arrays merge across scopes, so user and project settings combine rather than overwrite.

The path syntax here is its own thing, and it's different from the Read and Edit permission syntax, which is a genuine footgun. In the sandbox, an absolute path is written plainly, like slash-tmp-slash-build. A home path uses the tilde, like tilde-slash-dot-kube. And a project-relative path is either dot-slash-output or just bare, with no prefix, meaning the project root. Contrast that with Read and Edit permission rules, where an absolute path needs a double slash and a project-relative path uses a single leading slash. Different worlds. Don't mix them up.

A worked example. Suppose you want to block reading your home directory but still let the agent read the project. You put this in the project settings file, and it's sandbox-enabled true, with filesystem deny-read set to your home directory and allow-read set to the project. That allow-read on the project carves the project back out of the denied home region. Or if you want to grant extra write access, say to your kube directory and a build temp directory, you set filesystem allow-write to those two paths. Simple once you've got the prefix rules straight.

Now network isolation, which is enforced by a proxy that lives outside the sandbox. The default here is the opposite of filesystem reads. No domains are pre-allowed. The very first request to a new domain prompts you. You pre-allow domains with the network allowed-domains list, and you block them with denied-domains, and denied-domains wins even when a broader wildcard would have matched. For a managed lockdown there's an allow-managed-domains-only switch.

But there's a security limitation here you have to say out loud to your team. The built-in proxy enforces the allowlist based on the requested hostname, and it does not terminate or inspect the encrypted traffic. Which means domain fronting is possible. And it means allowing broad domains, such as github-dot-com, can create paths for data exfiltration. Think about that. If you allowlist all of github, you've potentially allowlisted a place an attacker can post your secrets to. If you need real inspection of encrypted traffic, you bring your own proxy, pointing the sandbox at it with the http-proxy-port or socks-proxy-port settings, and if you've installed a man-in-the-middle certificate authority, you flip on enable-weaker-network-isolation.

A few more sandbox settings worth knowing. There's fail-if-unavailable, which you absolutely want for unattended runs. Set it true, and if the sandbox can't initialize, startup hard-fails instead of the default behavior, which is to warn and then run unsandboxed. Read that again, because it's a silent-downgrade trap. Without fail-if-unavailable, a broken sandbox doesn't stop your run, it just removes your protection and keeps going. There's allow-unsandboxed-commands, which when set to false disables the escape hatch that would otherwise let a command opt out of the sandbox. The Overrides tab calls that strict sandbox mode. There's excluded-commands, for tools that genuinely must run outside the sandbox. Docker, the gh CLI, gcloud, and terraform all fail their encrypted connections under Seatbelt, and jest needs its watchman disabled. But heads up, excluded-commands has no managed-only lockdown, so it's a hole an unprivileged settings file could widen. There's enable-weaker-nested-sandbox for running bubblewrap inside an unprivileged container, which, as the name says, weakens things. And there's an environment variable, subprocess-env-scrub, that strips your Anthropic and cloud credentials from the environment handed to sandboxed subprocesses. Because by default, a sandboxed Bash command inherits the parent environment, credentials and all.

One reassuring built-in. The sandbox automatically denies write access to Claude Code's own settings files at every scope. So a sandboxed command cannot modify its own policy. It can't rewrite the rules that constrain it. That's a nice closed loop.

And the scoping point that connects pillar one to everything else. The sandbox covers Bash subprocesses only. Read, Edit, and Write go through the permission system directly, not the sandbox. Subagents share the parent's sandbox config. Hold onto that Bash-only fact, because it is the exact seam the big prompt-injection attack exploited. There are also standalone primitives shipped as the sandbox-runtime package if you want to wrap the whole process, not just Bash.

Now let me talk about the anti-pattern, because it's the bridge into permissions. The dangerously-skip-permissions flag. YOLO mode. The docs say it's equivalent to permission-mode bypass-permissions. And when they ask what replaces the prompt, the documentation's answer is one word. Nothing. It also skips protected-path checks, as of version two point one point one two six. The only things that still prompt under it are explicit ask rules and removals of root or home. And the line you should tattoo on the cron job, verbatim. Bypass-permissions offers no protection against prompt injection or unintended actions. There's a root guard, so it's blocked when you run as root or sudo on Linux and macOS. It's auto-skipped inside a recognized sandbox, and the reference devcontainer deliberately runs Claude as non-root precisely so that auto-skip kicks in. There's also a separate allow-dangerously-skip-permissions flag, which just adds the mode to the Shift-Tab cycle without turning it on.

What replaces it is least privilege. The allowed-tools flag, the disallowed-tools flag, the permission-mode flag, and your allow and deny rules. Which brings us to permission modes, and you need the exact values.

Default is reads only. Accept-edits allows reads, file edits, and common filesystem Bash like mkdir, touch, rm, mv, cp, and sed, but scoped to your working directory and any additional directories. Plan mode is reads only with no source edits, which you already know from the permissions-and-plan-mode episode. Auto mode is everything, but with a background classifier checking each action. It's a research preview and needs version two point one point eight three or later. Bypass-permissions is everything with no checks. And then the one I want to sell you hardest for unattended work, dont-ask.

Dont-ask is the gem for unattended CI. Here's what the docs say it does. It auto-denies every tool call that would otherwise prompt. Only actions matching your allow rules and read-only Bash commands can execute. Explicit ask rules are denied rather than prompting. That makes the mode fully non-interactive. Do you hear the difference between that and bypass? Bypass says yes to everything. Dont-ask says no to everything you didn't pre-approve. One fails open, the other fails closed. For a run with no human at the keyboard, you want the one that fails closed, every time. You set it with permission-mode dont-ask, and notably it's never in the Shift-Tab cycle, you can only ask for it explicitly. You can make it the persistent default with permissions default-mode.

And there's a guard against a repo granting itself power. The dangerous default modes, that's auto, bypass-permissions, and dont-ask, are ignored when they come from project or local settings. They only take effect from your user settings or managed settings. And cloud web sessions ignore bypass and dont-ask from settings entirely. So a malicious project can't just drop a settings file that flips itself into bypass mode. Good.

Let's talk protected paths, because these have special handling. Directories like dot-git, the git config dir, dot-vscode, dot-idea, dot-husky, dot-cargo, dot-devcontainer, dot-yarn, dot-mvn, and dot-claude, with the exception of the worktrees folder inside it, are never auto-approved except under bypass. Same for protected files like your gitconfig, your bashrc and zshrc, your npmrc and yarnrc, the pre-commit config, the MCP config, the claude-dot-json, and the envrc. Per mode it goes like this. Under default, accept-edits, and plan, you get prompted. Under auto, the classifier decides. Under dont-ask, it's denied. Under bypass, it's allowed. And here's a subtle, important one. Your allow rules do not pre-approve protected-path writes. The protected-path check runs before the allow rules are even consulted. So you cannot accidentally allowlist your way into letting the agent rewrite dot-git.

Now the permissions syntax itself, because the evaluation order matters more than people think. You have three arrays. Allow, deny, and ask. The order is deny, then ask, then allow. First match wins. And specificity does not reorder anything. A more specific allow rule does not beat a broader deny rule. The governing sentence is, if a tool is denied at any level, no other level can allow it. Deny is absolute.

There's a meaningful difference between a bare tool name in deny and a scoped one. A bare tool name as a deny, like just Bash, or like the MCP wildcard, removes the tool from context entirely. The model doesn't even see it. A scoped deny, like a deny on rm-star, keeps the tool available but blocks the matching calls. Two very different effects.

Now the anchoring footgun, and this one genuinely costs people. Read and Edit anchors follow gitignore semantics. A double-slash path is absolute. A tilde path is home. A single-slash path is project-relative. And a bare path, or a dot-slash path, is the current working directory. So here's the trap. A path written as slash-Users-slash-alice-slash-file is not absolute. It's project-relative, because of the single leading slash. To actually mean absolute, you need the double slash. Get that wrong and your carefully written deny rule guards a path that doesn't exist. Also handy to know, a Read rule on dot-env is the same as a Read rule on star-star-slash-dot-env. It matches at any depth.

Here's a solid deny example to anchor on. You deny Read on dot-slash-dot-env and on dot-env, deny Read on your ssh and aws directories with recursive globs, deny Bash on curl-star and wget-star, and deny WebFetch entirely. For WebFetch, the domain rules work like this. You can scope to a domain, or to a wildcard subdomain pattern that matches subdomains but not the apex, and a domain-star is the same as bare WebFetch.

Now the big pitfall in this whole area, and it's why the docs basically beg you not to do it. Bash argument-constraining rules are fragile. Suppose you try to allow curl only to a specific URL. An attacker bypasses that by putting options before the URL, by switching to a different scheme, by using a redirect flag to bounce somewhere else, by assigning the URL to a variable first and then currying that variable, or just by adding extra spaces. The rule matches the literal text, and there are infinite ways to write a command that does the same thing with different text. So the docs' recommendation is blunt. Deny curl and wget outright and use WebFetch domain rules instead, or use a PreToolUse hook. And critically, using WebFetch alone does not prevent network access. If Bash is allowed, Claude can still use curl or wget to reach any URL. So WebFetch rules and Bash deny rules are not substitutes, you need both.

There's also compound-command awareness. The matcher knows about separators, the double-ampersand, the double-pipe, the semicolon, the single pipe, the single ampersand, and newlines. Each subcommand has to match independently. And it strips certain process wrappers before matching, things like timeout, time, nice, nohup, stdbuf, and bare xargs. But, and write this down, it does not strip devbox run, npx, docker exec, find with dash-exec or dash-delete, watch, setsid, or flock. Which means an allow rule on devbox-run-star would happily match devbox run rm dash r f dot. The wrapper you allowed becomes a tunnel for the command you didn't.

The good news on the other side. Read-only built-ins run with no prompt in every mode. ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, and read-only git operations. So you're not going to drown in prompts for harmless inspection.

One more deeply important seam. Read and Edit deny rules do not stop arbitrary subprocesses. If a Python or Node script opens a file directly, your Read deny rule does nothing, because it's the script doing the opening, not the Read tool. The docs say it plainly. For operating-system-level enforcement that blocks all processes from accessing a path, enable the sandbox. This is the core reason you need both layers. The permission system guards the agent's own tools. The sandbox guards every process the agent can spawn. Neither one covers the other's blind spot.

A couple of finishing pieces for pillar one. The Agent-Explore and Agent-Plan rules, plus the disallowed-tools flag, control which subagents can run, which ties back to the subagents episode. Working directories are managed with the add-dir flag, the slash-add-dir command, or the additional-directories setting. And for admins, there's a whole family of managed-only lockdowns, names like allow-managed-permission-rules-only, allow-managed-mcp-servers-only, allow-managed-hooks-only, plus switches to disable bypass mode and disable auto mode outright.

Containers tie a bow on sandboxing. You install Claude into a devcontainer using the Claude Code Dev Container Feature. The reference container in the Anthropic repo is really just three files. A devcontainer-json that sets volume mounts, run-args for capabilities, and container environment variables. A Dockerfile. And an init-firewall script, which, in the docs' words, blocks all outbound network traffic except the allowed domains. That firewall needs the net-admin and net-raw capabilities granted through run-args. To keep your auth across rebuilds, you mount a named volume at the claude config directory, or set the config-dir environment variable. Policy goes in a managed-settings file dropped at the etc-claude-code path, which has the highest precedence of all. And here's the payoff line. Because the container runs Claude Code as a non-root user and confines command execution to the container, you can pass dangerously-skip-permissions for unattended operation. So inside that box, with the firewall up, the flag we spent ten minutes warning you about becomes defensible. With a warning attached. It does not stop a malicious project from exfiltrating the Claude Code credentials stored in your config directory. So don't mount your ssh or cloud creds in there, and pair the flag with the network egress restrictions. The box is only as good as what you didn't hand into it.

That's pillar one. Pillar two, prompt-injection defense.

Start with the threat model. An unattended agent ingests untrusted content all day long. Issue bodies. Pull request comments. Fetched web pages. MCP tool results. File contents. CI logs. Any of those can carry an instruction. The cleanest mental model for the danger is Simon Willison's lethal trifecta. Three legs. One, access to private data. Two, exposure to untrusted content. Three, an exfiltration channel. When all three are present, you're cooked. Remove any one leg and the attack collapses. Translate that into Claude Code terms. Don't grant secret-reading, and outbound network through WebFetch or curl, and the ability to read attacker-controlled text, all in the same unattended run. Knock out any one and the trifecta is broken.

This is not theoretical. Here's the real attack from this spring. Microsoft Threat Intelligence, along with independent researchers, disclosed a now-patched flaw in the Claude Code GitHub Action. An attacker hid an instruction inside a GitHub issue or a PR comment, dressed up as a compliance review that told the model to read the process environment file. And the model obeyed. Now here's the architectural gap, and it's the lesson of the whole episode. The Action's environment scrubbing applied to the Bash subprocess path. Bash ran under bubblewrap with a scrubbed environment. But the Read tool was an in-process call, not subject to that same isolation. Remember what I told you to hold onto? The sandbox covers Bash only. So when the model read the environment file through the Read tool, it got back the unscrubbed environment, including the Anthropic API key. The sandbox was guarding the door while the Read tool walked in through the window.

And there was a laundering trick on top. The injection told the model to cut off the first seven characters of the credential before printing it, so that naive secret-scanning wouldn't see a recognizable token prefix and raise a flag. Clever and nasty. There was a second bug too, where the write-permission check unconditionally trusted any actor whose name ended in the bot suffix, regardless of their actual permissions. All of this was patched in claude-code-action version one point zero point nine four. The headline lesson, in one sentence. Tool isolation has to cover every data-reading path, not just Bash. The Read tool bypassed the sandbox, and that was the whole story.

Now the built-in protections, because Claude Code is not naked here. The security docs list a stack. The permission system, where sensitive operations need approval. Context-aware analysis, which detects potentially harmful instructions by analyzing the full request. Input sanitization against command injection. Network command approval, meaning curl and wget are not auto-approved by default. Isolated context windows, where web fetch uses a separate context window to avoid injecting potentially malicious prompts into the main one. Trust verification, where a first-time codebase and any new MCP server require a trust prompt, which ties back to the MCP episode. But here's the headless caveat you must internalize. Trust verification is disabled when running non-interactively with the dash-p flag. So the safety net you lean on interactively isn't there in your cron job. There's command-injection detection, where suspicious bash commands require manual approval even if previously allowlisted. And fail-closed matching, where unmatched commands default to requiring manual approval. And the best-practices lines worth quoting. Review commands before approval. Avoid piping untrusted content directly to Claude. Verify changes to critical files. And, use virtual machines to run scripts and make tool calls, especially when interacting with external web services.

Auto mode deserves real attention here, because it's a genuine injection defense, not just a convenience. A separate classifier model reviews each action before it runs. What does it block? In the docs' words, anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read. And here's the elegant part. The classifier does not see tool results. Tool results are stripped, so hostile content in a file or a web page cannot manipulate it directly. So the injection that fooled the main model can't also turn around and fool the judge, because the judge never reads the poisoned text. On top of that, a separate server-side probe scans incoming tool results and flags suspicious content before Claude reads it. Belt and suspenders.

What does auto mode block by default? Piping a download straight into a shell. Sending sensitive data to external endpoints. Production deploys and migrations. Mass cloud-storage deletion. Granting IAM or repo permissions. Force-push, and push to main. What does it allow by default? Local file operations in your working directory. Installing declared dependencies. Reading a dot-env and sending those credentials to their matching API. Read-only HTTP. And pushing to the branch you started on. You can set conversational boundaries too. If you tell Claude don't push, the classifier will block a push. But, big but, those boundaries are re-read from the transcript on each check, and they can be lost to context compaction. So the docs' guidance is, for a hard guarantee, add a deny rule instead. A spoken boundary is a preference. A deny rule is a wall. There's a fallback behavior worth knowing. Three consecutive blocks, or twenty total, and auto mode pauses and prompts you. But in dash-p mode, with no human to prompt, repeated blocks simply abort the session. Auto mode needs Opus 4.6 or Sonnet 4.6 or later on the API, and the newest Opus is gated behind an environment flag on the enterprise clouds.

The GitHub Action has its own defense layer, building on the GitHub Action episode. Content sanitization strips HTML comments, invisible characters, markdown image alt text, hidden HTML attributes, and HTML entities, exactly the places injections like to hide. There's actor allow and deny, with include and exclude lists where exclusion wins. There's the write-permission gate. The action can only be triggered by users with write access to the repository. Bots are denied by default, and an allowed-bots list opts specific ones in, with the warning that allowed bots are not permission-checked. There's an allowed-non-write-users escape hatch the docs say to use with extreme caution, and only with the standard GitHub token. For fork PRs, the rule is, do not check out an untrusted ref into the workspace root before this action. The safe pattern is to checkout with no ref, getting the base branch, then load the PR head into a side path with add-dir. Token scope is tight. The GitHub app receives only a short-lived token scoped specifically to the repository, so it cannot reach other repositories. When you do use the non-write-users hatch, there's best-effort subprocess scrubbing of secrets, and on Linux runners the subprocesses additionally run with PID-namespace isolation. And watch the show-full-output setting. It's disabled by default for security reasons, because when it's on, tool outputs and file contents, possibly including secrets, become publicly visible in the Actions logs on public repos. And it auto-enables when step-debug is turned on, which is a sneaky way to accidentally expose everything. Finally, commits are unsigned by default, so flip on commit signing if you need it, and you can restrict the toolset right in the action's claude-args.

The programmable guardrail that ties this pillar to the hooks episode is the PreToolUse hook. It fires before the permission prompt, and it can block. A hook that exits with code two stops the call before the permission rules are even evaluated, which means it can override an allow rule. But, and this preserves deny-first, hook decisions do not bypass permission rules, deny and ask rules are evaluated regardless. So the layering is, a hook can be stricter than your allow rules, but it can't be more permissive than your deny rules. There's a beautiful pattern in here. To run all Bash commands without prompts except for a few you want blocked, add Bash to your allow list, and register a PreToolUse hook that rejects those specific commands. Allow broadly, deny surgically.

The hook mechanics. Exit code zero is success. Exit code two is a blocking error, where stderr is shown to Claude, stdout is ignored, and the tool is blocked. Any other non-zero is a non-blocking error. For PreToolUse the preferred output is JSON, where you emit a hook-specific-output object with a permission-decision, and the values there are deny, allow, ask, and defer, each with a reason string. The hook receives a rich JSON input, with the session id, the transcript path, the working directory, the permission mode, the event name, the tool name, and the tool input, where for Bash you read the actual command string off the command field. The matcher filters on the tool name, so you can match just Bash, or Edit-or-Write together, or an MCP regex, and a star or an omitted matcher means all tools. Beyond PreToolUse there are other useful events. PostToolUse, PostToolUseFailure, SessionStart, PermissionRequest, PermissionDenied, and ConfigChange. The docs specifically suggest auditing or blocking settings changes during a session with ConfigChange hooks. And the classic defense examples are exactly what you'd expect. Block rm dash r f. Block writes to immutable test files. Block curl to non-allowlisted domains by parsing the command string.

That's pillar two. Pillar three, audit logs and observability. This is the receipt, the thing that lets you answer, after the fact, what did it actually touch.

Start on disk. Your transcripts live in the claude projects directory, one JSONL file per session. The docs describe it as the full conversation transcript, every message, tool call, and tool result. There's a subagents folder with subagent transcripts, and a tool-results folder where large outputs get spilled to files. There's a history file that records every prompt you've typed, with a timestamp and project path, and it's kept indefinitely. There's a file-history folder with pre-edit snapshots, a debug folder that only fills in with the debug flag, and a stats cache that backs the usage numbers. But here's the liability warning you have to take seriously. Transcripts and history are not encrypted at rest. Operating-system file permissions are the only protection. And then, chillingly. If a tool reads a dot-env file or a command prints a credential, that value is written to the session transcript. So your audit log is also a credential graveyard. Anything a secret touches, it leaves a copy behind on disk in plaintext. Auto-cleanup happens after a configurable number of days, defaulting to thirty.

For headless runs, you've got structured output, building on the headless episode. With output-format json, the payload includes the total cost in dollars and a per-model cost breakdown, plus the result, the session id, and usage numbers. You parse it with jq pulling the result field. There's also output-format stream-json, which, with verbose and partial messages on, gives you newline-delimited events, where a system-init event reports the model, tools, MCP servers, and plugins, and you can capture every tool call as it streams. There's a bare flag for reproducible CI, which skips auto-discovery of hooks, skills, plugins, MCP, and your CLAUDE-dot-em-dee file, so only the flags you pass explicitly take effect. The docs note bare will eventually become the default for dash-p. And a billing note. As of mid-June, dash-p and the Agent SDK on subscription plans draw from a separate monthly Agent SDK credit.

Now the piece I'd point most teams at, OpenTelemetry, which I'll just call OTel from here. You enable it with the enable-telemetry environment variable set to one. You pick exporters for metrics and for logs, choosing among otlp, prometheus, console, or none. You point it at an endpoint with the standard OTel protocol, endpoint, and headers variables. The metrics it emits cover session count, lines of code, pull requests, commits, cost in dollars, token usage, code-edit-tool decisions, and active time. But the audit-grade signal is in the events, exported through the logs exporter. You get a user-prompt event, a tool-result event, an api-request event that carries the cost in dollars, api-error and api-refusal events, and, the one I care about most for safety, a tool-decision event that records every permission decision. That tool-result event is rich. It carries the tool name, the tool use id, whether it succeeded, the duration, any error type, the decision type, and the decision source, which tells you whether the decision came from config, from a hook, or from a permanent or temporary user approval. It also carries the input and result sizes in bytes. And there's a prompt id, a UUID that ties a single prompt to all of its downstream events, which the docs call ideal for audit trails. There are detail gates that are off by default, because they're redacted otherwise. You opt into logging user prompts, into tool details like the full Bash command and file paths, into tool content, and into raw API bodies. And every event carries standard attributes, the session id, the user account id, the user email, the organization id, and any custom resource attributes you set. The point of all this, and I want to land it hard. None of this requires custom instrumentation. Claude Code emits identity, session, tool invocations, cost, and permission decisions out of the box. You just turn it on and point it somewhere.

You can also roll your own audit log with hooks, which loops back to the hooks episode. A PostToolUse hook can read the JSON on standard input, pull the tool name, tool input, and session id, and append a line to a log file, then exit zero. Put it on a star matcher and it logs everything. And remember, a PreToolUse hook logs before execution, so it catches blocked calls too, the ones a PostToolUse hook would never see because they never ran.

For label and comment-driven runs, the GitHub Action run is itself the record. The action run logs plus the resulting PR diff are your audit trail, no extra plumbing needed. And for cloud web sessions, all operations are logged for compliance and audit purposes, they run in isolated Anthropic-managed VMs, git push is restricted to the current working branch, and the session is auto-terminated when it's done.

Now, cost and turn caps, which sit right on the border between safety and the next episode. You bound iterations with the max-turns flag, which the Action defaults to ten. You set a workflow timeout and concurrency controls. And you watch the total cost in the JSON output, and the cost-usage metric in OTel, to alert or cap your spend. One honest caveat. Present the budget cap as cost-tracking plus turn-capping, rather than asserting a single max-budget flag, unless you've verified that flag exists. And here's your forward pointer. This cost-and-turn-cap thinking is exactly where blast-radius engineering picks up, which is next episode. So if you're thinking, capping turns isn't really enough to bound the damage, you're right, and that's the whole next conversation.

Let me pull all three pillars into one thing you can copy. The locked-down unattended run.

Picture a scheduled or label-driven headless run, boxed in on all three pillars. Your project settings file sets the default permission mode to dont-ask. It has a deny block. Deny Read on dot-env, deny Read on your ssh and aws directories, deny curl and wget, deny WebFetch, and deny git push. It has an allow block, scoped tight. Allow your test command, your build command, git add, git commit, plus Edit and Read. It has a sandbox section with enabled true, fail-if-unavailable true, deny-read on your ssh and aws directories, and a network allowed-domains list with just the npm registry and the Anthropic API. And it has hooks. A PreToolUse hook on a Bash matcher running a guard script, and a PostToolUse hook on a star matcher running an audit script. The guard script denies rm dash r f, denies network egress, and denies writes to immutable test files, either by exiting two or by emitting a deny decision. The audit script appends the tool name, tool input, and session id to a log.

You invoke it with claude dash-p, your task, permission-mode dont-ask, max-turns fifteen, and output-format json, piping into jq to grab the result, the total cost, and the session id. You run the whole thing inside the reference devcontainer with the init-firewall script and the net-admin and net-raw capabilities, so that even an injection that talks Claude into running curl finds the socket dead. And you export OTel, with telemetry enabled and the logs exporter set to otlp, so the tool-result and tool-decision events land in your backend.

And now look at what defense-in-depth bought you. The deny rule means the model never even tries. The sandbox and the firewall mean the operating system stops it if an injection hijacks the model anyway. And the tool-result event plus the transcript let you prove afterward exactly what it touched. Three pillars, three layers, three different failure modes covered. Any one of them can fail and you're still standing.

Let me leave you with the one pitfall that matters most, because it's the one that actually happens. The silent success of dangerously-skip-permissions. Here's the story. A developer tests interactively, where the prompts are quietly protecting them the whole time. It works great. So they add dangerously-skip-permissions to the cron job or the Action to make it just work unattended. And now nothing, nothing, stands between an injected instruction and rm dash r f, or a credential getting curled out. How do you recognize it? The run completes with zero permission prompts. Protected-path writes to dot-git, to dot-claude, to the MCP config, all succeed silently. And in the transcript, the tool calls show a decision source of config or none, instead of a genuine user approval. The fix is to replace it with dont-ask plus an allowlist, or with auto mode, and to set disable-bypass-permissions-mode in your managed settings so nobody can quietly add the flag back. One subtle wrinkle. It's silently blocked when you run as root, by the root guard. So if your container runs as root, the flag fails closed, which actually masks the fact that you were ever depending on it. The day you fix the root setup, the dependency surfaces.

And the injection variant of the same pitfall. WebFetch and secret-read both available in the same run. That's exactly the lethal trifecta the Microsoft and oddguan researchers completed, private-data read plus an egress channel, from a single planted GitHub issue, with the credential laundered by cutting the first seven characters. How do you recognize it? Unexpected secrets showing up in your OTel tool-result events or your transcript. An outbound request to an unexpected domain right after a credential read. A Read of the process environment file or your aws credentials that you never asked for. And the fix is the whole episode in miniature. Never grant secret-read and outbound network in the same unattended run. Deny-read your credential directories, because remember, the sandbox does not block them by default. Deny curl, wget, and WebFetch. Pin the GitHub Action to one point zero point nine four or later. And never forget the seam, Read and Edit deny rules don't stop a subprocess that opens the file itself. Only the sandbox does that.

That's the gate. Three pillars, stacked, each catching what the others miss. Build it before you walk away from the keyboard, not after. Next episode, we take the turn-and-cost caps we touched on and turn them into real blast-radius engineering. See you then.