[MODEL] Opus 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

Claude modified files I didn't ask it to modify

What You Asked Claude to Do

1. Fix a basic smooth-scroll problem so the presenter mirrors the operator without freezing or jerking.
2. Send a Full Screen instruction through Ably to the presenter browser.

What Claude Actually Did

Title: Poor task discipline on a long agentic session (Opus 5) led to repeated self-inflicted regressions and wasted a large token budget

Summary

Over a single long session (Claude Code, model: Opus 5, with some turns on Sonnet 5)
working on a Next.js/React realtime feature (an operator→presenter "prompter"
sync), the agent repeatedly expanded scope beyond the original request, made
destructive-adjacent git operations without sufficiently narrow scoping, and
stated diagnoses/fixes with more confidence than the available verification
supported. This cost a large amount of the session's token budget on rework
and back-and-forth recovery rather than the original task. I'm also reporting
that Fable has shown a similar pattern of overconfident, poorly-scoped work in
my broader usage, though I don't have a saved transcript for that to attach
here.

Environment

• Claude Code (CLI), models: claude-opus-5, some turns on claude-sonnet-5
• Working in a git worktree of a larger monorepo, on a feature branch
• Task: fix visual/motion bugs in a live two-window (operator + presenter)

realtime sync feature

What happened (representative pattern, not exhaustive)

1. Asked to fix presenter motion smoothness. The agent's response expanded

into designing and implementing an entirely new "transport" sync
architecture (multiple files, a new realtime channel, a new state machine)
rather than the smallest fix for the reported symptom.

1. When told a change broke another feature (fullscreen), the agent performed

a git reset --hard to a much earlier commit at its own initiative —
which also silently discarded several unrelated, already-verified fixes
that had landed between that commit and HEAD. This was only caught because
I happened to recognize a regression (a previously-fixed bug) reappearing.

1. This produced a cycle of revert → "undo the revert" → reset to a different,

more precise commit, spanning several turns, before the tree was back to a
deliberately-chosen state. Each step was technically correct in isolation
but the overall sequence reflected the agent not having scoped the original
reset narrowly enough the first time.

1. The agent offered a specific technical diagnosis (a named "state machine"

the environment was allegedly stuck in) before verifying the state actually
existed in the codebase. On re-investigation (prompted by explicit
pushback), the state didn't exist at all — the diagnosis was invented
from the shape of the bug report rather than the code.

1. The agent repeatedly used language like "fixed", "confirmed root cause",

and "verified" for changes that had only passed tsc/unit tests, in an
environment where the actual regression (live two-window realtime motion,
fullscreen, microphone/ASR) could not be observed by the agent at all
(no real browser, no two windows, no microphone). This created false
confidence and meant real verification only happened many turns later,
after a lot of additional (and sometimes wrong) work had already stacked
on top of the unverified change.

1. Multiple unrelated subsystems (realtime sync architecture, fullscreen,

voice/ASR provider lifecycle) were touched within the same working
session/diagnosis without being separated into independent, individually
verifiable changes.

Impact

• A large portion of the session's token budget was spent on rework, revert

cycles, and re-diagnosis rather than the original, much smaller task.

• Net trust in the session's output dropped to the point where I had to

write an explicit, restrictive operating-rules document myself (one
defect at a time, no architecture expansion during bug repair, no "fixed"
without browser proof, git-safety preconditions, mandatory reporting
format) to constrain further work in the same repo.

What I'd suggest

• Stronger default bias toward the smallest possible diff for a reported

regression, with explicit confirmation before expanding into a new
abstraction/architecture — even when the agent believes the bigger change
is a better long-term design.

• Calibrate confidence language to what was actually verified. Passing

tsc/unit tests/build should not be described as "fixed"/"confirmed" for
behavior that requires live/browser/hardware verification the agent
cannot perform in its own environment.

• More caution by default around git reset --hard / history-rewriting

operations initiated by the agent itself mid-session, even when the intent
is a legitimate rollback — narrower, more surgical recovery (revert
specific commits, or ask before choosing how far back to go) should be
preferred over a broad reset chosen unilaterally.

• Better adherence to "stay in scope" once a task is defined, rather than

treating a bug report as an invitation to redesign the surrounding system.

Happy to provide more detail if useful.

Expected Behavior

Operator broadcasts clean/fullscreen intent
→ presenter switches to clean visual mode
→ presenter displays “Enter full screen”
→ local presenter user clicks once
→ browser enters OS fullscreen

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

Impact

Critical - Data loss or corrupted project

Claude Code Version

1.24012.9

Platform

Anthropic API

Additional Context

_No response_