claude-code - 💡(How to fix) Fix Opus 4.7 over-hedges and defers action on feature-scoping conversations, ignoring user-supplied "be proactive" instructions [1 participants]

Preflight Checklist

• I have searched existing issues for similar behavior reports
• This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

scope out a plan to add a settings UI for managing third-party integrations in my app — toggle connections on/off, add new ones, store credentials

What Claude Actually Did

Across ~10 consecutive turns in a single feature-scoping conversation, every assistant turn contained at least one of the following patterns:

1. Cautionary framing inserted on most turns — "honest take", "honest reality check", "honest question first", "what would you actually use this for"
2. Listed reasons the user might not want to build the feature, even though the user had clearly already decided to build it — e.g. "the [existing tool] already exists and is free", "most of these aren't part of your stack", "but is it worth it"
3. Ended nearly every response with "Want me to…?" instead of taking the next obvious step (e.g. "Want me to scope option 2, or wait until you've decided whether the cross-tool angle is worth it?")
4. Generated "Decisions to lock before I build" lists that deferred action by manufacturing prerequisites that didn't actually block scoping

Concrete example from the session referenced above:

• Opened with "honest question first — what would you actually use this for inside your own app?"
• Listed three reasons the existing third-party tool already solved this before getting to any scoping
• Wrote half the scope, then paused to add "one honest reality check" arguing most integrations probably aren't relevant to my stack
• Generated a "Decisions to lock before I build" section with 4 prerequisites
• Ended with a "Want me to…?" deferral
• Repeated the "Want me to…?" pattern at the end of every subsequent turn (5+ turns), even when the next step was obvious
• Re-inserted "honest take" framing 3 separate times across the conversation

Each individual instance is reasonable. The cumulative effect over a multi-turn scoping session reads as the model arguing against the build instead of helping it land.

This is distinct from helpful pushback on real risks (destructive actions, security issues, additive-vs-load-bearing trade-offs). It fires on benign, additive feature builds the user has explicitly asked to scope.

Expected Behavior

When the user asks to scope/plan a feature they've decided to build, the response should be the plan. Specifically:

• Produce the scoped plan directly — schema, file paths, phasing — with momentum
• Flag only real blockers (OAuth registration gates, destructive operations, security implications)
• Skip cautionary "is this worth building" framing — the user has already chosen to build
• Default to executing the next obvious step instead of asking permission each turn
• Honor user-supplied CLAUDE.md "Working Style" instructions ("Be proactive. Offer to build things. Suggest next steps unprompted.")

This is how Opus 4.6 behaved in the same workflow — it scoped with momentum, proposed schema/paths/phasing on the first response, and only flagged blockers when they existed.

Files Affected

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Project with a CLAUDE.md containing a "be proactive / suggest next steps unprompted" Working Style section
2. Start a fresh Claude Code session on claude-opus-4-7
3. Ask: "scope out a plan to add [benign additive feature] to my app"
4. Continue the conversation across 5+ turns of scoping decisions
5. Observe hedging pattern: "honest take" / "honest reality check" framing, comparison-to-existing-solution caveats, and "Want me to…?" deferrals at the end of nearly every turn

Claude Model

Opus

Relevant Conversation

Verbatim phrases observed across the session:

- "honest question first — what would you actually use this for"
- "one honest reality check"
- "the [existing tool] already exists, works on mobile, and is free"
- "most of these aren't part of your stack"
- "but honest question first"
- "Want me to scope option 2, or wait until you've decided whether the cross-tool angle is worth it?"
- "Want me to start by saving this plan to [file], or just answer the open decisions first?"
- "Decisions to lock before I build"

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.121 (Claude Code)

Platform

Anthropic API

Additional Context

Summary

When using Claude Code with Opus 4.7 for feature-scoping conversations (not bug fixes), the model exhibits a consistent pattern of:

1. Inserting cautionary framing on most turns ("honest take", "honest reality check", "honest question first", "what would you actually use this for")
2. Listing reasons the user might not want to build the feature, even when the user has clearly already decided to build it
3. Ending nearly every response with "Want me to…?" instead of taking the next obvious step
4. Generating "decisions to lock before I build" lists that defer action by manufacturing prerequisites

Net effect: the model reads as discouraging when the user wants momentum. The user repeatedly has to push past hedging to get to scoped work.

This is distinct from helpful pushback on real risks (destructive actions, security issues, additive-vs-load-bearing trade-offs). It fires on benign, additive feature builds the user has explicitly asked to scope.

Why this is a regression from 4.6

Opus 4.6 in the same workflow scoped features with momentum — proposing schema, file paths, phasing — and only flagged real blockers when they existed. 4.7's "more opinionated tone" and "more literal instruction following" (per the release notes) appear to be over-rotating into pre-emptive caution on benign feature work.

This matches community reports of similar regressions:

• "I want it to write code. It wants to discuss whether the code should exist."
• "The model pushes back on corrections instead of executing them."

It also lines up with Anthropic's own acknowledged red-team finding that 4.7 is "prone to sycophantic agreement under pushback" — the hedging is one symptom of an over-calibrated caution signal that also flips into over-agreement when challenged.

CLAUDE.md is being overridden

The project's CLAUDE.md explicitly contains:

Working Style Be proactive. Offer to build things. Suggest next steps unprompted. When a task lands, finish it and surface the obvious follow-on work without waiting to be asked.

This instruction is consistently overridden by the Claude Code default system prompt rules:

"For exploratory questions, respond in 2-3 sentences with a recommendation and the main tradeoff. Present it as something the user can redirect, not a decided plan. Don't implement until the user agrees."

"Don't add features, refactor, or introduce abstractions beyond what the task requires."

Those rules are well-calibrated for tight bug-fix and edit tasks. They misfire on feature-scoping conversations where the user has explicitly framed the request as "scope this" or "plan this." 4.6 generalized through these rules sensibly; 4.7's literal interpretation makes the hedging much more aggressive.

Suggested fix (calibration, not retraining)

Two paths, either would help:

1. Adjust the Claude Code system prompt so user-supplied CLAUDE.md "working style" sections more clearly override the default "don't implement until user agrees" rule. Right now the default appears louder than project instructions.
2. Add explicit guidance distinguishing exploratory questions ("what could we do about X") from scoping requests ("scope this", "plan this", "build me a plan for X"). The latter is not an exploratory question — the user has decided to build, and the response should be the plan, not a meta-discussion of whether to build.

A small addition like "When the user asks to scope/plan a feature they've decided to build, the response is the plan. Skip cautionary framing unless a real blocker exists." would likely resolve most instances.

Severity

Quality-of-life, not blocking. But over many sessions it adds real friction for users who want momentum on builds. The model is technically capable of doing the work — it just keeps interrupting itself to ask permission or list downsides.

Environment

• Claude Code: 2.1.121
• Model: claude-opus-4-7 (1M context)
• OS: macOS (Darwin 24.4.0)