Skip to content

Bug: Correct managed WebUI launch flags and isolated Python compatibility #108

Description

@BerryUIKI

Summary

webui_supervisor.py:169 passes --listen 127.0.0.1 and --nowebui. Upstream defines --listen as a boolean flag, with --server-name as a separate address option; --nowebui disables the native interface. Official WebUI arguments.

The installer also creates a venv from Berry's interpreter. This checkout uses Python 3.14, while upstream's Windows launcher checks for Python 3.10 and identifies 3.10.6 as its tested version. Official launch checks.

Environment and evidence

  • Review finding: F08 (2026-10-05 product/technical review).
  • Baseline: Windows, dev at c1c5dbe. The remote dev matched this commit when filing.
  • Evidence: Code.
  • Priority recommendation: P1 - proposed first-release blocker. This is review triage, not a production-incident severity declaration.
  • No real credentials, paid inference, engine installation, or unrelated process termination were used for review probes. Mocked observations establish the stated code behavior, not live-provider/GPU acceptance.

Reproduction or validation

Inspect WebUISupervisor.start: it passes --listen followed by 127.0.0.1 and --nowebui. Upstream defines --listen as a boolean and provides a separate server-name option; --nowebui disables the promised native UI. The installer creates the engine venv from Berry's interpreter, which was Python 3.14.5 during review, while upstream Windows launch checks target Python 3.10. No GPU installation was attempted.

User impact

Launch incompatibility, unintended listener configuration, and an unavailable native UI are credible integration blockers. A GPU installation was not attempted.

Proposed approach

Select a supported isolated interpreter and pinned engine version, use correct loopback flags, and verify both API health and native UI access.

Acceptance criteria

  • Pin a supported engine revision and provision its supported interpreter in the isolated runtime.
  • Use the correct loopback binding flags.
  • Both API health and the advertised native WebUI are verified after deployment.
  • Unsupported prerequisites fail preflight with actionable guidance.

Verification scope

Real GPU inference, paid-provider compatibility, and a clean-machine packaged desktop journey remain unverified. Any follow-up implementation should target dev under the repository's contribution/branching rules.

Activity

  1. added
    bugSomething isn't working
    criticalCritical priority issues that block core functionality or cause vulnerabilities
    backendBackend Python / FastAPI / Engine issues
    on Oct 4, 2026
  2. added a commit that references this issue on Oct 5, 2026
    d27b8ae
  3. BerryUIKI commented on Oct 5, 2026

    @BerryUIKI
    OwnerAuthor

    Fixed in PR #157. WebUI launch flags now use correct --listen (boolean) with --server-name 127.0.0.1, native WebUI is enabled by removing --nowebui, and Python version compatibility checks warn about non-3.10.x versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    backendBackend Python / FastAPI / Engine issuesbugSomething isn't workingcriticalCritical priority issues that block core functionality or cause vulnerabilities

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions