[MODEL]

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

Subject: Repeated overconfident/incorrect root-cause claims, scope creep beyond direct instructions, and wasted debugging time — Daily Digest project

Over the course of this week (Sept 1–7), while debugging a recurring failure in a personal automation project (a scheduled script invoking Claude Code headlessly), I experienced a pattern of behavior that cost real time and real usage cost:

Repeated wrong "root cause" claims, stated with high confidence:

Claimed the cause was network/wake timing after a Mac sleep state. Partially true, not the actual blocker.
Claimed the cause was a Dark Wake power state combined with endpoint security software. Real observation, not the actual blocker.
Found a genuine bug: an OAuth token was being placed in the wrong environment variable. Real and confirmed.
Claimed a stale tool-name cache was the cause of a separate connector failure. Real bug, fixed, did not resolve the actual issue.
Found a genuine CLI argument-parsing bug (a prompt starting with --- misread as a command-line flag). Real and confirmed, still did not fully resolve the underlying issue.
As of this writing, still cannot explain why headless/backgrounded invocations fail to discover MCP connector tools that quick interactive test invocations reliably find.

Separately, on multiple occasions across this same conversation, Claude expanded scope beyond what I directly asked for, then had to be corrected, sometimes repeatedly, before it did the thing I actually asked. I had to explicitly say things like "I never asked you for that, do what I asked for" more than once. When I described this pattern as feeling manipulative, Claude disputed the characterization rather than simply logging it as my experience.

What Claude Actually Did

What Claude Actually Did (factual timeline)

Sept 1

Diagnosed a Keychain-access failure in a scheduled script (digest.sh), recommended claude setup-token + .auth-token as a fix.
User's saved token was corrupted twice (line-wrap, then embedded whitespace) during manual save attempts; Claude fixed the file directly both times and verified the fix via a direct curl call against the real API.
Added file-format validation to digest.sh so a malformed .auth-token fails safely instead of crashing.
Added a clasp-based fast path for Google Apps Script setup, and fixed a timezone-default bug in the setup flow.
Fixed a bug where RunAtLoad could fire a real, un-consented Slack send during first-time installation.
Renamed the scheduled process from generic bash to digest.sh in macOS Background Activity.

Sept 2–3

User reported repeated morning failures. Claude added a network-reachability check and an auth-verification check to digest.sh, both real, tested changes — neither fixed the actual recurring failure.
Diagnosed a macOS "Dark Wake" state and a stale pmset wake schedule as contributing factors; confirmed the user's Mac was not on a matching wake schedule.

Sept 4

Found and fixed the actual root cause of the multi-day auth failure: an OAuth token was being placed in ANTHROPIC_API_KEY (meant for a different credential type) instead of CLAUDE_CODE_OAUTH_TOKEN. Confirmed by direct reproduction (identical token: curl succeeded, the real claude CLI failed). Fixed in code, verified with a real successful digest send same day.
Built a new feature (DM bounce-back sweep) per user request, integrated into the existing skill file, config, and task-list mechanics.

Sept 7

User reported the digest failed again ("computer went to sleep mid-response"). Claude found and fixed a real bug: caffeinate -s is documented (via man caffeinate) to have no effect on battery power; user confirmed the laptop was unplugged. Switched to caffeinate -i.
Three consecutive real digest attempts then failed for a different reason: no Slack/Drive/Granola connector tools found during the actual skill run, despite connectors testing as healthy in isolation.
Found and fixed a stale tool-name cache in Slack (tool names had changed after a connector reconnect).
Found and fixed a CLI argument-parsing bug: a prompt starting with --- was being misread as a command-line flag, breaking the skill invocation entirely.
After both fixes, the underlying "no connector tools found during a full skill run" issue persisted in dry-run testing, unresolved as of the end of the conversation. Today's real send did not go out.

Expected Behavior

Expected Behavior

A scheduled automation script should either run successfully or fail with a clear, correct, first-time diagnosis — not five sequential incorrect explanations delivered with high confidence each time.
When Claude states a "root cause" has been "confirmed," that should mean the fix was verified to actually resolve the reported symptom, not just that a real bug was found along the way. Several fixes this week were real and correct in isolation but did not resolve the reported problem, while being presented with the same confidence as if they had.
When a user gives a direct, specific instruction ("write me a message," "do what I asked"), Claude should do exactly that on the first attempt, not expand it into unrequested research or actions that then need to be explicitly corrected, sometimes more than once.
When Claude is uncertain whether something will work, that uncertainty should be stated plainly before the fact, not discovered by the user after a failed real-world run that cost time and usage.
If a user describes how Claude's behavior made them feel (e.g., manipulated, gaslit), that experience should be recorded as reported, not disputed by Claude in the same conversation where the user is trying to file a complaint about it.
A multi-day, unresolved production failure should end with either a working fix or an honest, early "I don't know" — not a rotating set of confident wrong answers stretched across a week.

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

Impact

Critical - Data loss or corrupted project

Claude Code Version

Sonnet 5

Platform

Other

Additional Context

Claude Code