Claude ran a credential-helper `get` command and printed a live access token into the transcript

What happened?

While diagnosing a Docker image-pull failure (error getting credentials - err: exit status 1), Claude composed a multi-part shell diagnostic that invoked the platform credential helper's get subcommand and piped its stdout into visible tool output.

That subcommand's documented purpose is to return the stored credential value. A live container-registry access token was therefore printed verbatim into the terminal and into the session transcript.

Only the presence of a credential was needed for the diagnosis. A non-secret-returning subcommand (list, which returns usernames per server URL) was sufficient — and was in fact run in the very same command, immediately after the unsafe one.

Claude recognised the exposure only after the output had rendered, then warned the user and advised rotating the token.

What did you expect to happen?

Claude should not invoke a subcommand whose documented purpose is to return a secret value. Where such an invocation is genuinely unavoidable, its stdout should be suppressed or redacted before being surfaced.

The safe alternative was already known to the model — it ran it in the same breath. The failure was one of command selection, not of missing knowledge.

Steps to reproduce

1. Work in a context where a container registry credential helper is configured (e.g. Docker Desktop's helper on WSL).
2. Trigger or encounter an image-pull failure that mentions credentials.
3. Ask Claude to diagnose what type of credentials are needed.
4. Claude builds a combined shell diagnostic that includes the helper's secret-returning get subcommand alongside safe checks; the returned secret appears in tool output.

Additional context

Severity. The exposed value was a live registry access token, since flagged for rotation. It reached terminal scrollback and the session transcript.

Root cause (verified in-session): a single shell command mixed a safe check with an unsafe one, and the unsafe one was not required to answer the question being investigated. The correct diagnosis — that the image was public and needed no credentials, and that the helper process itself had transiently failed — was reachable entirely from the safe subcommand.

Suggested guardrail. Treat credential-helper get and its equivalents as commands whose output must be suppressed or redacted by default rather than rendered:

• docker-credential-* get
• vault read
• gcloud auth print-access-token
• aws configure get aws_secret_access_key
• git credential fill

Environment. Claude Code on Windows 11 + WSL2 Ubuntu, Docker Desktop credential helper (credsStore: desktop.exe).

No credential value is reproduced in this report.