[GH-ISSUE #22225] feat: Hardware-isolated code execution backend via exec-sandbox (QEMU microVMs) #106664

New Issue

Closed

opened 2026-05-18 05:07:42 -05:00 by GiteaMirror · 1 comment

GiteaMirror commented 2026-05-18 05:07:42 -05:00

Owner

Copy Link

Originally created by @clemlesne on GitHub (Mar 4, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22225

TL;DR

exec-sandbox runs untrusted code inside ephemeral QEMU microVMs with hardware virtualization (KVM/HVF). It supports Python 3.14, JS/TS (Bun), and Shell, with 1-2ms warm-pool latency, streaming I/O, and 9 layers of isolation -- no privileged containers needed. It can be installed today as a zero-core-change Workspace Tool (pip install exec-sandbox), or later wired in as a native CODE_EXECUTION_ENGINE backend.

Disclosure: I am the author/maintainer of exec-sandbox.

Check Existing Issues

• I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

• I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

Open WebUI's code execution today offers three backends, each with meaningful trade-offs for multi-user and self-hosted deployments:

Backend	Isolation	Multi-user safe	Languages	Persistent packages	Server-side
Pyodide (default)	Browser sandbox (WASM)	Yes	Python only (subset)	No	No
Jupyter	None (shared kernel)	No -- docs warn against it	Python only	Yes	Yes
Open Terminal	Docker container	Partial	Any	Yes	Yes

The gap: There is no built-in backend that simultaneously provides (a) strong security isolation suitable for multi-tenant deployments, (b) server-side execution with full language support (Python, JS, shell), and (c) zero shared state between users/executions.

The community has recognized this. Discussion #19050 requests sandbox functionality as a core built-in, extending beyond the current Pyodide/Jupyter capabilities. Issue #9614 tracks code interpreter enhancements and has "external sandboxing" checked off on its roadmap (likely referencing the safe-code-execution plugin); exec-sandbox offers an alternative approach with hardware VM isolation instead of userspace kernel sandboxing. Issue #18224 highlighted the inadequacy of documentation around the RCE surface when workspace tools run via exec() on the server -- reinforcing why sandboxed execution matters.

The community safe-code-execution plugin by EtiennePerot addresses this with gVisor, but it requires Linux-only gVisor, relaxed seccomp profiles (seccomp=unconfined), AppArmor disabled, and writable cgroupfs -- constraints that can be difficult to meet in production container orchestration environments and are unavailable on macOS for local development.

Desired Solution you'd like

Add exec-sandbox (PyPI) as an additional code execution backend option, alongside the existing Pyodide, Jupyter, and Open Terminal backends.

What exec-sandbox provides:

• Runs untrusted code inside dedicated QEMU microVMs with hardware virtualization (KVM on Linux, HVF on macOS)
• Each execution gets a fresh VM -- destroyed immediately after. No state leakage between users or executions
• 9 layers of security isolation: hardware VM, custom hardened kernel (~360 subsystems stripped), EROFS read-only rootfs, unprivileged QEMU, non-root REPL, seccomp, cgroups v2, namespaces, socket authentication
• Supports Python 3.14, JavaScript/TypeScript (Bun 1.3), and Shell (Bash)
• 1-2ms warm pool latency, ~100ms from memory snapshot, ~400ms cold boot
• Streaming stdout/stderr, file I/O (upload/download), session support (stateful multi-step execution)
• Network disabled by default, optional domain allowlisting with DNS + TLS SNI filtering
• Works on macOS (HVF) and Linux (KVM) -- developers can test locally on Mac
• Self-hosted, no cloud dependency, Apache-2.0 license
• pip install exec-sandbox -- single dependency, assets auto-download on first use

How this compares to existing options:

	exec-sandbox	gVisor (safe-code-execution)	Pyodide	Jupyter
Isolation level	Hardware VM (KVM/HVF)	Userspace kernel	Browser WASM	None
macOS support	Yes (HVF)	No (Linux only)	Yes (browser)	Yes
Languages	Python, JS/TS, Shell	Python, Bash	Python (subset)	Python
Privileged container needed	No	Yes (seccomp=unconfined, no AppArmor)	N/A	N/A
Fresh per execution	Yes	Yes	Yes	No (shared)
Streaming output	Yes	Yes	No	Partial
File I/O	Yes	Limited	No	Yes
Package install	Yes (cached)	Yes	Limited (WASM)	Yes
Multi-user safe	Yes	Yes	Yes	No

Integration as an Open WebUI Workspace Tool:

The most natural integration point is as a Workspace Tool, matching the pattern established by EtiennePerot's safe-code-execution plugin. This requires zero changes to Open WebUI core. Here is a working implementation sketch:

"""
title: exec-sandbox Code Execution
author: dualeai
description: Run Python, JavaScript, and Shell code in hardware-isolated QEMU microVMs
version: 0.1.0
license: Apache-2.0
requirements: exec-sandbox>=0.18.0
required_python: >=3.12
"""

import asyncio
import json
from typing import Callable

from pydantic import BaseModel, Field


class Tools:
    class Valves(BaseModel):
        WARM_POOL_SIZE: int = Field(
            default=1,
            description="Number of pre-started VMs per language (0 to disable warm pool)",
        )
        DEFAULT_MEMORY_MB: int = Field(
            default=256,
            description="Memory per VM in MB",
        )
        MAX_RUNTIME_SECONDS: int = Field(
            default=30,
            description="Maximum execution time in seconds",
        )
        NETWORKING_ALLOWED: bool = Field(
            default=False,
            description="Allow sandboxed code to access the network",
        )
        ALLOWED_DOMAINS: str = Field(
            default="",
            description="Comma-separated domain allowlist (only used when networking is enabled)",
        )

    def __init__(self):
        self.valves = self.Valves()
        self._scheduler = None
        self._lock = asyncio.Lock()

    async def _get_scheduler(self):
        """Lazy-initialize the Scheduler singleton (shared across tool invocations)."""
        if self._scheduler is None:
            async with self._lock:
                if self._scheduler is None:
                    from exec_sandbox import Scheduler, SchedulerConfig

                    config = SchedulerConfig(
                        warm_pool_size=self.valves.WARM_POOL_SIZE,
                        default_memory_mb=self.valves.DEFAULT_MEMORY_MB,
                        default_timeout_seconds=self.valves.MAX_RUNTIME_SECONDS,
                    )
                    self._scheduler = Scheduler(config)
                    await self._scheduler.__aenter__()
        return self._scheduler

    async def run_python_code(
        self,
        python_code: str,
        __event_emitter__: Callable = None,
    ) -> str:
        """
        Run Python code in an isolated QEMU microVM.
        Each invocation gets a fresh VM that is destroyed after execution.
        """
        return await self._execute(python_code, "python", __event_emitter__)

    async def run_javascript_code(
        self,
        javascript_code: str,
        __event_emitter__: Callable = None,
    ) -> str:
        """
        Run JavaScript or TypeScript code in an isolated QEMU microVM using Bun.
        Each invocation gets a fresh VM that is destroyed after execution.
        """
        return await self._execute(javascript_code, "javascript", __event_emitter__)

    async def run_bash_command(
        self,
        bash_command: str,
        __event_emitter__: Callable = None,
    ) -> str:
        """
        Run a Bash command in an isolated QEMU microVM.
        Each invocation gets a fresh VM that is destroyed after execution.
        """
        return await self._execute(bash_command, "raw", __event_emitter__)

    async def _execute(
        self,
        code: str,
        language: str,
        __event_emitter__: Callable = None,
    ) -> str:
        if __event_emitter__:
            await __event_emitter__(
                {
                    "type": "status",
                    "data": {
                        "description": f"Executing {language} code in sandbox...",
                        "done": False,
                    },
                }
            )

        scheduler = await self._get_scheduler()

        # Build execution kwargs
        kwargs = {}
        if self.valves.NETWORKING_ALLOWED:
            kwargs["allow_network"] = True
            if self.valves.ALLOWED_DOMAINS.strip():
                kwargs["allowed_domains"] = [
                    d.strip()
                    for d in self.valves.ALLOWED_DOMAINS.split(",")
                    if d.strip()
                ]

        result = await scheduler.run(
            code=code,
            language=language,
            **kwargs,
        )

        if __event_emitter__:
            await __event_emitter__(
                {
                    "type": "status",
                    "data": {
                        "description": f"Execution completed (exit code: {result.exit_code}, {result.timing.total_ms}ms)",
                        "done": True,
                    },
                }
            )

        return json.dumps(
            {
                "status": "OK" if result.exit_code == 0 else "ERROR",
                "exit_code": result.exit_code,
                "stdout": result.stdout,
                "stderr": result.stderr,
                "execution_time_ms": result.timing.total_ms,
            }
        )

This follows the exact same pattern as the existing safe-code-execution tool -- same class structure, same Valves configuration, same event emitter usage -- so users already familiar with that plugin will find this immediately recognizable.

Alternatively, as a native backend integration:

For deeper integration, exec-sandbox could be registered as a new CODE_EXECUTION_ENGINE option (alongside the existing "pyodide" and "jupyter" options), backing the built-in execute_code system tool. Note: Open Terminal uses a separate Docker-based shell API rather than the CODE_EXECUTION_ENGINE config path. This would require a modest patch to backend/open_webui/utils/code_interpreter.py to dispatch to the exec-sandbox Scheduler when config.code.engine == "exec-sandbox". This approach would benefit from the existing UI affordances (run buttons on code blocks, automatic matplotlib capture, etc.) without any user-facing plugin installation.

Alternatives Considered

1. EtiennePerot's safe-code-execution (gVisor)
Excellent community plugin that currently fills this gap. However, gVisor is Linux-only, requires relaxed container security policies (seccomp=unconfined, AppArmor disabled, writable cgroupfs), and provides userspace kernel isolation rather than hardware VM isolation. exec-sandbox is a complementary alternative for deployments where macOS support, stricter container policies, or hardware-level isolation are requirements.

2. Jupyter backend
Works for single-user setups but the shared kernel model makes it explicitly unsuitable for multi-user environments. No isolation between users.

3. Open Terminal (Docker-based)
Provides container-level isolation and full shell access, but containers share the host kernel. The isolation boundary is the Linux namespace layer, not a hardware hypervisor.

4. Cloud sandbox APIs (E2B, Modal, Runloop, Daytona)
Require sending code and data to external servers. Not viable for air-gapped, privacy-sensitive, or self-hosted deployments. Several are proprietary.

Additional Context

Resource requirements:

• Python 3.12+ on the host (exec-sandbox's minimum supported version)
• QEMU must be installed on the host (brew install qemu on macOS, apt install qemu-system on Linux)
• Hardware acceleration recommended: KVM on Linux (/dev/kvm), HVF on macOS (kern.hv_support)
• Docker deployments: QEMU must be installed inside the container, and the container needs access to /dev/kvm on the host (e.g., --device /dev/kvm). Most cloud VMs and bare-metal hosts expose KVM, but nested virtualization must be enabled if running inside a VM
• VM images (~75MB for Python, ~57MB for JS, ~15MB for shell) auto-download from GitHub Releases on first use
• Memory: each VM uses 192MB by default (configurable), with warm pool pre-starting 1 VM per language
• Without hardware acceleration, QEMU uses software emulation (TCG), which is 5-8x slower but still functional

What this does NOT propose:

• This is not proposing to replace Pyodide, Jupyter, or Open Terminal. Each has valid use cases
• This is not proposing changes to Open WebUI core (the Workspace Tool approach requires zero core changes)
• This is not proposing a cloud dependency -- everything runs on the same host as Open WebUI

Links:

• GitHub: https://github.com/dualeai/exec-sandbox
• PyPI: https://pypi.org/project/exec-sandbox/
• License: Apache-2.0

Originally created by @clemlesne on GitHub (Mar 4, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/22225 ### TL;DR [exec-sandbox](https://github.com/dualeai/exec-sandbox) runs untrusted code inside ephemeral QEMU microVMs with hardware virtualization (KVM/HVF). It supports Python 3.14, JS/TS (Bun), and Shell, with 1-2ms warm-pool latency, streaming I/O, and 9 layers of isolation -- no privileged containers needed. It can be installed today as a zero-core-change Workspace Tool (`pip install exec-sandbox`), or later wired in as a native `CODE_EXECUTION_ENGINE` backend. *Disclosure: I am the author/maintainer of exec-sandbox.* ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description Open WebUI's code execution today offers three backends, each with meaningful trade-offs for multi-user and self-hosted deployments: | Backend | Isolation | Multi-user safe | Languages | Persistent packages | Server-side | |---------|-----------|-----------------|-----------|---------------------|-------------| | **Pyodide** (default) | Browser sandbox (WASM) | Yes | Python only (subset) | No | No | | **Jupyter** | None (shared kernel) | No -- [docs warn against it](https://docs.openwebui.com/features/chat-conversations/chat-features/code-execution/) | Python only | Yes | Yes | | **Open Terminal** | Docker container | Partial | Any | Yes | Yes | **The gap:** There is no built-in backend that simultaneously provides (a) strong security isolation suitable for multi-tenant deployments, (b) server-side execution with full language support (Python, JS, shell), and (c) zero shared state between users/executions. The community has recognized this. [Discussion #19050](https://github.com/open-webui/open-webui/discussions/19050) requests sandbox functionality as a core built-in, extending beyond the current Pyodide/Jupyter capabilities. [Issue #9614](https://github.com/open-webui/open-webui/issues/9614) tracks code interpreter enhancements and has "external sandboxing" checked off on its roadmap (likely referencing the safe-code-execution plugin); exec-sandbox offers an alternative approach with hardware VM isolation instead of userspace kernel sandboxing. [Issue #18224](https://github.com/open-webui/open-webui/issues/18224) highlighted the inadequacy of documentation around the RCE surface when workspace tools run via `exec()` on the server -- reinforcing why sandboxed execution matters. The community [safe-code-execution](https://github.com/EtiennePerot/safe-code-execution) plugin by EtiennePerot addresses this with gVisor, but it requires Linux-only gVisor, relaxed seccomp profiles (`seccomp=unconfined`), AppArmor disabled, and writable cgroupfs -- constraints that can be difficult to meet in production container orchestration environments and are unavailable on macOS for local development. ### Desired Solution you'd like Add [exec-sandbox](https://github.com/dualeai/exec-sandbox) ([PyPI](https://pypi.org/project/exec-sandbox/)) as an additional code execution backend option, alongside the existing Pyodide, Jupyter, and Open Terminal backends. **What exec-sandbox provides:** - Runs untrusted code inside dedicated QEMU microVMs with hardware virtualization (KVM on Linux, HVF on macOS) - Each execution gets a fresh VM -- destroyed immediately after. No state leakage between users or executions - 9 layers of security isolation: hardware VM, custom hardened kernel (~360 subsystems stripped), EROFS read-only rootfs, unprivileged QEMU, non-root REPL, seccomp, cgroups v2, namespaces, socket authentication - Supports Python 3.14, JavaScript/TypeScript (Bun 1.3), and Shell (Bash) - 1-2ms warm pool latency, ~100ms from memory snapshot, ~400ms cold boot - Streaming stdout/stderr, file I/O (upload/download), session support (stateful multi-step execution) - Network disabled by default, optional domain allowlisting with DNS + TLS SNI filtering - Works on macOS (HVF) and Linux (KVM) -- developers can test locally on Mac - Self-hosted, no cloud dependency, Apache-2.0 license - `pip install exec-sandbox` -- single dependency, assets auto-download on first use **How this compares to existing options:** | | exec-sandbox | gVisor (safe-code-execution) | Pyodide | Jupyter | |---|---|---|---|---| | Isolation level | Hardware VM (KVM/HVF) | Userspace kernel | Browser WASM | None | | macOS support | Yes (HVF) | No (Linux only) | Yes (browser) | Yes | | Languages | Python, JS/TS, Shell | Python, Bash | Python (subset) | Python | | Privileged container needed | No | Yes (seccomp=unconfined, no AppArmor) | N/A | N/A | | Fresh per execution | Yes | Yes | Yes | No (shared) | | Streaming output | Yes | Yes | No | Partial | | File I/O | Yes | Limited | No | Yes | | Package install | Yes (cached) | Yes | Limited (WASM) | Yes | | Multi-user safe | Yes | Yes | Yes | No | **Integration as an Open WebUI Workspace Tool:** The most natural integration point is as a Workspace Tool, matching the pattern established by EtiennePerot's safe-code-execution plugin. This requires zero changes to Open WebUI core. Here is a working implementation sketch: ```python """ title: exec-sandbox Code Execution author: dualeai description: Run Python, JavaScript, and Shell code in hardware-isolated QEMU microVMs version: 0.1.0 license: Apache-2.0 requirements: exec-sandbox>=0.18.0 required_python: >=3.12 """ import asyncio import json from typing import Callable from pydantic import BaseModel, Field class Tools: class Valves(BaseModel): WARM_POOL_SIZE: int = Field( default=1, description="Number of pre-started VMs per language (0 to disable warm pool)", ) DEFAULT_MEMORY_MB: int = Field( default=256, description="Memory per VM in MB", ) MAX_RUNTIME_SECONDS: int = Field( default=30, description="Maximum execution time in seconds", ) NETWORKING_ALLOWED: bool = Field( default=False, description="Allow sandboxed code to access the network", ) ALLOWED_DOMAINS: str = Field( default="", description="Comma-separated domain allowlist (only used when networking is enabled)", ) def __init__(self): self.valves = self.Valves() self._scheduler = None self._lock = asyncio.Lock() async def _get_scheduler(self): """Lazy-initialize the Scheduler singleton (shared across tool invocations).""" if self._scheduler is None: async with self._lock: if self._scheduler is None: from exec_sandbox import Scheduler, SchedulerConfig config = SchedulerConfig( warm_pool_size=self.valves.WARM_POOL_SIZE, default_memory_mb=self.valves.DEFAULT_MEMORY_MB, default_timeout_seconds=self.valves.MAX_RUNTIME_SECONDS, ) self._scheduler = Scheduler(config) await self._scheduler.__aenter__() return self._scheduler async def run_python_code( self, python_code: str, __event_emitter__: Callable = None, ) -> str: """ Run Python code in an isolated QEMU microVM. Each invocation gets a fresh VM that is destroyed after execution. """ return await self._execute(python_code, "python", __event_emitter__) async def run_javascript_code( self, javascript_code: str, __event_emitter__: Callable = None, ) -> str: """ Run JavaScript or TypeScript code in an isolated QEMU microVM using Bun. Each invocation gets a fresh VM that is destroyed after execution. """ return await self._execute(javascript_code, "javascript", __event_emitter__) async def run_bash_command( self, bash_command: str, __event_emitter__: Callable = None, ) -> str: """ Run a Bash command in an isolated QEMU microVM. Each invocation gets a fresh VM that is destroyed after execution. """ return await self._execute(bash_command, "raw", __event_emitter__) async def _execute( self, code: str, language: str, __event_emitter__: Callable = None, ) -> str: if __event_emitter__: await __event_emitter__( { "type": "status", "data": { "description": f"Executing {language} code in sandbox...", "done": False, }, } ) scheduler = await self._get_scheduler() # Build execution kwargs kwargs = {} if self.valves.NETWORKING_ALLOWED: kwargs["allow_network"] = True if self.valves.ALLOWED_DOMAINS.strip(): kwargs["allowed_domains"] = [ d.strip() for d in self.valves.ALLOWED_DOMAINS.split(",") if d.strip() ] result = await scheduler.run( code=code, language=language, **kwargs, ) if __event_emitter__: await __event_emitter__( { "type": "status", "data": { "description": f"Execution completed (exit code: {result.exit_code}, {result.timing.total_ms}ms)", "done": True, }, } ) return json.dumps( { "status": "OK" if result.exit_code == 0 else "ERROR", "exit_code": result.exit_code, "stdout": result.stdout, "stderr": result.stderr, "execution_time_ms": result.timing.total_ms, } ) ``` This follows the exact same pattern as the existing safe-code-execution tool -- same class structure, same Valves configuration, same event emitter usage -- so users already familiar with that plugin will find this immediately recognizable. **Alternatively, as a native backend integration:** For deeper integration, exec-sandbox could be registered as a new `CODE_EXECUTION_ENGINE` option (alongside the existing `"pyodide"` and `"jupyter"` options), backing the built-in `execute_code` system tool. Note: Open Terminal uses a separate Docker-based shell API rather than the `CODE_EXECUTION_ENGINE` config path. This would require a modest patch to `backend/open_webui/utils/code_interpreter.py` to dispatch to the exec-sandbox Scheduler when `config.code.engine == "exec-sandbox"`. This approach would benefit from the existing UI affordances (run buttons on code blocks, automatic matplotlib capture, etc.) without any user-facing plugin installation. ### Alternatives Considered **1. EtiennePerot's safe-code-execution (gVisor)** Excellent community plugin that currently fills this gap. However, gVisor is Linux-only, requires relaxed container security policies (`seccomp=unconfined`, AppArmor disabled, writable cgroupfs), and provides userspace kernel isolation rather than hardware VM isolation. exec-sandbox is a complementary alternative for deployments where macOS support, stricter container policies, or hardware-level isolation are requirements. **2. Jupyter backend** Works for single-user setups but the shared kernel model makes it [explicitly unsuitable](https://docs.openwebui.com/features/chat-conversations/chat-features/code-execution/) for multi-user environments. No isolation between users. **3. Open Terminal (Docker-based)** Provides container-level isolation and full shell access, but containers share the host kernel. The isolation boundary is the Linux namespace layer, not a hardware hypervisor. **4. Cloud sandbox APIs (E2B, Modal, Runloop, Daytona)** Require sending code and data to external servers. Not viable for air-gapped, privacy-sensitive, or self-hosted deployments. Several are proprietary. ### Additional Context **Resource requirements:** - Python 3.12+ on the host (exec-sandbox's minimum supported version) - QEMU must be installed on the host (`brew install qemu` on macOS, `apt install qemu-system` on Linux) - Hardware acceleration recommended: KVM on Linux (`/dev/kvm`), HVF on macOS (`kern.hv_support`) - **Docker deployments:** QEMU must be installed inside the container, and the container needs access to `/dev/kvm` on the host (e.g., `--device /dev/kvm`). Most cloud VMs and bare-metal hosts expose KVM, but nested virtualization must be enabled if running inside a VM - VM images (~75MB for Python, ~57MB for JS, ~15MB for shell) auto-download from GitHub Releases on first use - Memory: each VM uses 192MB by default (configurable), with warm pool pre-starting 1 VM per language - Without hardware acceleration, QEMU uses software emulation (TCG), which is 5-8x slower but still functional **What this does NOT propose:** - This is not proposing to replace Pyodide, Jupyter, or Open Terminal. Each has valid use cases - This is not proposing changes to Open WebUI core (the Workspace Tool approach requires zero core changes) - This is not proposing a cloud dependency -- everything runs on the same host as Open WebUI **Links:** - GitHub: https://github.com/dualeai/exec-sandbox - PyPI: https://pypi.org/project/exec-sandbox/ - License: Apache-2.0

GiteaMirror closed this issue 2026-05-18 05:07:42 -05:00

GiteaMirror commented 2026-05-18 05:07:43 -05:00

Author

Owner

Copy Link

@Classic298 commented on GitHub (Mar 4, 2026):

Probably not going to happen.
Also this feature request violates this requirement: "I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions."

Should have been opened in the discussions

The good news: What you are asking for is already being built.

https://github.com/open-webui/terminals

A scalable multi-user solution with isolated individual sandboxes - one sandbox per user - auto startup and orchestration.

and some of the other things you mentioned which open terminal does not yet have might be added in the future, who knows

But adding another backend must be most carefully considered, in the context of open terminal already covering 99% of that and the multi-user orchestration coming soon, i see little reason to add exec-sandbox

<!-- gh-comment-id:3998589492 --> @Classic298 commented on GitHub (Mar 4, 2026): Probably not going to happen. Also this feature request violates this requirement: "I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions." Should have been opened in the discussions The good news: What you are asking for is already being built. https://github.com/open-webui/terminals A scalable multi-user solution with isolated individual sandboxes - one sandbox per user - auto startup and orchestration. and some of the other things you mentioned which open terminal does not yet have might be added in the future, who knows But adding another backend must be most carefully considered, in the context of open terminal already covering 99% of that and the multi-user orchestration coming soon, i see little reason to add exec-sandbox

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dev

v0.10.2

v0.10.1

v0.10.0

v0.9.6

v0.9.5

v0.9.4

v0.9.3

v0.9.2

v0.9.1

v0.9.0

v0.8.12

v0.8.11

v0.8.10

v0.8.9

v0.8.8

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.2

v0.7.1

v0.7.0

v0.6.43

v0.6.42

v0.6.41

v0.6.40

v0.6.39

v0.6.38

v0.6.37

v0.6.36

v0.6.35

v0.6.34

v0.6.33

v0.6.32

v0.6.31

v0.6.30

v0.6.29

v0.6.28

v0.6.27

v0.6.26

v0.6.25

v0.6.24

v0.6.23

v0.6.22

v0.6.21

v0.6.20

v0.6.19

v0.6.18

v0.6.17

v0.6.16

v0.6.15

v0.6.14

v0.6.13

v0.6.12

v0.6.11

v0.6.10

v0.6.9

v0.6.8

v0.6.7

v0.6.6

v0.6.5

v0.6.4

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.35

v0.3.34

v0.3.33

v0.3.32

v0.3.31

v0.3.30

v0.3.29

v0.3.28

v0.3.27

v0.3.26

v0.3.25

v0.3.24

v0.3.23

v0.3.22

v0.3.21

v0.3.20

v0.3.19

v0.3.18

v0.3.17

v0.3.16

v0.3.15

v0.3.14

v0.3.13

v0.3.12

v0.3.11

v0.3.10

v0.3.9

v0.3.8

v0.3.7

v0.3.6

v0.3.5

v0.3.4

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.125

v0.1.124

v0.1.123

v0.1.122

v0.1.121

v0.1.120

v0.1.119

v0.1.118

v0.1.117

v0.1.116

v0.1.115

v0.1.114

v0.1.113

v0.1.112

v0.1.111

v0.1.110

v0.1.109

v0.1.108

v0.1.107

v0.1.106

v0.1.105

v0.1.104

v0.1.103

v0.1.102

Labels

Clear labels

bug

confirmed

confirmed issue

core

documentation

enhancement

good first issue

help wanted

non-core

pull-request

Mirrored from GitHub Pull Request

python

question

testing wanted

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#106664