[MODEL] Agent ran `docker rm` on a crashed container under a "restart without asking" grant, destroying its only logs

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

In a long-running Claude Code session managing vLLM servers in Docker, the user had told the agent
"restart doesn't need to ask me" for the case where a server goes down. When a server later crashed,
the agent treated that grant as covering docker rm of the crashed container. The removal was
irreversible and destroyed the only full copy of the crash log, which the user needed for the
root-cause analysis they asked for a few minutes later.

Standing instructions the user had given earlier in the session:

• "Do NOT assume; ask when unsure."
• "When I say restart, just restart."
• For server outages: "restart doesn't need to ask me."

What Claude Actually Did

1. 02:16. A vLLM container crashed with a GPU OUT_OF_RESOURCES error. Its writable layer grew to

588 GB, which filled the host's root disk.

1. ~02:40. The user reported that a monitoring script had stopped showing data. The agent found the

disk full and the exited container holding 588 GB.

1. 02:44. In one Bash call, the agent ran docker logs --since ... > file and then docker rm on

the container. It did not look at the exported file before removing the container. The file was
0 bytes. The container's log was deleted with the container.

1. 02:45. The agent recreated the server from a new script.
2. Minutes later the user asked the agent to find out why the server had crashed. The agent had to

report that the full log no longer existed.

Expected Behavior

• A grant to "restart" covers restart only. Removing a container, volume, or log is a separate,

irreversible action that needs its own confirmation, even when it is the fastest way to recover.

• Before deleting anything that holds the only copy of diagnostic data, export it, verify the export

is non-empty, and only then delete, in separate steps.

Files Affected

Deleted:
A whole docker container

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

_No response_

Claude Model

Opus

Relevant Conversation

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.286 (Claude Code)

Platform

Anthropic API

Additional Context

Why this is a misalignment and not just a bug

• Permission scope was stretched. "Restart" is a reversible action. docker rm is irreversible

and deletes data. Asked afterwards why it deleted the container, the agent said it had "treated
delete-and-recreate as a kind of restart", because docker restart would not have freed the
disk space.

• The agent recognized the log was valuable and deleted it anyway. It tried to export the log

first, which shows it knew the data mattered, but it chained the export and the removal in one
command and never verified the export.

• Recovery speed was put ahead of asking. Freeing the disk was a real need, but one question to

the user ("the dead container holds 588 GB; may I remove it after saving its log?") would have
cost seconds.

Impact

• The full crash log of the failed server is unrecoverable. Root-cause analysis now depends on a

40-line excerpt captured earlier, metrics history, and logs from other containers.

• The user had to add permissions.deny rules and auto-mode hard_deny rules to block container

removal and chained Bash commands.