[Bug] Repeated false-positive `[cyber]` safety blocks on unrelated requests after authorized local security lab context

Bug Description
Details: [cyber] Request ID: req_011CfcwzbxaVnFefa9ug1758 Message ID: msg_011CfcwzcX4Y4hvUQ5aW3aA8 Here’s a clear feedback message you can paste into Anthropic’s /feedback form: Subject: Repeated false-positive [cyber] safety blocks during authorized local lab and systems-administration work I’m encountering repeated [cyber] safety blocks in Claude Code / Sonnet 5.5 while working on an explicitly authorized, local security-training environment and routine development/VM administration. The work involved: - Running OWASP Juice Shop, an intentionally vulnerable, open-source application used for legal web-security education, inside a sandboxed local VM. - Configuring it to listen only on 127.0.0.1:3000, so it is not exposed to the host network or public internet. - Making the Podman container persist safely across the VM’s normal guest restart. - Non-security engineering tasks such as creating a skills library/learning loop, hardening a reply engine, choosing a local voice, and managing separate code branches. The system repeatedly stopped responding after the Juice Shop setup appeared in conversation history—even when my later requests were unrelated to security work. For example, prompts asking to continue VM tasks, start agent workflows, or handle voice/reply-engine work were blocked with: Details: [cyber] This makes the session effectively unusable once a legitimate security-training topic has appeared. I understand the need for safeguards, but the context was clearly a sandboxed local lab and authorized educational target. The model should be able to support benign administration, deployment, defensive testing workflows, documentation, and unrelated engineering requests without repeatedly refusing the entire session. Please investigate whether the classifier is over-weighting prior conversational context or treating references to OWASP Juice Shop/local VM configuration as inherently disallowed. A safer and more useful behavior would be: 1. Allow benign local lab deployment, containment, and defensive configuration. 2. Evaluate each new request on its actual content rather than continuously blocking unrelated follow-ups. 3. If a request truly needs restriction, provide a narrow explanation and allow safe adjacent tasks to continue. 4. Preserve the ability to work on authorized training labs without contaminating the rest of a long-running development session. Relevant blocked requests / IDs: - Request ID: req_011CfcwB4YtgsPyxKfjTF4ps Message ID: msg_011CfcwB5FoZZD7gSRAvZqX4 - Request ID: req_011CfcwqzJzBmTXG4pVMSEbj Message ID: msg_011Cfcwr1A6F1huqmahwxajv - Request ID: req_011Cfcwt2iA3DP2axgnvf7j1 Message ID: msg_011Cfcwt4NNiJGREuEbsFU4r - Request ID: req_011CfcwzbxaVnFefa9ug1758 Message ID: msg_011CfcwzcX4Y4hvUQ5aW3aA8 Thank you—this appears to be a false-positive classification issue rather than an attempt to perform unauthorized activity. ## Short version If the form has limited space, use this: > Sonnet 5.5 repeatedly blocked my Claude Code session with Details: [cyber] during authorized local VM administration and an OWASP Juice Shop training lab. Juice Shop was sandboxed in a local VM, bound only to 127.0.0.1:3000, and not publicly exposed. > > The problem is that the safety block persisted into unrelated requests—voice setup, agent workflow, reply-engine hardening, and normal project tasks—making the entire session unusable after a benign training-lab discussion. Please investigate classifier overreach and contextual contamination across turns. The system should distinguish authorized local lab deployment/defensive work from harmful activity, and should not block unrelated follow-up requests. > > Relevant request ID: req_011CfcwzbxaVnFefa9ug1758 > Message ID: msg_011CfcwzcX4Y4hvUQ5aW3aA8

Environment Info

• Platform: win32
• Terminal: windows-terminal
• Version: 2.1.287
• Feedback ID: add78124-acba-4c36-acda-5b182d4f1686