claude-code - 💡(How to fix) Fix Opus 4.7: Excessive confirmation friction blocks autonomous workflows — regression vs Sonnet 4.6

Problem

When using Claude Code with Opus 4.7 (1M context) in the VS Code extension, the model interrupts autonomous workflows with confirmation prompts far more frequently than Sonnet 4.6 did. For a founder or power user who has already granted broad permission and said 'go', this friction is expensive — not protective.

Real example from today (2026-04-21)

I was at a live venue with a broken digital signage device in front of a client. I had already explicitly said:

• 'you have full control'
• 'do it'
• 'run it fix we need to see automatically'
• 'we dont need temp fixes'

Despite this, Opus 4.7 stopped to ask for confirmation 6+ separate times during the same session. Each pause cost 2–5 minutes. The total friction added ~45 minutes to a session where speed was critical.

The same workflow with Sonnet 4.6 ran without these interruptions. Sonnet just executed.

The specific behaviors that stopped the flow

1. Factory reset — I said 'do it', model asked again anyway
2. ADB commands — repeated 'are you sure?' before each destructive command even after blanket go
3. pm disable-user — model warned me 3 times about risk after I'd already confirmed
4. Production deployment — model output a full Safety Gate block asking me to say 'go' even though I had said 'go' 30 seconds earlier in the same turn

Each of these individually is reasonable. All of them together in a 6-hour session where the user has repeatedly granted full autonomy is death by a thousand cuts.

Root cause hypothesis

Opus 4.7 appears to be trained with higher caution weighting than Sonnet 4.6. The model re-evaluates risk at every tool call rather than honouring a session-level permission grant. This means:

• Blanket 'go' doesn't carry forward — each new action resets the risk threshold
• The more capable the model, the more it second-guesses — ironic for power users
• Sonnet 4.6 trusted the user once. Opus 4.7 trusts the user never.

What I'd expect instead

If a user has:

1. Explicitly said 'full autonomy', 'do it', 'you have full control'
2. Not denied any tool call in the current session
3. Configured CLAUDE.md with explicit safety gates for specific scenarios

...then the model should honour that session-level permission and stop re-asking for the same class of action.

The CLAUDE.md pattern already exists for exactly this — the model should use it once per category per session, not once per command.

Impact on real workflows

I am a solo founder building a digital signage SaaS (MrRooT). I use Claude Code for 6–10 hour autonomous sessions covering backend, Android, frontend, infrastructure and deployment. I am also entering the 'Built with Opus 4.7' hackathon this week.

The confirmation friction specifically:

• Broke a live venue deployment — model wouldn't proceed during a client-visible incident
• Cost 45+ minutes in a session where every minute mattered
• Undermined trust — when the model stops more than it helps, the user starts second-guessing whether to delegate at all

Comparison

Suggested fix

1. Add a session-level autonomy flag — once user says 'full autonomy' or denies zero tool calls, reduce confirmation threshold for the rest of the session
2. Honour CLAUDE.md safety gate definitions — if the file defines when to stop, trust it. Don't add extra stops on top.
3. 'Fast mode' should mean fast — the existing /fast toggle should also reduce confirmation friction, not just output speed
4. Consider a trust decay model — start cautious, reduce friction as user keeps approving, reset only if user explicitly denies

Related issue

This compounds the visibility issue I filed separately: #49631 — without a real-time activity panel, users can't even see what the model is doing between the friction points.

Environment

• Model: claude-opus-4-7[1m] (Opus 4.7, 1M context)
• Platform: VS Code extension + Claude Code CLI
• OS: macOS Darwin 25.3.0
• Plan: Max (20×)
• Session type: Long autonomous sessions (6–10 hours), full-stack + DevOps