mudler/LocalAI · error · ValueError
Inline reward function '{name}' rejected: inline reward code
Error message
Inline reward function '{name}' rejected: inline reward code executes arbitrary Python and is disabled by default. Set {ALLOW_INLINE_ENV}=true on the backend to enable it (only on a trusted, access-controlled instance), or use a builtin reward function instead. What it means
Inline reward specs execute arbitrary caller-supplied Python via exec, and the backend deliberately treats its _SAFE_BUILTINS allowlist as non-security (comments note trivial escapes via __subclasses__). Because the fine-tuning endpoint is unauthenticated by default, inline rewards are opt-in: the backend refuses them unless LOCALAI_TRL_ALLOW_INLINE_REWARD is set to a truthy value (1/true/yes/on).
Source
Thrown at backend/python/trl/reward_functions.py:242
)
func = BUILTIN_REGISTRY[name]
if params:
# Convert string params to appropriate types
typed_params = {}
for k, v in params.items():
try:
typed_params[k] = int(v)
except (ValueError, TypeError):
try:
typed_params[k] = float(v)
except (ValueError, TypeError):
typed_params[k] = v
func = functools.partial(func, **typed_params)
reward_funcs.append(func)
elif spec_type == "inline":
if not _inline_rewards_allowed():
raise ValueError(
f"Inline reward function '{name}' rejected: inline reward code "
f"executes arbitrary Python and is disabled by default. Set "
f"{ALLOW_INLINE_ENV}=true on the backend to enable it (only on a "
f"trusted, access-controlled instance), or use a builtin reward "
f"function instead."
)
code = spec.get("code", "")
if not code.strip():
raise ValueError(f"Inline reward function '{name}' has no code")
func = compile_inline_reward(name, code)
reward_funcs.append(func)
else:
raise ValueError(f"Unknown reward function type '{spec_type}'. Use 'builtin' or 'inline'")
return reward_funcs
View on GitHub (pinned to 44413a9d06)
Solutions
- If you control the instance and accept the risk, set LOCALAI_TRL_ALLOW_INLINE_REWARD=true in the backend environment and restart it.
- Prefer rewriting the reward as a builtin-type spec if the logic fits an existing registry function.
- If enabling, restrict API access (auth proxy/network policy) since the endpoint executes arbitrary Python.
Example fix
# before: inline spec, env unset # after: backend env LOCALAI_TRL_ALLOW_INLINE_REWARD=true # docker-compose / k8s env of the trl backend
Defensive patterns
Strategy: validation
Validate before calling
import os
def inline_rewards_enabled() -> bool:
return os.environ.get("LOCALAI_TRL_ALLOW_INLINE_REWARD", "").strip().lower() in ("1", "true", "yes", "on")
def spec_allowed(spec: dict) -> bool:
return spec.get("type", "builtin") != "inline" or inline_rewards_enabled() Try / catch
try:
funcs = build_reward_functions(specs)
except ValueError as e:
if "disabled by default" in str(e):
return error_response(str(e), hint="operator must opt in or use builtin")
raise Prevention
- Default to builtin specs; treat inline as an operator-only escape hatch.
- If enabling inline rewards, put auth in front of the fine-tune endpoint.
- Set the env var in the backend container spec, not the client.
When it happens
Trigger: Sending a spec with type:'inline' while the env var is unset; setting the var on the client instead of the backend process; value 'True ' with trailing content not in the accepted set (though strip().lower() handles most).
Common situations: Operators unaware inline rewards are gated; Kubernetes deployments where the env var was added to the wrong container; shared instances where enabling it intentionally requires a trusted, access-controlled environment.
Related errors
- Dataset source path is outside the allowed directory
- Output path is outside the allowed directory
- GRPO requires at least one reward function. Specify reward_f
- Syntax error in inline reward function '{name}': {e}
- Inline reward function '{name}' must return a list, got {typ
AI-assisted analysis of mudler/LocalAI@44413a9d06 (2026-08-15).
Data as JSON: /api/errors/7d5511653173d9ee.
Report an issue: GitHub.