AI Gateway guardrails with Block action continue blocking for remainder of Claude session after first trigger

[zjacobson1016]

Summary

When AI Gateway input or output guardrails are configured with Block action, a single trigger appears to put the session into a persistent blocked state. Subsequent requests in the same Claude Code session continue to be blocked even when the new prompt/content would not violate the guardrail.

Expected behavior

After a guardrail blocks one request, the user should be able to send a new, compliant prompt in the same session and have it processed normally (unless that new prompt also violates the guardrail).

Actual behavior

1. User runs a prompt that triggers an input or output guardrail with Block action (e.g. guardrail databricks_demo on dogfood)
2. Request is correctly blocked with a guardrail error
3. User sends a new, unrelated prompt that should pass the guardrail
4. Request is still blocked — the session remains in a blocked state for the remainder of the Claude Code session

Observed error examples:

Request blocked by input guardrail 'databricks_demo'

Output guardrail 'databricks_demo' failed to evaluate: ... messages.0: user messages must have non-empty content

The output guardrail failure can also occur on tool-only assistant turns (empty text content), which may contribute to the session getting stuck.

Reproduction

1. Configure ucode claude against a Databricks workspace with AI Gateway guardrails enabled (input and/or output phase, Block action)
2. Launch Claude via ucode claude (required for MCP OAuth token)
3. Send a prompt that triggers the guardrail (e.g. content related to MCP/GitHub tooling on dogfood with databricks_demo)
4. Observe block response
5. Send a benign prompt (e.g. "What is 2+2?")
6. Observe that the request is still blocked or fails with guardrail errors

Workarounds attempted

• Switching models (e.g. Opus → Sonnet) — partial relief for output guardrail evaluation errors, but session blocking may persist
• Changing guardrail to Log mode — avoids blocking but does not fix Block-mode session stickiness
• Starting a new Claude session — appears to reset state

Impact

Makes Block-mode guardrails unusable for interactive coding sessions via ucode claude, since one false positive or tool-only turn can brick the entire session.

Environment

• ucode claude routing through Databricks AI Gateway
• Workspace: e2-dogfood.staging.cloud.databricks.com (also observed on other workspaces)
• Guardrail: databricks_demo (input and output phases)
• Claude Code launched via ucode claude

Suggested investigation

• Whether guardrail block state is cached per session/conversation ID and not cleared between turns
• Whether empty assistant content on MCP tool-call turns causes output guardrail evaluation failures that latch as permanent blocks
• Whether guardrail evaluation should be per-request rather than per-session