Open WebUI Code Interpreter: Setup & Security Guide

Open WebUI's code interpreter lets your AI do work, not just talk. It runs Python code the model writes, processes data, generates visualizations, and handles file operations. You choose the execution backend: Pyodide runs in the browser with zero setup; Jupyter runs on a server with full Python packages; Open Terminal gives shell-level control. Here's how to enable it, compare the options, secure it for your team, and troubleshoot when it breaks.

What Is the Code Interpreter?

Open WebUI's code interpreter is an add-on that lets the LLM write and execute code instead of just describing it. The model can load files, transform data, run calculations, create graphs, and return results inline in the chat.

Why use it? Because describing what you want is often slower than showing the model how to do it. A data analyst can ask the model to load a CSV, group by category, and generate a chart. The model writes the pandas code, runs it, and shows you the result. The model stays in context across code blocks, so it can refine the analysis iteratively.

When not to use it: If your team doesn't trust untrusted code (see Security section), or if your workload requires packages Open WebUI doesn't support. For heavy computational tasks, Jupyter with a dedicated kernel is better.

The code interpreter is per-conversation. You toggle it on in the Composer (the text input area) each time you want to use it. Not all models support it equally; Claude and GPT-4 work well; smaller models can be hit-or-miss.

The Three Execution Backends: Pyodide vs Jupyter vs Open Terminal

Open WebUI offers three execution engines. Pick one based on your use case, network isolation needs, and Python package requirements.

Pyodide (browser-based, recommended for beginners):

Pyodide runs Python inside your browser using WebAssembly. Zero server setup needed. It works offline. The LLM writes code, your browser executes it, results go back to the chat. Supported libraries include numpy, pandas, matplotlib, scipy, scikit-learn, and about 17 others. File system access is sandboxed to /mnt/uploads/, where your uploaded files live. The downside: you can't pip install new packages. If you need something not in the pre-compiled list, you're blocked.

Jupyter (server-based, full Python):

Jupyter is a notebook server that runs on your machine or a remote box. Open WebUI can point to an existing Jupyter server and use it for code execution. Full Python environment, full package support, persistence between calls. The trade-off: you need to set up and maintain Jupyter. Network setup is more complex. If your Jupyter server is on the internet, you've exposed a powerful compute resource. More on security below.

Open Terminal (modern, shell-level):

The newest backend. Gives the model shell access. Can install packages, run scripts, interact with the filesystem, call external tools. This is the "production" backend for teams. It requires careful permission management and isolation, because shell access is powerful. Official docs note this is the recommended path forward, but setup and security hardening are on you.

Decision matrix:

• Learning, demos, single-user: Pyodide
• Team analysis, persistent sessions, heavy Python: Jupyter
• Production automation, external tools, CI integration: Open Terminal

How to Enable Code Interpreter: Step-by-Step

Here's the path to turn on code interpreter:

1. Log in to Open WebUI as an admin.
2. Click Settings (gear icon, bottom left).
3. Go to Admin Settings > Code Execution.
4. Toggle "Enable Code Interpreter" to ON.
5. Choose your backend: Pyodide (default) or Jupyter. If Jupyter, paste your server URL (e.g. localhost:8888 for local, or your.server.com:8888 for remote).
6. Click Save.

Now, per conversation:

1. Open a new chat.
2. In the Composer (text input), click the Code Interpreter icon (looks like a terminal or <> symbol). It should turn blue, indicating it's active.
3. Ask the model to do something code-intensive: "Load this CSV I uploaded and show me sales by region."
4. The model writes code, executes it in your chosen backend, and returns results inline.

For more control, visit Admin Settings > Code Execution again. You can:

• Block specific Python modules (set CODE_INTERPRETER_BLOCKED_MODULES in environment variables).
• Enable "Native Tool Calling" to let models use code execution as a tool, not just on request.
• Set per-model code execution (some models only, not all).

First-time test: After enabling, ask the model to calculate 19 * 23 using Python. If it returns 437, code interpreter is working. If you're running Open WebUI locally, this setup is handled for you if you use Opsily's managed Open WebUI.

Pyodide Backend: Quick Browser-Based Setup

Pyodide is the zero-friction option. Once you enable Code Interpreter in Admin Settings, Pyodide is ready immediately.

What you can do:

• Import numpy, pandas, matplotlib, scipy, scikit-learn, and 17+ other pre-compiled libraries.
• Read uploaded files from /mnt/uploads/filename.
• Generate charts (matplotlib renders as base64 and displays inline in chat).
• Process data: filtering, grouping, aggregation.
• Export results as text.

What you cannot do:

• Install new packages (pip install won't work; packages aren't in the WebAssembly build).
• Access the host filesystem outside /mnt/uploads/.
• Run system commands (no shell).
• Interact with external databases or APIs (no outbound network in browser context).

Browser compatibility: Pyodide requires WebAssembly support (modern Chrome, Firefox, Safari, Edge). Old browsers won't work.

Example workflow:

• You upload a CSV file in Open WebUI.
• Ask: "Load this file and show me the top 5 rows."
• Model writes: import pandas as pd; df = pd.read_csv('/mnt/uploads/data.csv'); print(df.head())
• Runs in the browser, returns the dataframe head.
• Ask: "Describe the numerical columns."
• Model writes: print(df.describe())
• Runs in the same browser context (dataframe persists), returns summary stats.

Performance: Startup is ~2 seconds per model response (compilation happens once, then cached). Execution is fast for small datasets (<50MB).

When to use Pyodide: Solo analysis, demos, rapid prototyping, no external dependencies.

Jupyter Backend: Full Python Setup

Jupyter gives you the full Python toolchain. Setup is more involved, but it's worth it if your team needs production-grade code execution.

Local Jupyter setup (macOS/Linux):

1. Install Jupyter: pip install jupyter
2. Start the server: jupyter notebook --ip 127.0.0.1 --port 8888
3. Note the token in the terminal output.
4. In Open WebUI Admin Settings > Code Execution, paste your Jupyter server URL (for local setup, typically your machine address with port 8888).
5. Save and test.

Remote Jupyter (your server or cloud):

If Jupyter runs on a remote machine, pass your server's external address and port. Ensure the firewall allows access. Use SSH tunneling (ssh -L) or a reverse proxy for security.

What you can do:

• Any Python package: pip install during session.
• Persistent kernel: variables, imports, files persist across code blocks.
• External libraries: requests, boto3, psycopg2, sqlalchemy, anything on PyPI.
• File system access: read/write to the Jupyter server's filesystem.
• Multiple kernels: separate project contexts.

What you cannot do safely:

• Run untrusted code (Jupyter kernel has full filesystem access; malicious code can read/write anywhere the Jupyter process can).
• Isolate workloads (one runaway code block can freeze the kernel).

Example workflow:

• Upload a CSV.
• Ask: "Connect to our database and merge this CSV with the users table, then export."
• Model writes SQL + pandas code using sqlalchemy.
• Runs against your real database (so audit and permission it carefully).
• Returns a merged dataset.

Security note: Jupyter == trust. Only use it with models and code you trust, or isolate the Jupyter server in a container/sandbox. If you don't want to manage your own Jupyter server, hosted Open WebUI options handle infrastructure and security for your team.

Security for Teams: Sandboxing & Permissions

This section is crucial. Code execution is powerful and risky.

Browser execution (Pyodide) is NOT a security boundary:

Pyodide runs in the browser's JavaScript context. A malicious model or prompt injection can still read local storage, send keylogging events, or exfiltrate data to a third-party server. Treat browser-based code execution as semi-trusted only.

Jupyter risks:

A Jupyter kernel runs as the user who started it. If that user is root or has database credentials in environment variables, the model can access those. Malicious code can read ~/.ssh/id_rsa, modify production data, or pivot to other machines.

Permission model in Open WebUI:

• "Code Interpreter" is a group-based permission. Admins can grant it to specific user groups.
• Only users in that group can toggle Code Interpreter on in their Composer.
• Per-model, you can disable code execution: Admin Settings > Models, select a model, toggle "Enable Code Interpreter" for that model only.

Best practices:

1. Limit code interpreter to trusted groups. Not every user needs it.
2. Use module blocking for Jupyter: set CODE_INTERPRETER_BLOCKED_MODULES=subprocess,os.system to prevent shell escapes.
3. Run Jupyter in a container (Docker) with no volume mounts to the host, if possible.
4. Monitor Jupyter logs: check /var/log/jupyter for unexpected code execution.
5. For team analysis, create a dedicated Jupyter instance with read-only database credentials.
6. Never use the same Jupyter kernel for multiple untrusted sessions; spin up a new kernel per user or project.
7. If running Open Terminal, treat it like SSH access: restrict it to power users, audit heavily.

Untrusted model inputs: If you're running Open WebUI with public access or untrusted external models, disable code interpreter or restrict it to Pyodide in a fresh browser tab. Don't use Jupyter. The risk of prompt injection >> the benefit of automation.

Practical Example: Analyze CSV Data

Let's walk through a real scenario.

Setup:

• Open WebUI is running locally.
• You've enabled Code Interpreter > Pyodide (default).
• You've uploaded a file: customer_data.csv (100 rows of customer ID, region, revenue, signup_date).

Workflow:

Step 1: Load and describe

Composer: "Load customer_data.csv and describe the data."

Model: import pandas as pd; df = pd.read_csv('/mnt/uploads/customer_data.csv'); print(df.shape); print(df.head())

Result: 100 rows, 4 columns.

Step 2: Analysis (data persists)

Composer: "Group revenue by region and show totals."

Model: groupby = df.groupby('region')['revenue'].sum().sort_values(ascending=False); print(groupby)

Result: North 450K, South 320K, East 220K, West 180K.

Step 3: Visualization

Composer: "Create a bar chart."

Model: import matplotlib.pyplot as plt; fig, ax = plt.subplots(); groupby.plot(kind='bar', ax=ax); plt.show()

Result: Inline chart rendered in chat.

Key: Context persists across blocks. Pandas and matplotlib run natively in Pyodide. Results display inline.

Troubleshooting & Best Practices

Common issues and fixes:

"Analyzing..." but nothing happens:

• Check: Is Code Interpreter enabled in Admin Settings?
• Check: Is the model selected for code execution?
• Fix: Try a simpler prompt (e.g., "Calculate 2 + 2") to test the backend.

Jupyter code falls back to Pyodide:

• Most common: Jupyter server is unreachable.
• Fix: Verify the URL in Admin Settings. Test connectivity from the browser.

Code output shows base64 instead of a chart:

• Matplotlib renders as base64. Ensure your browser supports data URIs (all modern browsers do).

Models reject Code Interpreter:

• Some models don't understand tool calling. Use Claude, GPT-4, or a newer Mistral.

Best practices:

• Mention the backend in your prompt.
• Test Pyodide with simple math before complex workflows.
• Document Jupyter access and databases it touches.

Frequently Asked Questions

Can I use Code Interpreter without admin access?

Code Interpreter enabling is an admin-only setting in Open WebUI. Users can toggle it on or off per conversation only if admins have granted permission globally. Admins must enable it globally in Admin Settings > Code Execution and assign group permissions.

What Python version does Pyodide use?

Pyodide runs a Python 3.x version that depends on the Open WebUI build date. To check the exact version, users should open their browser console (Ctrl+Shift+J) and search for Pyodide version information, or consult the official Pyodide documentation.

Can I run shell commands in Pyodide?

Pyodide is Python-only and cannot run shell commands. No subprocess or os.system module is available. For shell commands and system access, users should switch to the Jupyter backend with a full Python kernel, or the Open Terminal backend for full shell control.

Does code execution work offline?

Pyodide works offline because it runs in the browser via WebAssembly. Jupyter and Open Terminal both require network access to their servers: Jupyter needs connectivity to the notebook server, and Open Terminal requires access to the shell environment.

How do I add new Python packages to Pyodide?

New packages cannot be installed in Pyodide. Packages must be pre-compiled into the Pyodide WebAssembly build before deployment. To request new libraries, users can open an issue in the Pyodide GitHub repository, or switch to the Jupyter backend for full pip install support.

Is code execution GDPR compliant?

Open WebUI is GDPR compliant, and code execution runs within the same data residency rules. Data is not sent to third parties. If Jupyter is used, the server must also be GDPR-compliant in the user's jurisdiction. Opsily support can advise on regional hosting options.

Can I restrict code execution to specific user groups?

Code Interpreter availability can be controlled per user group or per model in Admin Settings > Code Execution. This lets admins restrict access to specific teams or enable it only for trusted models. Both controls can be used together for fine-grained permission management.

The Bottom Line

Open WebUI's code interpreter bridges the gap between chat and computation. Pyodide handles simple data tasks instantly; Jupyter scales to complex analysis; Open Terminal gives you shell control. Enable it in Admin Settings, test with the three backends, and pick the one that fits your team's trust model and workload.

Security matters: browser code execution isn't a sandbox, Jupyter is as powerful as the user running it, and Open Terminal is SSH for your LLM. Use permissions wisely.

Ready to try it? Start with Opsily's demo and spin up a managed Open WebUI instance, or check managed pricing for self-hosted vs. managed.