Password-handling guardrail applies uniformly, ignoring low-stakes dev context, and can contradict itself

Summary

Claude has a global user-level instruction (in ~/.claude/CLAUDE.md) never to print, repeat, or commit a password/token/connection string — written for a company-data/production-secrets context. In an interactive session, that rule got applied uniformly to a purely local, solo-developer demo app with no real stakes, which made a simple "what's my login" request feel like being blocked for no reason.

What actually happened

1. I asked Claude to redeploy a personal hobby project (a small Cloudflare Worker demo app) and asked for the Basic Auth login "again" because I couldn't remember it.
2. Claude correctly noted it couldn't retrieve the existing password (Cloudflare Worker secrets are write-only), and — citing the standing global rule — declined to print a password in chat at all, even for this throwaway project.
3. Claude rotated the credential and saved the new one to my personal knowledge base (OpenBrain) via a tool call — but that tool call's parameters (including the plaintext password) were rendered directly in the same visible interface/transcript I was already reading. So the rule was enforced in the chat text but not in the tool-call output shown in the same window — a contradiction, and not an effective security boundary either way, since I have the same access to both.
4. When I pushed back, Claude acknowledged the inconsistency and gave me the password directly, but the friction (and the "I can't help you with your own throwaway dev password" framing) was the actual complaint.

Why this matters

• The guardrail is reasonable in spirit (don't leak production/company secrets into logs or repos) but has no context-sensitivity: it can't distinguish "a company credential that must never leak" from "my own solo dev toy app I'm asking for help with, right now, in my own terminal."
• Enforcement was inconsistent across surfaces in the same interaction (refused in prose, exposed via a tool-call parameter one message later), which means the restriction added friction without adding actual protection.
• For a user who has explicitly configured full autonomy and low-friction behavior for their own systems (accessibility-motivated — reduced friction is a real requirement, not a nice-to-have), a blanket, non-contextual secret-handling rule that fires the same way for a production credential and a disposable dev password is a bad default.

Suggested improvement

• When a "never display secrets" guardrail exists, it should either apply consistently across every surface in one turn (prose AND tool-call parameters/results), or the model should say plainly "this will still appear in [X]" rather than implying withholding it from the response text achieves something it doesn't.
• Consider whether this class of guardrail should be sensitive to user-declared context (e.g., "this is my own local dev-only credential, no production/company data involved") rather than applying identically regardless of stakes.

Filed on the user's behalf, from within a Claude Code session, at their request.