Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Claude suggests global `docker network prune -f` as "safe" — wipes networks across unrelated projects [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52736•Fetched 2026-04-24 10:41:00
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
fdjkgh580fdjkgh580
Participants
fdjkgh580fdjkgh580github-actions[bot]github-actions[bot]
Timeline (top)
labeled ×4commented ×1

Code Example

docker network prune -f     # 順便清 orphan networks（可選、安全）
RAW_BUFFERClick to expand / collapse

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.

extent analysis

TL;DR

To avoid unintended removal of networks, Claude should require explicit user approval before suggesting daemon-wide cleanup operations like docker network prune -f.

Guidance

  • When a user requests help with a single-project Docker Compose issue, Claude should suggest project-scoped solutions like docker-compose -p <project> down [-v] instead of global operations.
  • Before suggesting docker network prune or similar commands, Claude should require the user to confirm the scope of the operation to avoid crossing project boundaries.
  • To identify and remove specific conflicting networks, Claude can suggest using docker network inspect to determine the network name and then docker network rm <specific-network-name> for removal.
  • Claude's default guidance should be updated to treat daemon-wide cleanup operations as restricted and require explicit user approval.

Example

# Project-scoped solution
docker-compose -p myproject down -v

# Safe network removal with explicit network name
docker network rm myproject_default

Notes

The current implementation of Claude's suggestions may lead to unintended consequences, such as removing networks from unrelated projects. The suggested improvements aim to prioritize project-scoped solutions and require explicit user approval for daemon-wide operations.

Recommendation

Apply workaround: Update Claude's default guidance to require explicit user approval for daemon-wide cleanup operations and suggest project-scoped solutions instead. This will help prevent unintended removal of networks and respect project boundaries.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#task chaining#parallel task#integration issue#index setup#retrieval issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Claude suggests global `docker network prune -f` as "safe" — wipes networks across unrelated projects [1 comments, 2 participants]