[GH-ISSUE #266] "Failed to connect to server" when configuring Open Terminal integration (works fine in browser) #170

New issue

Open

opened 2026-10-18 14:06:41 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:06:41 +00:00

Owner

Originally created by @gilvandev on GitHub (Aug 29, 2026).
Original GitHub issue: https://github.com/open-webui/desktop/issues/266

Bug: "Failed to connect to server" when configuring Open Terminal integration (works fine in browser)

Description

When configuring a Terminal (Open Terminal) integration under Settings → Integrations → Terminal and clicking Verify Connection, the desktop app shows a red "Falha na conexão com o servidor" ("Failed to connect to server") toast, even though the target server is fully reachable, responding, and correctly authenticated.

The exact same configuration works without any issue when accessing the same Open WebUI instance from a regular browser (tested in Chrome).

Environment

Open WebUI Desktop version: v0.0.20 (latest)
OS: Windows
Open WebUI server version: v0.11.1 (self-hosted, Docker on TrueNAS SCALE)
Open Terminal version: 0.12.3 (self-hosted, Docker)
Connection type: User-level "Terminal" integration (Settings → Integrations → Terminal), configured with:
- URL: http://192.168.1.15:30377
- OpenAPI spec path: /openapi.json
- Auth: Bearer token

Steps to Reproduce

Open the Open WebUI Desktop app and connect to a remote self-hosted Open WebUI server.
Go to Settings → Integrations → Terminal → Open Terminal.
Add a new terminal connection with a valid URL and Bearer API key pointing to a running Open Terminal instance.
Click Verify Connection.
Observe the error toast: "Falha na conexão com o servidor".

Expected Behavior

The connection should verify successfully, exactly as it does when performing the same steps in a standard browser session against the same Open WebUI server.

Actual Behavior

Connection verification fails in the desktop app only.

Troubleshooting Already Performed

To rule out server-side issues, I validated every layer manually from the TrueNAS host itself:

Network reachability from inside the Open WebUI container — confirmed working:
docker exec -it ix-open-webui-open-webui-1 curl -v http://192.168.1.15:30377/openapi.json
→ Returns HTTP/1.1 200 OK with the full valid OpenAPI schema.
Authentication against a protected endpoint — confirmed working:
docker exec -it ix-open-webui-open-webui-1 curl -v -H "Authorization: Bearer " http://192.168.1.15:30377/execute

→ Returns HTTP/1.1 200 OK with [] (empty process list, as expected).
Direct browser access to http://192.168.1.15:30377/docs and http://192.168.1.15:30377/openapi.json — both load correctly and return valid responses.
Same integration configured via the Open WebUI browser session (Chrome) — connects and verifies successfully with the exact same URL and API key.

This isolates the issue specifically to the desktop app's embedded Electron/Chromium webview failing to complete the request, while the underlying server, network path, and credentials are all confirmed valid.

Suspected Cause

Given the desktop app is Electron-based, this is likely related to Private Network Access (PNA) restrictions or a stricter CORS/fetch policy enforced by the embedded Chromium instance when a "remote" context (the connected Open WebUI server) attempts to reach a separate private-network address (the Open Terminal instance) directly from the renderer. Standard browsers appear to allow or handle this differently than the Electron webview does by default.

Additional Notes

This may also affect other integrations that rely on the browser making direct requests to separate self-hosted services on the local network (not proxied through the Open WebUI backend), so it might be worth checking whether other "Direct Connection" style integrations are similarly affected.

Happy to provide further logs, devtools console output, or test additional configurations if helpful.

Originally created by @gilvandev on GitHub (Aug 29, 2026). Original GitHub issue: https://github.com/open-webui/desktop/issues/266 ## Bug: "Failed to connect to server" when configuring Open Terminal integration (works fine in browser) ### Description When configuring a **Terminal** (Open Terminal) integration under **Settings → Integrations → Terminal** and clicking **Verify Connection**, the desktop app shows a red "Falha na conexão com o servidor" ("Failed to connect to server") toast, even though the target server is fully reachable, responding, and correctly authenticated. The exact same configuration works without any issue when accessing the same Open WebUI instance from a regular browser (tested in Chrome). ### Environment - Open WebUI Desktop version: v0.0.20 (latest) - OS: Windows - Open WebUI server version: v0.11.1 (self-hosted, Docker on TrueNAS SCALE) - Open Terminal version: 0.12.3 (self-hosted, Docker) - Connection type: User-level "Terminal" integration (Settings → Integrations → Terminal), configured with: - URL: `http://192.168.1.15:30377` - OpenAPI spec path: `/openapi.json` - Auth: Bearer token ### Steps to Reproduce 1. Open the Open WebUI Desktop app and connect to a remote self-hosted Open WebUI server. 2. Go to **Settings → Integrations → Terminal → Open Terminal**. 3. Add a new terminal connection with a valid URL and Bearer API key pointing to a running Open Terminal instance. 4. Click **Verify Connection**. 5. Observe the error toast: "Falha na conexão com o servidor". ### Expected Behavior The connection should verify successfully, exactly as it does when performing the same steps in a standard browser session against the same Open WebUI server. ### Actual Behavior Connection verification fails in the desktop app only. ### Troubleshooting Already Performed To rule out server-side issues, I validated every layer manually from the TrueNAS host itself: 1. **Network reachability from inside the Open WebUI container** — confirmed working: docker exec -it ix-open-webui-open-webui-1 curl -v http://192.168.1.15:30377/openapi.json → Returns `HTTP/1.1 200 OK` with the full valid OpenAPI schema. 2. **Authentication against a protected endpoint** — confirmed working: docker exec -it ix-open-webui-open-webui-1 curl -v -H "Authorization: Bearer <redacted>" http://192.168.1.15:30377/execute → Returns `HTTP/1.1 200 OK` with `[]` (empty process list, as expected). 3. **Direct browser access** to `http://192.168.1.15:30377/docs` and `http://192.168.1.15:30377/openapi.json` — both load correctly and return valid responses. 4. **Same integration configured via the Open WebUI browser session** (Chrome) — connects and verifies successfully with the exact same URL and API key. This isolates the issue specifically to the desktop app's embedded Electron/Chromium webview failing to complete the request, while the underlying server, network path, and credentials are all confirmed valid. ### Suspected Cause Given the desktop app is Electron-based, this is likely related to **Private Network Access (PNA)** restrictions or a stricter CORS/fetch policy enforced by the embedded Chromium instance when a "remote" context (the connected Open WebUI server) attempts to reach a separate private-network address (the Open Terminal instance) directly from the renderer. Standard browsers appear to allow or handle this differently than the Electron webview does by default. ### Additional Notes This may also affect other integrations that rely on the browser making direct requests to separate self-hosted services on the local network (not proxied through the Open WebUI backend), so it might be worth checking whether other "Direct Connection" style integrations are similarly affected. Happy to provide further logs, devtools console output, or test additional configurations if helpful.

bsakaguchi referenced this issue

2026-10-18 14:07:06 +00:00

[PR #172] [MERGED] 0.0.17 #221

bsakaguchi referenced this issue

2026-10-18 14:07:07 +00:00

[PR #170] [CLOSED] (fix) url links open in the default browser #223