BerriAI/litellm · error · HTTPException

Content blocked: executable code block detected (language: {

Error message

Content blocked: executable code block detected (language: {language})

What it means

The Block Code Execution guardrail found a fenced code block whose language tag matches blocked_languages (or default executable languages) at/above confidence_threshold with action=block, and rejected the content. The language tag from the fence (e.g., python, bash) is embedded in the message. Input-side blocks surface as ModifyResponseException (HTTP 200 with the block message, LLM never invoked); output-side blocks raise HTTPException 400 with detail {error, guardrail, language}.

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

Remove the offending language from blocked_languages (or set blocked_languages: null and rely on intent only) so legitimate snippets pass.
Use action: mask to replace the block with a mask placeholder instead of failing the call.
Lower/raise confidence_threshold so only high-confidence executable blocks are caught.
Client-side: catch the 400 detail.language / 200 violation message and ask the user to rephrase without the fenced block.

Example fix

# before — every python fence is rejected
litellm_params:
  guardrail: block_code_execution
  blocked_languages: [python, bash, javascript, sql]
  action: block

# after — mask python, block only shell code
litellm_params:
  guardrail: block_code_execution
  blocked_languages: [bash, sh]
  mask_languages: [python]
  action: block

Defensive patterns

Strategy: try-catch

Validate before calling

# Client-side pre-scan approximating the guardrail's fence detection
import re
FENCE = re.compile(r"```([a-zA-Z0-9_+-]*)")
BLOCKED = {"python", "py", "bash", "sh", "javascript", "js"}
def violates_code_block_policy(text: str) -> str | None:
    for m in FENCE.finditer(text):
        lang = m.group(1).lower()
        if lang in BLOCKED:
            return lang
    return None
lang = violates_code_block_policy(prompt)  # strip the fence or rephrase before sending

Try / catch

try:
    resp = litellm.completion(..., guardrails=["block-code-exec"])
except Exception as e:
    detail = getattr(e, "detail", None) or {}
    lang = detail.get("language") if isinstance(detail, dict) else None
    if lang or "executable code block detected" in str(e):
        return handle_policy_block(lang)  # user-facing message, no retry
    raise
# input-side: a 200 whose body is the violation message — detect and surface it

Prevention

Keep blocked_languages minimal — only languages your policy actually prohibits.
Use action: mask first so violations redact instead of fail.
Remember responses are always enforced regardless of intent — test both directions.
Set confidence_threshold high enough that ordinary prose in backticks is not flagged.

When it happens

Trigger: A prompt or model response contains a fenced block like ```python ... ``` where the language matches the configured blocked_languages and the classifier confidence meets confidence_threshold; for requests, execution intent must also be present when detect_execution_intent is on. Masked fences are replaced with a placeholder when effective_block is false.

Common situations: Coding assistants blocked from returning runnable Python/Bash snippets by a compliance guardrail; broad default language lists catching innocuous languages (sql, javascript); users wrapping prose in triple backticks getting flagged because a language tag matched; response-side enforcement surprising teams that only expected request scanning.

Related errors

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