Add Tenki sandboxes plugin for Open WebUI

[francoluxor]

What this is

open-webui-tenki is a community plugin that lets Open WebUI run code inside isolated, ephemeral Tenki microVM sandboxes — keeping arbitrary, model- or user-written code off the Open WebUI host.

It ships two entry points over one shared async execution core:

• Tool (Tenki Sandbox) — the model writes code, runs it in a fresh sandbox, reads the output (stdout, stderr, tracebacks, charts), and iterates. Fully autonomous within the model's tool loop.
• Action (Tenki Sandbox — Run Code) — a Run code button under a message that executes its code block and streams the output back inline.

How it behaves

• Isolated & ephemeral — a fresh microVM per run, always torn down; no state carried between runs; no orphaned sandboxes.
• Python and shell, with a language selector so more can be added later.
• Secure by default — network egress is off unless the operator opts in.
• Non-blocking — fully async (Tenki async SDK), bounded by a concurrency semaphore.
• Configurable through Open WebUI Valves: API key (required), endpoint, workspace/project, resources, timeout, egress, and image — plus an optional per-user key override.
• Charts — matplotlib figures are auto-captured after a run (no prompt needed) and rendered inline; images are delivered via Open WebUI's file event so they show across model types.

How it's built & distributed

The logic lives once in src/open_webui_tenki/. scripts/build.py inlines it into the two self-contained single files under open-webui/, so operators can one-click import them from the community hub with no manual dependency install. CI verifies the committed distributables stay in sync with the source.

Testing

• Unit (tests/unit) — mocked SDK, no credentials: config, rendering, teardown, timeout, truncation, credential precedence, build integrity, and both entry points.
• Live integration (tests/integration) — gated on TENKI_API_KEY; provisions real microVMs and exercises Python/shell, tracebacks, timeouts, inline image capture, guaranteed teardown (no leaks), and both the Tool and Action paths.
• Also validated end-to-end in a real Open WebUI instance (agentic Tool answer + an inline matplotlib chart via the Action).

Docs

README.md (install, configuration, security posture), TESTING.md (test layers), and CONTRIBUTING.md (dev loop, release, hub-publish steps).

Publish in the Community portal

Create a new listing (a "post") on openwebui.com for each plugin: one for the Tool, one for the Function.

1. Sign in at openwebui.com.
2. Use the create / "+" option and pick the type (Tool for tenki_code_execution.py, Function for tenki_run_code.py).
3. Paste the full contents of the built distributable into its editor. The site reads the frontmatter (title, description, version, etc.) to build the listing.
4. Publish. It becomes a browsable/searchable entry (you'll see it at a URL like openwebui.com/posts/...), and other operators can one-click import it into their instance.

Screenshots

Setup

Tool usage

Function/Actions usage

[tenki-reviewer]

Review Complete

Agent	Model
v2-correctness	deepseek-v4-pro
v2-sweep	claude-haiku-4-5
v2-domain-specialist	deepseek-v4-pro
v2-security	deepseek-v4-pro
v2-verifier	deepseek-v4-pro
v2-holistic	deepseek-v4-pro
v2-concurrency	deepseek-v4-pro
v2-triaged-orchestrator	deepseek-v4-pro
v2-triage	deepseek-v4-flash

Files Reviewed: 28
Findings: 4

By Severity:

• 🟠 High: 2
• 🟡 Medium: 1
• 🟢 Low: 1

---

4 findings in a sandboxed code execution plugin for Open WebUI: 2 high-severity security issues (markdown injection in result rendering and an uncapped result_text channel bypassing sandbox output limits), 1 medium-severity resource exhaustion vector (large image files read into memory before aggregate cap check), and 1 low-severity maintenance issue (version not covered by version consistency checks).

Files Reviewed (28 files)

.github/workflows/ci.yml
.github/workflows/release.yml
.gitignore
CONTRIBUTING.md
LICENSE
README.md
TESTING.md
open-webui/functions/tenki_run_code.py
open-webui/tools/tenki_code_execution.py
pyproject.toml
scripts/build.py
scripts/check_version.py
scripts/try_live.py
src/open_webui_tenki/__init__.py
src/open_webui_tenki/action.py
src/open_webui_tenki/config.py
src/open_webui_tenki/constants.py
src/open_webui_tenki/core.py
src/open_webui_tenki/languages.py
src/open_webui_tenki/result.py
src/open_webui_tenki/tool.py
tests/conftest.py
tests/integration/test_live.py
tests/unit/test_action.py
tests/unit/test_build.py
tests/unit/test_config_errors.py
tests/unit/test_core.py
tests/unit/test_tool.py

[tenki-reviewer]

Risk: 🟠 High (78/100) — 2 high findings, 1 medium, 1 low · 3731 LOC across 28 files

---

Overview

This PR introduces open-webui-tenki, a sandboxed code execution plugin for Open WebUI leveraging a remote microVM sandbox. The review identified 4 findings — 2 high, 1 medium, 1 low — across correctness, security, and resource-isolation dimensions.

High Severity

• Markdown injection via unsanitized sandbox output (src/open_webui_tenki/result.py:71): to_chat_markdown() wraps raw stdout/stderr/result in triple-backtick code fences without escaping backtick sequences in the output. Sandbox output containing ``` can prematurely close the fence, rendering subsequent text as live markdown in chat. A second vector exists through crafted code-fence info strings flowing through extract_last_code_block → `build_run_plan` ValueError → error rendering. This enables UI spoofing and potential phishing in the chat interface.

• Uncapped result_text bypasses max_output_bytes limit (src/open_webui_tenki/core.py:165): The Python runner writes repr() of the last expression to RESULT_FILENAME. While stdout/stderr are properly capped via _decode_capped(), result_text is read with sandbox.fs.read_text() with no size limit. A sandbox program ending in an expression with a multi-hundred-MB repr() bypasses the output-containment guarantee and can cause host memory exhaustion.

Medium Severity

• Large image files read entirely into memory before aggregate cap check (src/open_webui_tenki/core.py:78): _collect_images reads each candidate file via sandbox.fs.read_bytes() before checking the 10 MB aggregate cap. A sandboxed user can write a 500 MB .png file; the entire file loads into host memory before the cap check breaks the loop, undermining resource-isolation guarantees.

Low Severity

• __version__ not covered by version consistency checks (src/open_webui_tenki/__init__.py:23): scripts/check_version.py validates versions across pyproject.toml and the two distributable frontmatters but ignores __init__.py.__version__. CONTRIBUTING.md version-bump instructions also omit it. No code currently imports __version__, but it creates a future maintenance trap.

---

Agent	Model
v2-correctness	deepseek-v4-pro
v2-sweep	claude-haiku-4-5
v2-domain-specialist	deepseek-v4-pro
v2-security	deepseek-v4-pro
v2-verifier	deepseek-v4-pro
v2-holistic	deepseek-v4-pro
v2-concurrency	deepseek-v4-pro
v2-triaged-orchestrator	deepseek-v4-pro
v2-triage	deepseek-v4-flash