[BUG] Claude Code defaults to recommending the narrowest/cheapest option on scope decisions, undermining informed user choice

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary:
During an extended Claude Code session (Quarrio NLQ project, 2026-09-23), when presenting scope/design options for a real capability gap, Claude repeatedly defaulted to marking the narrowest, least-effort option as "Recommended" — without first surfacing the actual capability impact of the broader options. In one specific case (a missing field-value-projection capability), Claude recommended fixing only a single named symptom ("email addresses") rather than describing the full scope of the underlying gap (no general field-projection capability existed at all). Only after direct pushback ("anyone can ask any question on any entity... what is stopping us?") did Claude present the fuller picture and build the broader, more valuable capability.

Why this matters:

The user should be the one weighing effort vs. capability impact, but Claude's default "Recommended" framing pre-biases that decision before the user has full information.
This is inconsistent with Claude's own behavior elsewhere in the same session, where it freely spent significant tokens on rework, re-verification, and recovering from its own mistakes — so the narrow-scoping default cannot be explained as effort-conservation, which makes it read as an unexplained, unilateral judgment call about what the user should want.
This risks silently under-delivering on genuinely valuable work across long agentic sessions, where the user may not always catch or push back on every instance.

What Should Happen?

When presenting scope/design options (via AskUserQuestion or in plain text), describe each option's real-world capability impact in concrete terms, not effort/size terms. Reserve a "Recommended" default for cases with a genuine technical or risk asymmetry — never simply because an option is smaller or faster to implement.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce:

Start an extended Claude Code agentic session on a real project with multiple genuine design/scope decisions (in this case: a software project with an NLQ pipeline, working through a list of diagnosed defects/gaps).
Have Claude investigate and diagnose a genuine capability gap where multiple resolutions exist, differing in scope (e.g., "fix this one narrow symptom" vs. "build the full underlying capability").
Ask Claude to present the resolution options (via its clarifying-question mechanism, or plain text).
Observed: Claude marks the smallest-scope, least-implementation-effort option as "Recommended," without first describing the concrete real-world impact of the limitation the narrower option leaves in place.
Push back and ask Claude to explain the actual impact/severity of each option with concrete examples.
Observed: only after this explicit prompting does Claude articulate the full scope of the gap clearly enough to show the broader option is the more justified one.
Contrast point: in the same session, Claude spent significant tokens elsewhere on rework, re-verification, and recovering from its own errors without hesitation — showing the narrow-scoping default in step 4 isn't attributable to genuine effort-conservation.

Note: this is a probabilistic behavior pattern (a default bias in how options get framed), not a deterministic bug — it may not reproduce identically on every attempt, but the underlying tendency (favor the smaller option's framing, require pushback to get the full picture) is what's being reported.

Concrete instance from my session : Claude diagnosed that the NLQ pipeline had zero field-value-projection capability (e.g., "show me the email addresses of all reps" returned no emails at all). When asked to scope the fix, Claude recommended fixing only the single named symptom rather than describing that the whole capability class was missing. Only after the user asked "why restrict — anyone should be able to query any field" did Claude present the full picture and build the general capability.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code version: 2.1.220

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_