[MODEL] Circular testing and wasting time

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

Claude modified files I didn't ask it to modify

What You Asked Claude to Do

Title: Claude Opus 4.5 exhibits circular reasoning, excessive trial-and-error, and inability to form systematic debugging plans

Description:

Over two consecutive sessions (Feb 3-4, 2026), Claude Code (Opus 4.5) performed poorly on implementation and debugging tasks for
a React Native/Firebase project. The issues fall into several categories:

1. Circular Code Changes (Web Push Notifications — Both Days)

Claude repeatedly rewrote the same code back and forth between contradictory approaches without clear reasoning for why each new
approach would succeed where the previous one failed:

• Switched between using Firebase's getMessaging() and disabling it — multiple times
• Switched between finding Firebase's service worker and registering our own — multiple times
• Switched between self-generated VAPID keys and Firebase's registered keys
• Switched between Firebase's scoped service worker (/firebase-cloud-messaging-push-scope) and root scope (/)
• Each reversal contradicted explicit "CRITICAL RULES" that Claude itself had written in previous iterations (e.g., "MUST call

getMessaging()" → later disabled it, "Do NOT register our own SW" → later registered our own SW)

The user was asked to test each variation manually in the browser (clear cache, hard refresh, check console output, report back).
Over two days, this resulted in 12+ test cycles, all producing the same outcome: FCM returns 201 but never delivers. Claude
should have recognized the pattern much earlier and stopped guessing.

1. Inability to Form a Systematic Debugging Plan

Rather than methodically isolating variables, Claude took a "shotgun" approach — changing multiple things at once, then when it
didn't work, changing different things. There was no structured elimination process. Key failures:

• Never clearly articulated what hypothesis each change was testing
• Never established success/failure criteria before asking the user to test
• Failed to recognize that FCM returning 201 without delivery was consistent across ALL approaches, suggesting the problem was

outside the code entirely

• Kept proposing code changes when the evidence pointed to an infrastructure/platform issue
• The user had to explicitly say "Do not guess at re-writing code again. Review completely how the one message got sent through

and stick with that plan" — Claude should not need this instruction

1. Mulligan System Implementation Issues (Feb 3)

The mulligan feature (allowing users to save their exercise streak after missing a day) required multiple rounds of fixes:

• Implementation had logical errors that Claude introduced and then had to fix
• The user experienced repeated test-fix-test cycles
• Claude acknowledged the implementation was problematic

1. Making the User the Test Runner

Claude cannot run a browser or interact with web services that require authentication. However, rather than acknowledging this
limitation upfront and planning around it, Claude repeatedly:

• Made speculative code changes
• Deployed them
• Asked the user to clear cache, refresh, check console output, and report back
• Received "no, that didn't work"
• Made another speculative change and repeated

This happened 12+ times across the two days for web push alone. A better approach would have been to exhaust all code-side
analysis first, clearly state the limitation, and present options — rather than using the user as a human test harness for
guesses.

1. Contradicting Its Own Documentation

Claude maintained a CLAUDE.md file with learnings. Multiple times, it wrote rules like "Do NOT disable getMessaging()" or "Push
events ONLY arrive at Firebase's scope" — then in the next iteration, did exactly what it documented as wrong. When context
compacted between sessions, some of these learnings were lost and Claude repeated failed approaches.

1. Failure to Recognize Browser

The push subscription endpoint was consistently https://fcm.googleapis.com/fcm/send/... (Google's FCM), which definitively
indicates Chrome/Chromium. The user stated they were using Safari. Claude did not flag this discrepancy early — it's relevant
because Safari uses Apple's push service (APNs), not FCM, and the entire debugging approach depends on which push service is in
use.

Environment

• Claude Code CLI with Opus 4.5 (claude-opus-4-5-20251101)
• macOS, React Native / Expo / Firebase project
• Two sessions, both hit context auto-compaction due to length

Expected Behavior

• Form a hypothesis, state it clearly, test it once, evaluate
• Recognize patterns (12 consecutive failures with the same symptom = stop changing code)
• Acknowledge limitations early ("I cannot debug FCM's internal delivery pipeline")
• Minimize user testing cycles by exhausting code-side analysis first
• Never contradict its own documented learnings without explicitly explaining why

What Claude Actually Did

Read the above.

Expected Behavior

See above.

Files Affected

All files

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

See above

Claude Model

Sonnet

Relevant Conversation

Too long.  This was multiple days of back and forth.

Impact

High - Significant unwanted changes

Claude Code Version

Claude Opus 4.5

Platform

Anthropic API

Additional Context

_No response_