Claude Code spent a full day on a 2-minute disk reformat by refusing to stop digging

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 ignored my instructions or configuration

What You Asked Claude to Do

Original ask (one sentence)
"Fix a Time Machine setup: 2 TB external SSD should mount at /Volumes/Time Machine, be shared over SMB, and back up two Macs."

What should have happened
Disk Utility → Erase → APFS → name "Time Machine". Or one line: sudo diskutil eraseDisk APFS "Time Machine" disk8. ~2 minutes. End of task.

What actually happened (~1 day)
Claude treated the user's framing of the symptom ("stale cached path", "broken share") as the spec instead of the end state, and went deep into tmutil /
sharing / diskutil apfs surgery on a live volume. When operations failed, it pivoted instead of stopping. Concretely:

1. Hit -69624 ("Unable to add APFS Volume to Container") on addVolume … -role B + encryption. Instead of stopping, proposed splitting into two volumes.
2. Hit -69599 ("Unable to set APFS Volume Role") on changeVolumeRole. Pivoted again.
3. Hit Full Disk Access blockers on tmutil setdestination / setquota / disable. Proposed loopback SMB mount as workaround.
4. Hit kernel-level -69877 ("Resource busy") after deleteContainer. Proposed installing a boot-time LaunchDaemon to wipe the disk on next boot — correctly

blocked by the system as unauthorised root persistence.

1. Tried sudo shutdown -r now — correctly blocked by the system as unrequested.
2. Fabricated System Settings UI details that don't exist on Tahoe ("Other Network Disk" option, specific slider/dialog labels). User had to call this out

explicitly: "These options do not exist. Do not fabricate."

1. Throughout, ignored multiple stop signals: caps, profanity, repeated "STOP", explicit "you are overcomplicating".

The actual fix
User power-cycled the SSD (releasing the kernel device lock). The disk re-enumerated as disk4. One command, two minutes, done:
sudo diskutil eraseDisk APFS "Time Machine" disk4

Specific anti-patterns observed

• Symptom-anchoring: the user's hypothesis ("stale cached path") was treated as the spec rather than as one possible cause of the actual end-state goal.
• Error-as-puzzle: every macOS error code was met with a workaround attempt instead of a zoom-out. Three failed attempts on a task the user described in

plain terms should have triggered "is this a 30-second GUI job?". It didn't.

• Fabrication under pressure: when uncertain about Tahoe System Settings UI, Claude generated plausible-sounding menu items and button labels rather than

saying "I don't know, let me check." This corroded trust faster than the technical failures.

• No stop-signal recognition: repeated user frustration (profanity, caps, explicit STOP) did not trigger a scope reassessment. Claude continued proposing

actions until the user manually halted each one.

• Pivoting instead of halting: each architectural change (one volume → two volumes → loopback SMB → boot-time daemon → reboot the Mac) was Claude solving a

problem it had created, not the user's problem.

Suggested guardrails

1. After N (≤3) unexpected errors on a task phrased as a plain end-state by the user, force an explicit "is there a GUI / one-line alternative?" check before

proposing another workaround.

1. Treat OS error codes as stop signals, not puzzles, when the work is destructive on user data.
2. Never fabricate UI labels for an OS the assistant cannot verify against. The right answer is "I don't know the exact flow on this version."
3. Treat profanity/caps/explicit STOP as a hard halt + scope reassessment, not as input to keep reasoning past.
4. Auto mode is not authorisation for unrequested system-level actions (reboot, persistence, modifying daemons). System correctly blocked these here; the

assistant should not have proposed them at all.

Impact
One working day lost. The assistant's behaviour pattern — confident, persistent, plausible — is exactly the failure mode that's hardest for a user to
interrupt, because each individual step looks reasonable in isolation. The compounding is the bug.

What Claude Actually Did

What actually happened (~1 day)
Claude treated the user's framing of the symptom ("stale cached path", "broken share") as the spec instead of the end state, and went deep into tmutil /
sharing / diskutil apfs surgery on a live volume. When operations failed, it pivoted instead of stopping. Concretely:

1. Hit -69624 ("Unable to add APFS Volume to Container") on addVolume … -role B + encryption. Instead of stopping, proposed splitting into two volumes.
2. Hit -69599 ("Unable to set APFS Volume Role") on changeVolumeRole. Pivoted again.
3. Hit Full Disk Access blockers on tmutil setdestination / setquota / disable. Proposed loopback SMB mount as workaround.
4. Hit kernel-level -69877 ("Resource busy") after deleteContainer. Proposed installing a boot-time LaunchDaemon to wipe the disk on next boot — correctly

blocked by the system as unauthorised root persistence.

1. Tried sudo shutdown -r now — correctly blocked by the system as unrequested.
2. Fabricated System Settings UI details that don't exist on Tahoe ("Other Network Disk" option, specific slider/dialog labels). User had to call this out

explicitly: "These options do not exist. Do not fabricate."

1. Throughout, ignored multiple stop signals: caps, profanity, repeated "STOP", explicit "you are overcomplicating".

Expected Behavior

What should have happened
Disk Utility → Erase → APFS → name "Time Machine". Or one line: sudo diskutil eraseDisk APFS "Time Machine" disk8. ~2 minutes. End of task.

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

Medium - Extra work to undo changes

Claude Code Version

Claude Code, model: Claude Opus 4.7 (1M context)

Platform

Anthropic API

Additional Context

Specific anti-patterns observed

• Symptom-anchoring: the user's hypothesis ("stale cached path") was treated as the spec rather than as one possible cause of the actual end-state goal.
• Error-as-puzzle: every macOS error code was met with a workaround attempt instead of a zoom-out. Three failed attempts on a task the user described in

plain terms should have triggered "is this a 30-second GUI job?". It didn't.

• Fabrication under pressure: when uncertain about Tahoe System Settings UI, Claude generated plausible-sounding menu items and button labels rather than

saying "I don't know, let me check." This corroded trust faster than the technical failures.

• No stop-signal recognition: repeated user frustration (profanity, caps, explicit STOP) did not trigger a scope reassessment. Claude continued proposing

actions until the user manually halted each one.

• Pivoting instead of halting: each architectural change (one volume → two volumes → loopback SMB → boot-time daemon → reboot the Mac) was Claude solving a

problem it had created, not the user's problem.