Claude suggests global `docker network prune -f` as "safe" — wipes networks across unrelated projects

What happened

While helping a user resolve a single-project Docker Compose subnet collision, Claude (Opus 4.7) suggested this command and annotated it as 可選、安全 (optional, safe) in Traditional Chinese:

docker network prune -f     # 順便清 orphan networks（可選、安全）

The user ran it. It silently removed every unused network across the entire Docker daemon, including networks belonging to other unrelated projects on the same machine (green-trade, inte-green-vibe, etc.). The user has multiple side projects colocated on one Mac; those projects' networks are now gone and must be rebuilt via docker-compose up per project.

No data loss (volumes are untouched), but the blast radius crossed project / trust boundaries, and the (可選、安全) annotation actively misled the user.

Why this is a problem

docker network prune -f without filters is a global daemon operation — indistinguishable from docker system prune in scope for networks. It is never safe to suggest as an off-hand cleanup step when the user's expressed intent is narrower (fixing one project).

This violates the "blast radius" rule in Claude Code's own system prompt, which specifically lists destructive operations that need user confirmation, but does not currently enumerate docker *prune variants among the dangerous ones in the default guidance.

Reproduction

1. User asks Claude to fix a Docker Compose network-pool collision for a single project
2. Claude suggests docker-compose down for the project (correct), then adds docker network prune -f with a \"safe\" / \"optional\" annotation
3. User runs the chain — all other projects' networks removed

Requested improvement

Treat these as restricted by default, refuse or require explicit scope-confirmed user approval before suggesting:

• docker system prune[ -a][ --volumes]
• docker network prune (without --filter)
• docker volume prune (without --filter)
• docker container prune (without --filter)
• docker image prune -a

Suggested safer alternatives Claude should default to:

• docker-compose -p <project> down [-v]
• docker network rm <specific-network-name>
• docker network inspect to identify the specific conflicting network before removal

The heuristic: never suggest daemon-wide cleanup when the user's goal is project-scoped. If daemon-wide cleanup is actually desired, require the user to explicitly say so first.

Meta

This is reported as feedback per the user's explicit request after the incident. Happy to share more of the conversation if useful.