Claude Opus 4.7: six migration tips before retuning everything

Opus 4.7 shipped today. Six things worth absorbing before we reopen Claude Code on any serious project tonight, tested across two production codebases in the first hours of the release. Not benchmarks. The first hour of 4.7, in practice.

Outline

Each feature below follows the same shape: what actually changed in 4.7, what we must be aware of before opening the next session, and how to tweak it to a specific project.

• Retuning prompts for literal-instruction following.
  • What changed: 4.7 interprets instructions literally where 4.6 silently filled in the gaps.
  • What to watch: loose phrases in CLAUDE.md or saved commands now trigger overscoped or destructive tool calls.
  • How to tweak: rewrite every instruction with three parts. Scope (named files and functions). Acceptance criteria (tests pass, no lint errors). Forbidden side effects (no rename, no reformat, no package.json edits).
• Auditing the allowlist with /less-permission-prompts.
  • What changed: a new skill ships with zero docs, scans .claude/projects/**/*.jsonl transcripts, and proposes a project-specific allowlist ranked by real usage.
  • What to watch: the skill refuses interpreters, package managers, and mutation commands even when we called them 300 times. Allowlists are per-project, never shared across repos.
  • How to tweak: run the skill on day one of every new project. Keep the refusals as-is. Adjust only after a week of seeing what the classifier would otherwise block.
• Picking a default between xhigh and lower effort levels.
  • What changed: Claude Code silently raised its default to xhigh for every plan. On 4.6 the default was high.
  • What to watch: xhigh stacks with the tokeniser bump (1.0 to 1.35x more tokens) and later-turn thinking amplification. The bill shifts without a single prompt change.
  • How to tweak: keep xhigh for multi-file refactors, concurrency debugging, and anything inside auto mode. Drop to /effort high or /effort medium for lint fixes, formatting passes, doc generation, and CI scripts. Put the override at the top of task-specific CLAUDE.md files.
• Toggling auto mode with the Mutation Barrier framework.
  • What changed: auto mode arrived on Max. A Sonnet 4.6 classifier reads every tool call and decides in two stages whether the action goes through.
  • What to watch: broad allowlist rules (interpreters, blanket shell, package managers) get purged on toggle. Mutation rules (git push, rm) and network rules (curl, ssh) survive only when narrow.
  • How to tweak: let Anthropic handle Category 1 (arbitrary code execution). Write Category 2 (mutations) and Category 3 (network) rules narrowly, e.g. curl https://api.mydomain.com/* instead of curl *. Every rule should feel a little uncomfortable.
• Using /ultrareview on release-day pull requests.
  • What changed: a new slash command spawns parallel cloud reviewers (correctness, security, design, test coverage) and reconciles the findings. Pro and Max get three free runs with 4.7.
  • What to watch: local /review greenlights a prompt migration PR while missing the behavioural landmines that literal-instruction following exposes.
  • How to tweak: spend the three free runs on prompt migrations, skill updates, agent team config changes, and CI pipeline updates that touch Claude Code. Treat the rest as billable and be tactical.
• Knowing the migration gotchas nobody is writing down.
  • What changed: tokeniser now maps the same input to 1.0 to 1.35x more tokens. Settings live per-project, not globally. Auto mode works on Bedrock, Vertex, and Foundry from day one. New cyber safeguards block unverified pentest prompts.
  • What to watch: the first few hours feel expensive because the first few hours are expensive. Security workflows that ran fine on 4.6 start getting denied.
  • How to tweak: monitor usage over a week before rewriting any workflow. Run /less-permission-prompts on every new codebase. Enrol in the Cyber Verification Programme for legitimate pentest or red-team work.

Prerequisites, Libraries and setup

• Claude Code CLI on the latest build (16 April 2026 changelog or later).
• A Pro, Max, Team, or Enterprise plan. Auto mode lands on Max today. /ultrareview quotas vary by plan.
• At least one existing project with a CLAUDE.md, saved slash commands in .claude/commands/, or custom skills written against 4.6.
• A rough sense of our current usage numbers before upgrading, so we can tell signal from noise during the first week.

1. Retune prompts before anything else

Open Claude Code on any project today and a fifth option shows up in the /permissions menu. Auto mode. Shift+Tab cycles through it. The badge at the bottom of the window changes. That is the most visible piece of the release and also the least interesting one, because auto mode landed on Team plan three weeks ago and its mechanics are already documented.

The actually-disruptive change is quieter. Opus 4.7 takes instructions literally now. The 4.6 tolerance that covered for loose prompts is gone. Every "clean up X", "refactor Y", "fix the bug" sitting in a CLAUDE.md or a saved command is a loaded gun pointing at our own work. The 4.7 migration guide warns about this in one sentence that nobody quoted in their release-day tweet: prompts written for earlier models can sometimes now produce unexpected results, where previous models interpreted instructions loosely or skipped parts entirely, Opus 4.7 takes the instructions literally.

On 4.6, "clean up the test directory" was interpreted as "delete files named test_scratch_*.py and stale fixtures". On 4.7 it becomes "delete everything in /test because the user said clean up". Not scope escalation. Literalism. The cleanup was asked for. Cleanup is what landed. The silent constraints in our mental model never translated into a tool call.

So every CLAUDE.md in the repo needs a pass before the first session runs. Every saved prompt in .claude/commands/. Every custom skill written assuming 4.6 would fill in the blanks. The re-tune is a discipline, not a template. Every instruction needs three things before it ends:

• The scope: which files, which functions, named explicitly.
• The acceptance criteria: tests passing, no linter errors, existing behaviour unchanged.
• The forbidden side effects: do not touch package.json, do not rename variables, do not reformat.

Three answers, one prompt, every time. On 4.6 that was a nice-to-have because the model tolerated ambiguity. On 4.7 it is the minimum viable instruction format.

Retune first. Toggle anything else after.

2. Audit the allowlist with /less-permission-prompts

Claude Code shipped a skill today called /less-permission-prompts. Changelog entry, one line, zero ceremony. It scans the .claude/projects/**/*.jsonl transcripts in the current project, aggregates tool-call patterns, and proposes an allowlist ranked by frequency, with explicit rejections for anything that is not read-only.

Running it on a content-tooling project (heavy on custom MCPs plus GitHub issue tracking plus Slack threads) against the 50 most recent transcripts produced 14 patterns for .claude/settings.local.json. The allowlist went from 24 entries to 38. The breakdown matters:

• Four custom MCP tools called constantly for content ops (get_post_overview, get_maillage_candidates, list_product_ideas, find_youtube_outliers).
• Nine GitHub MCP read-only tools (get_file_contents, search_code, get_me, search_users, search_repositories, search_issues, list_issues, list_pull_requests, list_commits).
• One Slack MCP tool (slack_read_thread).

What the skill did not suggest, and why that is interesting: zero bash commands. Not because bash is unused. git status, git log, git diff, ls, cat, grep, find, lsof, ps, du are called a hundred times a day. They are already auto-allowed by the Claude Code baseline. The skill refuses to duplicate the built-in safelist.

The explicit rejections matter too: node, npx, python3, bun, curl, git add, git commit, git push, rm, mkdir, ssh, gh api. The skill will not allowlist these even when they show up 300 times in the transcripts.

Running the same skill on a second project (e-commerce automation, browser driving, scraping partner dashboards, inventory sync) produced six patterns: four browser MCPs (find, read_page, tabs_context_mcp, read_network_requests) and two custom content-query MCPs reused from the first project's infra. Zero overlap with the first scan.

Two scans, twenty lines, zero overlap. That is the baseline.

Someone will post a gist on X titled "The Ultimate Claude Code 4.7 Allowlist" and it will hit 2k likes by tonight. What usually goes into those is node **, npx * yes *, python3 *, bun run *, blanket rm and git push because "trust me bro it works". About 90 percent of those lines get auto-purged when auto mode is toggled (more on that in Tip 4). A 50-line paste where 45 lines vanish silently is not a baseline, it is a false sense of safety.

Allowlists are project-specific. The settings file lives in .claude/settings.local.json, per-project, not shared. Running /less-permission-prompts on day one of a new project is now a setup step, like .gitignore or .editorconfig.

3. Understand xhigh and pick a default

Anthropic added a new effort level called xhigh, sitting between high and max. Claude Code raised its default to xhigh for all plans. On 4.6 the default was high. Every session opened from today runs at xhigh unless overridden.

xhigh means more thinking, more output tokens, more latency. Combined with one sentence from the 4.7 migration guide (Opus 4.7 thinks more at higher effort levels, particularly on later turns in agentic settings), the maths gets loud.

Three multipliers stack on top of each other. The tokeniser now maps the same input to 1.0 to 1.35x more tokens depending on content type. xhigh spends more thinking tokens by default. Later turns in the same agentic session amplify that. Nothing changed in our prompts, the bill shifted on its own.

Override where the task does not need the horsepower. xhigh is the right call for multi-file refactors, debugging concurrency bugs, research-style exploration, and anything running inside auto mode. It is overkill for lint fixes, formatting passes, doc generation, CI scripts, and most tasks under ten tool calls.

/effort high     # override the xhigh default per session
/effort medium   # cheaper, fine for lint fixes and formatting
/effort auto     # reset to the model default

Put the override at the top of task-specific CLAUDE.md files for recurring workflows that do not need the deep think.

New default equals new budget.

4. Toggle auto mode with the Mutation Barrier in mind

Auto mode arrived on Max. It has been live on Team and Enterprise since 25 March. What shows up in the /permissions menu today is the same feature those plans had for three weeks, with three weeks of edge cases already hit by the Team users.

The mechanics in one paragraph: Sonnet 4.6 runs as a silent classifier, reads every tool call (minus Claude's reasoning and tool outputs, stripped for prompt-injection resistance), and decides in two stages whether the action goes through. 17 percent false-negative rate on real overeager actions. 0.4 percent false-positive rate on real traffic. Three consecutive denials, or 20 total, and the session escalates.

The detail nobody is explaining correctly this morning is buried in the Anthropic engineering post: on entering auto mode, we drop permission rules that are known to grant arbitrary code execution, including blanket shell access, wildcarded script interpreters (python, node, ruby, and similar), and package manager run commands.

The allowlist does not bypass the classifier. Broad rules get purged at toggle time. Narrow rules survive. This inverts the intuition built on 4.6. Here is the framework we have been using internally. Call it the Mutation Barrier. Three categories, different responsibilities:

Category 1. Arbitrary code execution

Interpreters, package managers, blanket shell. Anthropic drops these on entry whether anyone wants it or not. If python3 ** was allowlisted, the classifier now sees every python3 command. No work on our side, no warning either.

Category 2. Mutations

git add, git push, rm, mkdir, MCP create/update/delete. These SURVIVE into auto mode if allowlisted narrowly. A broad git push entry hands back the blast radius the classifier was built to protect. The correct move is to let the classifier see every mutation.

Category 3. Network

curl, ssh, gh api, infisical run. Same rule as Category 2. curl https://api.mydomain.com/* can survive. curl * should not survive, and should not be written.

Every rule in Category 2 or 3 should feel a little uncomfortable. If it does not, it is too broad. There is a reason CLIs work better than opaque MCP wrappers here. When the command being audited is literally the command being executed, a narrow allowlist is possible. MCP wrappers hide the surface area and make narrow allowlists impossible to reason about.

Narrow or nothing.

5. Use /ultrareview for release-day PRs

Once the allowlist is tuned and auto mode is cautiously toggled, the last shipped-today lever worth spending time on is code review. Pro and Max get three free /ultrareview runs with 4.7. It runs a comprehensive code review in the cloud using parallel multi-agent analysis and critique. Called with no arguments it reviews the current branch. With a PR number it fetches and reviews a specific GitHub pull request.

/ultrareview           # review the current branch
/ultrareview 427       # review GitHub PR #427

The difference from the existing /review is non-trivial. /review runs locally in the current session at the current effort level. /ultrareview spawns parallel reviewers in Anthropic-managed cloud, each with a different angle (correctness, security, design, test coverage), then reconciles the findings. Same model class, more eyes, no local latency.

The release-day use case is specific. A PR that retunes ten prompts in CLAUDE.md, updates the skill library for 4.7 literal-instruction handling, and bumps effort defaults deserves more than a syntactic check. /review will say the Markdown looks fine. /ultrareview catches behavioural landmines that do not surface as syntax: a retuned prompt that still carries a 4.6-era implicit assumption, an MCP call that assumes error handling the classifier will not allow, a skill that references a local file path.

Use the three free runs on the PRs where breakage costs most. Prompt migrations. Skill migrations. Agent team config changes. CI pipeline updates that touch Claude Code. After those three, they are billable against usage. Be tactical.

6. Know the migration gotchas

Four things worth catching before the tab closes and the toggle happens:

• Tokeniser maths. The same input maps to 1.0 to 1.35x more tokens on 4.7. Not a line of code changed, the bill shifted. Monitor usage over a week before concluding the workflow is broken. The first few hours of 4.7 feel expensive because the first few hours of 4.7 are expensive. Watch the trend across a week before reacting.
• Settings file is per-project. .claude/settings.local.json lives in the project root. Not in ~/.claude. Not shared. Every new codebase starts with an empty allowlist. Running /less-permission-prompts on day one of a new project is now a setup step.
• Auto mode works on Bedrock, Vertex, and Foundry. A few "Bedrock not supported" claims are already on X this morning from people who did not check. Opus 4.7 shipped across Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry from day one. A cloud-locked shop is fine.
• Cyber safeguards may block pentest prompts. Opus 4.7 ships with automatic safeguards that detect and block requests flagged as prohibited or high-risk cybersecurity uses. For legitimate vulnerability research, penetration testing, or red-teaming, Anthropic rolled out a Cyber Verification Programme that needs enrolment before those prompts go through. Security workflows that ran on 4.6 without friction will see denials today. That is not auto mode misfiring. It is the new safeguards doing their job.

None of those are scary. They catch anyone who upgraded before reading.

Conclusion

Opus 4.7 is a release-day migration, not just a model bump. Reach for this guidance when a project has a CLAUDE.md, saved commands, or skills written against 4.6, and especially when auto mode is about to get toggled for the first time. The model is stronger on every benchmark Anthropic cares about, and a vague prompt still produces vague output, except now 4.7 executes it literally, the tokeniser charges more for it, and xhigh spends more thinking tokens chewing through it. Watch the usage trend over the first week before rewriting any workflow in anger. Next problem to solve: keeping the retuned prompts under version control so the discipline survives the second migration.

Resources

1. Claude Opus 4.7 announcement and migration guide
2. Anthropic engineering post on Claude Code auto mode (25 March 2026)
3. Claude Code changelog (16 April 2026)