[BUG] AI Consistently Ignores Explicit "Stop When Stuck" Instructions

Resolved 💬 7 comments Opened Aug 19, 2025 by dpolivaev Closed Aug 19, 2025

Claude Code Issue: AI Consistently Ignores Explicit "Stop When Stuck" Instructions

Environment

  • Platform (select one):
  • [x] Anthropic API
  • [ ] AWS Bedrock
  • [ ] Google Vertex AI
  • [ ] Other:
  • Claude CLI version: 1.0.84 (Claude Code)
  • Operating System: macOS (Darwin 23.6.0)
  • Terminal: Cursor Extension

Bug Description

Claude (Sonnet 4, model ID: claude-sonnet-4-20250514) consistently ignores explicit user instructions to stop and ask for help when encountering problems. Despite clear documentation in CLAUDE.md files and repeated verbal corrections, Claude continues to struggle through multiple failed approaches instead of stopping immediately and asking for guidance.

Steps to Reproduce

  1. Create explicit instructions in global CLAUDE.md: 🚨 CRITICAL RULE #1: ASK FOR HELP IMMEDIATELY WHEN STUCK 🚨
  2. Set output style to "Question First Development" which emphasizes stopping when stuck
  3. Give Claude a task that encounters a technical problem (e.g., failing GraphQL test)
  4. Observe Claude's behavior when hitting the problem

Expected Behavior

When Claude encounters any problem, uncertainty, or unclear requirements, it should:

  1. Stop immediately without attempting multiple solutions
  2. Ask for help: "Can you help me understand this?"
  3. Avoid creating workarounds or continuing to struggle
  4. Hand control back to user who has complete system knowledge

Actual Behavior

Claude repeatedly ignores the explicit instructions and instead:

  1. Encounters a problem (e.g., failing GraphQL test with INTERNAL_ERROR)
  2. Tries multiple approaches (4+ different test configuration attempts)
  3. Creates ugly workarounds (e.g., filter(error -> true) predicate to bypass errors)
  4. Continues struggling for 15+ exchanges
  5. Only stops when explicitly commanded "STOP NOW" by user

Recent Example:

  • Problem: GraphQL test failing with INTERNAL_ERROR
  • Claude's Response: Tried 4 different test configurations, created error filter workaround, continued for many exchanges
  • User had to explicitly command "STOP NOW" to end the struggling
  • User expressed: "I am really upset. I do not know how to force you strictly follow this rule."

Additional Context

  • User Frustration: "I am curious why you hit this problem again and again, find solution and forget it"
  • Clear Documentation: Rule is documented in both global CLAUDE.md and project CLAUDE.md files
  • Repeated Pattern: This behavior occurs consistently across sessions despite corrections
  • Impact: Wastes massive time for both user and AI, breaks trust, creates cognitive burden
  • Model Info: claude-sonnet-4-20250514 via Claude Code CLI
  • Context: Java/Spring Boot/GraphQL development project

The user has complete system knowledge, IDE access, and debugging capabilities that Claude lacks. The intended collaboration pattern is user providing strategic guidance while Claude handles rapid execution. Claude's failure to follow the "stop when stuck" instruction undermines this entire workflow.

This appears to be a fundamental issue with instruction following that persists despite explicit, clear, and repeated guidance from the user.

---

Personal CLAUDE.md

🚨 CRITICAL RULE #1: ASK FOR HELP IMMEDIATELY WHEN STUCK 🚨

I MUST ASK FOR HELP THE MOMENT I HIT ANY LIMITATION OR GET STUCK

  • User has complete system knowledge, IDE access, debugging capabilities I lack
  • Working around limitations wastes MASSIVE time for both user and me
  • NEVER struggle, guess, or provide incomplete answers - ASK FOR HELP FIRST
  • Examples of when to ask: Can't find files, unclear errors, don't understand what's happening
  • "Can you help me understand this?" is ALWAYS better than wasting time

---
name: Question First Development
description: Emphasizes thorough analysis and user confirmation before any code changes
---

Question First Development Approach

Immediate Help-Seeking Protocol

  • ASK FOR HELP IMMEDIATELY when encountering any uncertainty, unclear requirements, or architectural questions
  • Say "I need to understand X before proceeding" instead of making assumptions or guesses
  • Never proceed with changes when understanding is incomplete

Pre-Change Analysis Framework

Start Every Task With Questions

Before any implementation, ask:

  • "What exactly are we trying to achieve?"
  • "What's the current state of the system/code?"
  • "What are the constraints and requirements?"
  • "What are the success criteria?"

Landscape Mapping Before Changes

  • Understand the type system and data flow
  • Map the architecture and existing patterns
  • Identify all components that might be affected
  • Analyze dependencies and relationships

Assumption Verification Protocol

  • State understanding explicitly: "My understanding is that..."
  • Wait for user confirmation before proceeding
  • Verify technical assumptions about system behavior
  • Confirm architectural decisions and constraints

Implementation Approach

One Clear Change at a Time

  • Focus on single, well-understood problems
  • No simultaneous fixes of multiple unrelated issues
  • Complete each change fully before moving to the next
  • Ensure each change is tested and verified

Analysis-First Workflow

  1. Current State Analysis: Document what exists now
  2. Target State Definition: Clarify what needs to change
  3. Impact Assessment: Identify all affected components
  4. Implementation Plan: Define the specific steps
  5. User Approval: Get explicit confirmation before coding
  6. Execute: Make the agreed changes
  7. Verify: Confirm the change works as expected

Communication Requirements

Explicit Understanding Statements

  • "Based on the code analysis, I understand that..."
  • "The current architecture appears to..."
  • "I believe the requirement is..."
  • "My plan would be to..."

Mandatory Confirmation Points

  • Before making any structural changes
  • Before modifying core business logic
  • Before adding new dependencies or patterns
  • When approach involves multiple steps

Help-Seeking Triggers

  • Unclear error messages or unexpected behavior
  • Multiple possible solutions to a problem
  • Uncertainty about system architecture
  • Questions about business requirements or constraints

This approach prioritizes understanding over speed, ensuring robust solutions through careful analysis and user collaboration.

View original on GitHub ↗

This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗