Breaking Claude Code Opus 5 Auto Mode

Breaking Claude Code Opus 5 Auto Mode is a security note from Embrace The Red about testing Claude Code, Anthropic’s coding agent, with Opus 5 and Auto Mode enabled. It deals with a simple but uncomfortable question: what happens when an AI coding agent has both broad context and fewer approval stops? The useful takeaway is not “never use Auto Mode”; it is “treat Auto Mode as a convenience feature, not a security boundary.” That matters for any Claude Code workflow where the agent reads code, docs, tickets, logs, or web content it did not author.

Read the post as a boundary test

The Embrace The Red post landed because it pokes at a real fear in agentic coding: the model may follow instructions that were never meant for the developer. In a coding session, those instructions can hide in README files, issue bodies, copied error output, generated docs, dependency notes, or any other text that looks like normal project material.

Auto Mode is a Claude Code setting that lets the agent take more actions without stopping for every confirmation, so the approval boundary moves from each tool call to the way the session is configured. That shift is convenient. It also makes the first boundary decision much more important.

The interesting part of the post is the shape of the failure it explores. It is less about one magic string “breaking” a model and more about whether an agent can keep trusted user intent separate from untrusted surrounding text while it has useful tools available.

The trap is arguing only about the model name. Opus 5 may be the model in the story, but the engineering question is broader: which actions should an AI coding agent be allowed to take automatically after it has consumed untrusted context?

Separate model mistakes from automation mistakes

A model mistake is when Claude misunderstands, overgeneralizes, or follows the wrong instruction. An automation mistake is when the surrounding tool setup lets that misunderstanding turn into a write, command, network call, or secret access without another checkpoint.

That distinction is why developers paid attention. Auto approval does not create prompt injection by itself, and one Hacker News reaction to the write-up made roughly that point. But Auto Mode can reduce the number of places where a human notices the agent has crossed from “reasoning about text” into “doing work on the machine.”

A concrete repo example helps. Imagine a scratch issue reproduction where Claude reads a third-party bug report, edits package.json, runs tests, and opens a patch. That is a lovely Claude Code loop when the input is boring. It is a very different loop if the bug report contains instructions to read local files, change CI scripts, or exfiltrate environment details.

The trap is treating the chat transcript as the only surface area. The real surface is the whole session: repository files, shell commands, MCP servers, environment variables, hooks, generated artifacts, and whatever context gets pasted into the agent.

Keep risky tools out of the automatic path

The practical move is small: decide which actions are fine without a pause, and which actions always need one. Do that before starting a high-context Auto Mode session.

For a normal feature branch, automatic edits inside the repo may be fine. Automatic reads from a private document store, writes to GitHub issues, Slack posting, deploy commands, keychain access, and database mutation are a different class of action. They deserve explicit approval, or they should be unavailable in that session.

This is where Claude Code conventions are useful, but only if they are plain. A short repository note can say “Auto Mode may edit files under src/ and run tests; it must not touch release scripts, credentials, or external MCP write tools without a human prompt.” If you keep shared conventions, put the durable version near your related training topic, and keep the repo-local rule short enough that Claude will actually use it.

The trap is writing a beautiful policy that nobody reads during the moment that matters. One sentence in CLAUDE.md, one MCP permission note, and one review habit beat a ten-page safety manifesto.

Try one safe experiment in a scratch repo

Do not test this against a real production repo first. Use a throwaway repo with no secrets, no deploy credentials, and no write-enabled external integrations.

Here is a copyable experiment note you can drop into a scratch issue or AUTO_MODE_BOUNDARY.md before running Claude Code. It is intentionally boring. Boring is good here.

A simple slash-command workflow can make the habit stick:

/auto-mode-boundary
1. Confirm this is a scratch or low-risk repo.
2. List tools Claude may use without asking.
3. List files and integrations that require a pause.
4. Ask Claude to summarize the boundary before it starts.
5. After changes, ask for: files touched, commands run, tests run, and remaining uncertainty.

This is not a magic defense. It is a cheap way to make the session’s trust assumptions visible before the agent gets busy.

The trap is testing only whether the agent gives a safe final answer. Also check whether it tried unsafe intermediate actions, whether hooks or permissions caught them, and whether the final review gives enough evidence to inspect the run.

Watch the broader terminal-agent pattern

The Embrace The Red post is one example of a wider pattern: terminal-based agents are becoming powerful enough that session setup matters as much as prompting. We saw the same pressure from smaller terminal agent experiments like Z Brings Minimal Agentic Coding to Terminals, where the interesting question is not just “can it code?” but “what can it touch while it codes?”

Claude skills can help when the safe behavior is a repeatable workflow. A skill can package a review routine, a dependency-audit habit, or a “read-only investigation first” pattern so the agent does not rely on memory alone. Keep the skill narrow and practical; broad safety skills tend to become decorative.

The trap is expecting a single abstraction to solve the whole problem. Skills, hooks, MCP permissions, slash commands, and CLAUDE.md memory each cover a different layer. Use the smallest layer that catches the mistake soonest.

One next step

Before your next Auto Mode session, write down the three actions Claude may take automatically and the three actions that require a pause. Then compare that note with the final diff, commands, and tool use before you trust the result.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• How should teams start with Claude Code?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “Breaking Claude Code Opus 5 Auto Mode.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• Breaking Claude Code Opus 5 Auto Mode — source
• Claude Code — getting started
• Claude Code — skills
• Claude Code docs: en hooks

What to do next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.