BerriAI/litellm · error · HTTPException

Content blocked: execution request detected

Error message

Content blocked: execution request detected

What it means

The Block Code Execution guardrail detected execution intent in the scanned text (phrases like 'run this', 'execute this code' matched by the detect_execution_intent heuristics) with action=block, and blocked the call. On the input side this becomes a ModifyResponseException via raise_passthrough_exception, so the client gets an HTTP 200 whose body carries the violation message and the LLM is never called; on the output side (post-call hook) it is an HTTPException with status 400 and detail containing the guardrail name and language='execution_request'.

Source

Thrown at litellm/proxy/guardrails/guardrail_hooks/block_code_execution/block_code_execution.py:495

                should_raise = True
            parts.append(text[last_end:start])
            if effective_block:
                parts.append(self.MASK_PLACEHOLDER)
            else:
                parts.append(text[start:end])
            last_end = end

        parts.append(text[last_end:])
        new_text: Final = "".join(parts)
        return new_text, should_raise

    def _raise_block_error(self, language: str, is_output: bool, request_data: dict) -> None:
        if language == "execution_request":
            msg = "Content blocked: execution request detected"
        else:
            msg = f"Content blocked: executable code block detected (language: {language})"
        if is_output:
            raise HTTPException(
                status_code=400,
                detail={
                    "error": msg,
                    "guardrail": self.guardrail_name,
                    "language": language,
                },
            )
        self.raise_passthrough_exception(
            violation_message=msg,
            request_data=request_data,
            detection_info={"language": language},
        )

    @log_guardrail_information
    async def apply_guardrail(
        self,
        inputs: GenericGuardrailAPIInputs,
        request_data: dict,

View on GitHub (pinned to 77b7c6c40c)

Solutions

  1. If execution requests should be allowed, set detect_execution_intent: false in the guardrail litellm_params so only fenced code blocks are considered.
  2. Switch action: block to action: mask to redact the offending block/intent instead of rejecting the call.
  3. If blocking is intended but you want a cleaner client experience, handle the 200-block / 400 response in your client (inspect the violation message) rather than treating it as an outage.
  4. Tune blocked_languages / confidence_threshold so only the languages you actually prohibit are matched.

Example fix

# before — blocks any request that looks like it wants code executed
litellm_params:
  guardrail: block_code_execution
  action: block
  detect_execution_intent: true

# after — only mask fenced code blocks, never reject on intent
litellm_params:
  guardrail: block_code_execution
  action: mask
  detect_execution_intent: false
Defensive patterns

Strategy: try-catch

Validate before calling

# No server-side pre-check exists; approximate client-side before sending
import re
EXECUTION_INTENT = re.compile(r"\b(run|execute|eval)\s+(this|the)\s+(code|script|program)\b", re.I)
def likely_execution_request(text: str) -> bool:
    return bool(EXECUTION_INTENT.search(text))
if likely_execution_request(user_prompt) and guardrail_blocks_intent:
    prompt = prompt.replace("run this", "show this")  # or warn user

Try / catch

from litellm.exceptions import HTTPException as LiteHTTPException
try:
    resp = litellm.completion(..., guardrails=["block-code-exec"])
except LiteHTTPException as e:  # output-side block: HTTP 400
    if "execution request detected" in str(e.detail if hasattr(e, "detail") else e):
        return friendly_block_message(e)
    raise
# input-side block: HTTP 200 whose content is the violation message — check for it
if "Content blocked: execution request detected" in resp_content:
    return friendly_block_message(None)

Prevention

When it happens

Trigger: A user prompt containing execution-intent phrases (and no conflicting no-execution phrases) while the guardrail is configured with action: block (the default) and detect_execution_intent enabled — the block fires even without a fenced code block when intent alone is detected. Also fires for tool outputs/responses when the model text matches intent patterns and is_output=True.

Common situations: Coding-assistant deployments where users legitimately ask to run code ('please execute this script') get blocked by default settings; teams enabling the guardrail without realizing detect_execution_intent blocks intent, not just code; output-side blocks surprising users because responses are always enforced regardless of intent.

Related errors

AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18). Data as JSON: /api/errors/887805edce52c534. Report an issue: GitHub.