[MODEL] Opus 4.5

Preflight Checklist

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

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

Implement a scheduling feature that respects user-configured work hours (tasks should be scheduled outside 9-5 work hours).

What Claude Actually Did

1. First attempt: Added timeConstraint: 'personal_time' to the scheduling call and claimed the task was complete
2. Did not trace through the actual code execution path
3. Missed that a cache layer returns data BEFORE the fix is reached
4. When the fix didn't work, investigation revealed the cache bypass - a second round of implementation was needed
5. This pattern repeated: surface-level fix → claim completion → user tests → doesn't work → deeper investigation

Expected Behavior

1. Trace the actual execution path a user would trigger
2. Identify bypass paths (caches, early returns, conditional logic)
3. Verify the fix is actually reached in real user scenarios
4. If uncertain, ask clarifying questions rather than optimistically claiming completion

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

1. Ask Claude to fix a bug in code that has caching or multiple execution paths
2. Claude implements a fix in one location
3. Claude claims task is complete without verifying the fix is reached
4. User tests and finds bug still exists
5. Investigation reveals cached data or early return bypassed the fix

Claude Model

Opus

Relevant Conversation

User: Tasks are still showing during work hours even though I set 9-5

Claude's first fix: Added timeConstraint: 'personal_time' to scheduling call, committed, claimed done

User: [screenshot showing tasks at 8 AM, 10:30 AM during work hours]

Investigation revealed: Cache check at line 288-293 returns cached data BEFORE the scheduling logic runs. The fix was never executed for cached dates.

Root issue: Claude found a function that LOOKED like the right place to fix, made the change, and claimed completion without tracing what actually happens when a user opens the planner.

Impact

Medium - Extra work to undo changes

Claude Code Version

2.0.45

Platform

Anthropic API

Additional Context

This pattern causes MORE token usage than asking clarifying questions upfront:

• Initial "I'm done" response
• User testing reveals failure
• Investigation to find real root cause
• Second implementation attempt
• Potentially more rounds

I have found that the same task is taking _multiple_ rounds of "Ok done!" then verification/code review ALSO claiming it is done... then when the test shows it isn't done, THEN Claude is recognizing, "Oh well I didn't really dig deep enough.", claims a fix, claims fix is verified, but it isn't fixed.

This is costing both myself and anthropic more money in token usage rather than spending the tokens upfront to be thorough or verify..