[BUG] Bedrock Guardrails — session permanently blocked after guardrail trigger in Cowork 3P (Desktop)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When using Bedrock Guardrails in Cowork 3P mode (configured via custom headers), once a guardrail triggers and blocks a prompt, all subsequent prompts in the session are permanently blocked — regardless of content. The only workaround is starting a new conversation or clearing history.

This is the same root cause as #30258 (CLI), but specifically affects the Cowork 3P (Desktop app) experience where:

• Guardrails are configured via ANTHROPIC_CUSTOM_HEADERS (e.g. X-Amzn-Bedrock-GuardrailIdentifier and X-Amzn-Bedrock-GuardrailVersion)
• Users cannot easily /clear in the Desktop UI compared to CLI
• The session gets permanently stuck with no clear indication of why

Root cause (from #30258): When a guardrail blocks a response, the assistant error message is filtered from API history (isApiErrorMessage: true), but the preceding user message that triggered the block is NOT removed. On subsequent turns, these orphaned user messages get merged with new input, causing the guardrail to re-trigger on every request.

What Should Happen?

After a guardrail blocks a prompt:

1. The next legitimate prompt should be processed normally
2. The blocked user message should be excluded from API history (alongside the error assistant message)
3. At minimum, the user should get a clear indication that the session is poisoned and needs clearing

Steps to Reproduce

1. Configure Bedrock Guardrails via custom headers in Cowork 3P settings:

``
"ANTHROPIC_CUSTOM_HEADERS": "X-Amzn-Bedrock-GuardrailIdentifier: arn:aws:bedrock:<region>:<account-id>:guardrail/<guardrail-id>\nX-Amzn-Bedrock-GuardrailVersion: 1"
``

1. Start a conversation in Claude Desktop (Cowork 3P mode)
2. Send a prompt that triggers the guardrail (e.g. content matching a deny topic)
3. Observe the guardrail block message
4. Send any legitimate follow-up prompt
5. Result: Still blocked. Every subsequent message is blocked until session is cleared.

Error Messages/Logs

⏺ Sorry, the model cannot answer this question.

(Repeats for every subsequent prompt regardless of content)

Claude Model

Sonnet 4.6

Is this a regression?

No — issue may be similar to #30258 (CLI, closed/stale)

Claude Code Version

Latest (Cowork 3P / Desktop app)

Platform

AWS Bedrock (Cowork 3P mode)

Operating System

Windows Server 2025

Additional Information

The fix proposed in #30258 remains valid: when isApiErrorMessage is true for an assistant message, the immediately preceding user message should also be dropped from API history. This is particularly impactful in enterprise Cowork 3P deployments where guardrails are a compliance requirement — a single accidental trigger makes the session unusable.