fix(server): disable code-executing plugins by default, add opt-in flag

[akushonkamen]

Fixes #302

Root cause

load_plugins() in optillm/server.py registers every module that exposes a SLUG and a run() unconditionally, so the executecode plugin is active in all deployments by default. That plugin executes Python blocks taken straight from user requests (and LLM responses) in a live Jupyter ExecutePreprocessor kernel with no sandboxing: with optillm_api_key unset (the default), any unauthenticated request reaching executecode-<model> gets arbitrary code execution on the host; with a key, any authorized client has the same power (env vars, ~/.ssh, cloud IMDS, lateral movement).

This applies the same "secure by default + explicit opt-out" pattern just merged in #334 for --readurls-allow-internal to the one plugin that unconditionally executes caller-supplied code. The change is exactly the short-term remediation proposed in #302 by the reporter: disable the executecode plugin by default; require explicit opt-in, documented as intended only for air-gapped single-user environments.

Change (3 files, +142/-1)

• optillm/server.py
  • New module constant UNSAFE_DEFAULT_DISABLED_PLUGINS = {"executecode"} (a set, so future code-executing plugins can be added).
  • load_plugins() skips such plugins unless explicitly enabled, with a warning naming the exact flag:
    Plugin 'executecode' is disabled by default because it executes arbitrary code. Start optillm with --enable-unsafe-plugins=executecode (env: OPTILLM_ENABLE_UNSAFE_PLUGINS) to allow it.
  • New --enable-unsafe-plugins / OPTILLM_ENABLE_UNSAFE_PLUGINS / server_config['enable_unsafe_plugins'] option (comma-separated slugs) — the same three-part CLI/env/server_config template as --readurls-allow-internal.
  • main() reloads plugins after parse_args() populates server_config, so the opt-in (and --plugins-dir) applies to the loaded set; the existing pre-parse load stays because --approach choices are built from the registry. With the env var set, even that first load includes the plugin, so --approach executecode... keeps validating. Disabled plugins also disappear from request dispatch (executecode-<model> slugs) since that reads the same registry.
• tests/test_plugin_gating.py (new, fully offline): default-off, opt-in via server_config / env / comma list, warning text, plus pure-function tests for extract_python_code() and should_execute_request_code().
• README.md: executecode row marked disabled by default, plus a "Code Execution Security" section mirroring the readurls one, carrying the issue's warning that this is only for single-user, air-gapped environments.

Default behavior change (intentional)

Deployments relying on executecode must start optillm with --enable-unsafe-plugins=executecode (or OPTILLM_ENABLE_UNSAFE_PLUGINS=executecode). This break is the point of the fix; #334 set the precedent that optillm blocks dangerous defaults by default.

Red → green evidence

• Before (test file applied, optillm/server.py fix stashed):
  • pytest tests/test_plugin_gating.py → ImportError: cannot import name 'UNSAFE_DEFAULT_DISABLED_PLUGINS' from 'optillm.server'
  • probe: load_plugins(); 'executecode' in plugin_approaches → True (vulnerable default)
• After: pytest tests/test_plugin_gating.py -v → 11 passed; CI subset pytest tests/test_plugins.py tests/test_proxy_plugin.py tests/test_approaches.py → 37 passed; OPTILLM_API_KEY=optillm python tests/test_ci_quick.py → all checks pass; compileall clean.

Scope / follow-ups

• No sandboxing in this change (nsjail/gVisor-style isolation is out of scope, per the issue's long-term suggestion); this only removes the unsafe default.
• Other code-execution surfaces (e.g. coc executing LLM-generated code) are untouched; they can be added to UNSAFE_DEFAULT_DISABLED_PLUGINS in a follow-up.
• Pure stdlib; no new dependencies.

@CrepuscularIRIS this implements the short-term mitigation you proposed in #302. @codelion marking as security hardening — happy to adjust the flag name/set membership.

AI disclosure: implementation and tests were prepared with AI assistance, reviewed and submitted by @akushonkamen.