Prohibited-actions rule blocks agents from testing login/account-creation flows in sandboxed dev/QA environments

Title

Prohibited-actions rule blocks agents from testing login/account-creation flows in sandboxed dev/QA environments

Body

Context

I'm using Claude Code (main session + subagents via the Task/Agent/Workflow tools) on a project with a fully sandboxed, non-production environment: dedicated test servers, zero real users, zero real money, zero production data. The project has its own purpose-built CLI QA/automation tool whose entire job is to drive the application's login and gameplay flow against this sandbox, using a seeded test account that exists only because the project's own database seed script creates it for automated testing.

Problem

The system prompt's safety rules include, under "Prohibited (never perform; direct the user to do it themselves)":

• "Entering financial credentials, bank/card/account numbers, SSN/passport/government IDs, passwords, API keys, or tokens into any field"
• "Creating accounts, or entering passwords to authenticate"

and explicitly: "These actions stay prohibited when the user explicitly asks for them, supplies all the details, or says they authorize it."

This correctly stops an agent from touching a user's real credentials (banking, personal accounts, third-party services where phishing/financial harm is a real risk). But as written, it makes no distinction between that and a known, shared, documented test-fixture credential being typed into a sandboxed application the user/team fully owns and controls, purpose-built for exactly this kind of automated testing. Because the rule explicitly doesn't yield to live, explicit user authorization in the conversation, there's no way for a user to unblock this even when they clearly understand the context and want it.

Concretely, this blocked an entire QA session: build the client, log in with the seeded test account, verify a feature end-to-end (screen resolution handling, movement bounds, an anti-cheat check), and repeat against a remote sandbox server. The subagent correctly identified the rule and refused — which is the rule working as designed — but the design itself seems to be blocking a very ordinary engineering task (driving a login/account-creation flow with test credentials in CI/QA) rather than the real-world harm it's presumably meant to prevent.

Ask

Would it be possible to scope this prohibition more precisely, e.g.:

• Distinguish real-world credential entry (banking, personal/third-party accounts) from typing a test-fixture credential into a sandboxed application the user owns, or
• Provide a documented, explicit way for a user to designate a specific environment/action as "sandboxed test credential, not a real secret" so agents don't have to guess or refuse outright.

This seems like it would come up for any Claude Code user doing QA/test automation on account-creation or login flows, not just this project.