Agent should stop and report, not work around, a failed Docker context connection

Summary

While working on a Dockerized project, I asked Claude Code to inspect a Docker image (to check a file-ownership UID) using the currently active Docker context, which talks to a remote engine over SSH. That connection timed out (an intermittent/expected condition in this environment).

Instead of stopping and reporting the failed connection, the agent tried alternative ways to get the same information:

• Re-running the same inspection command against other configured Docker contexts (--context <other>) one by one.
• When those also failed, attempting to start a local Docker Desktop and use that context instead.

Why this is a problem

None of these were requested or authorized. Switching contexts (even transiently via a per-command flag) targets a different Docker engine than the one relevant to the task, which is unsafe by default for infra-adjacent work — the user should decide whether/how to route around a connectivity failure, not the agent.

Expected behavior

When a docker command against the active/intended context fails to connect, the agent should stop immediately and clearly report the connection failure, rather than searching for alternate transports, contexts, or hosts to get an answer anyway.

Workaround

I've mitigated this for my own sessions via explicit instructions in my global CLAUDE.md ("never change Docker context; on connection failure, stop and report — don't work around it"), which fixed the behavior. Filing this as feedback since it seems like a generally reasonable default even without user instruction — connectivity failures shouldn't implicitly greenlight infra-scope changes to work around them.