github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-17 17:02:01 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

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

New Issue
Closed
opened 2026-04-20 02:11:08 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-20 02:11:08 -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:

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 commented 2026-04-20 02:11:10 -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
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
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#19669
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?