[Bug]: Can't connect to Remote Gateway via Tailscale for Hermes Desktop

[seguelaCedric]

Bug Description

The test connection works, but the actual connection doesn't.

Steps to Reproduce

Use remote gateway for VPS using tailscale

Expected Behavior

Connect to remote gateway

Actual Behavior

Test connection works but the actual connection doesn't

Affected Component

Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

No response

Debug Report

2026-06-03 10:15:33,458 WARNING tui_gateway.ws: ws send failed peer=127.0.0.1:50022 error=
2026-06-03 10:15:33,461 WARNING tui_gateway.ws: ws response send failed peer=127.0.0.1:50022 id=38 method=setup.runtime_check


and 


[hermes] [boot] Restarting desktop connection
[hermes] [boot] Resolving Hermes backend
[hermes] [boot] Connecting to remote Hermes backend at http://100.112.221.20:9119
[hermes] Hermes backend exited (SIGTERM)
[hermes] [boot] Remote Hermes backend is ready
[hermes] [boot] Resolving Hermes backend
[hermes] [boot] Connecting to remote Hermes backend at http://100.112.221.20:9119
[hermes] [boot] Remote Hermes backend is ready
[hermes] [bootstrap] reset requested by renderer; clearing latched failure
[hermes] [boot] Resolving Hermes backend
[hermes] [boot] Connecting to remote Hermes backend at http://100.112.221.20:9119
[hermes] [boot] Remote Hermes backend is ready
[hermes] [boot] Restarting desktop connection
[hermes] [boot] Resolving Hermes backend
[hermes] [boot] Finding an open local port
[hermes] [boot] Resolving Hermes runtime
[hermes] [boot] Hermes runtime is ready
[hermes] [boot] Starting Hermes backend via Hermes at /Users/cedricseguela/.hermes/hermes-agent (venv: /Users/cedricseguela/.hermes/hermes-agent/venv)
[hermes] Starting Hermes backend via Hermes at /Users/cedricseguela/.hermes/hermes-agent (venv: /Users/cedricseguela/.hermes/hermes-agent/venv)

Operating System

Ubuntu 24.04

Python Version

No response

Hermes Version

No response

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[Kavyrocom]

Additional sanitized reproduction from another self-hosted setup; likely same failure mode.

Environment

• Hermes Desktop: 0.15.1 era
• Remote backend/dashboard: Hermes 0.15.1
• Client OS: macOS (Hermes Desktop)
• Remote host OS: Ubuntu 24.04 VPS
• Network path: Tailscale private network
• Remote URL shape: http://100.x.x.x:9119
• Dashboard is also reachable publicly through Cloudflare Access, but this reproduction uses the direct Tailscale private URL, not Cloudflare Access.
• Dashboard session token is provided in the Desktop UI. Token is intentionally not included here.

Setup details

The remote dashboard is reachable over Tailscale through a reverse proxy bound only to the Tailscale IP:

Tailscale client -> http://100.x.x.x:9119 -> Caddy bound to Tailscale IP -> 127.0.0.1:9119 Hermes dashboard

Server-side checks pass:

GET http://100.x.x.x:9119/ -> 200
GET http://127.0.0.1:9119/ -> 200
GET /api/config with X-Hermes-Session-Token -> 200

Reproduction

1. Open Hermes Desktop on macOS.
2. Settings -> Gateway Connection.
3. Select Remote gateway.
4. Set Remote URL to http://100.x.x.x:9119.
5. Paste the dashboard session token.
6. Click Test remote.
7. Desktop reports success: Connected to http://100.x.x.x:9119 · Hermes 0.15.1.
8. Click Save and reconnect.
9. Desktop then shows an error instead of holding the remote connection.

Expected behavior

If Test remote validates the remote URL + session token successfully, Save and reconnect should either:

• persist the remote gateway config and connect to the same remote backend, or
• fail with a specific diagnostic explaining which later step is failing, e.g. WebSocket connection, config persistence, local runtime bootstrap, origin/host validation, etc.

Actual behavior

Test remote passes, but Save and reconnect fails. From the UI, the successful test appears misleading because it does not guarantee that the actual remote desktop connection path will work.

Notes

• This does not appear to be a Tailscale reachability issue: the same Mac can open the remote dashboard URL in a browser over Tailscale.
• It does not appear to be a dashboard token issue: /api/config returns 200 when called with X-Hermes-Session-Token.
• No Cloudflare Access cookies/redirects are involved in this reproduction path.
• The real tailnet IP, token, hostname, account identity, and private deployment names are redacted.

It would help if Test remote exercised the same WebSocket/session path used by Save and reconnect, or if Save and reconnect surfaced the first failing request/transport step in the UI/logs.

[Kavyrocom]

Additional sanitized desktop.log excerpt from the same setup.

The full log is 2,024 lines; only the relevant, redacted lines are included here.

High-level log findings

• Earlier attempts against a Cloudflare Access protected URL repeatedly fail at /api/status because the desktop client receives HTML 302 instead of JSON. That part is expected if the URL is behind Cloudflare Access and matches issue Hermes Desktop remote gateway fails behind Cloudflare Access: /api/status gets HTML 302 instead of opening Access login flow #37986.
• The later Tailscale URL does pass the remote readiness check: Remote Hermes backend is ready.
• After remote readiness succeeds, Desktop appears to restart the connection and fall back to starting a local backend again.
• In the local fallback path it can then hit a local port conflict: 127.0.0.1:9120 already in use.
• Multiple Hermes backend exited (SIGTERM) lines appear during remote/local switching.

Sanitized repeated failures against Cloudflare Access URL

249x [boot] Connecting to remote Hermes backend at https://<cloudflare-access-domain>
247x [boot] Desktop boot failed: Hermes backend did not become ready: Expected JSON from https://<cloudflare-access-domain>/api/status but got HTML (status 302). The endpoint is likely missing on the Hermes backend.

This is not the main Tailscale reproduction, but it shows that the Desktop readiness check does not distinguish "HTML auth redirect" from "endpoint missing".

Sanitized Tailscale reproduction excerpt

[boot] Restarting desktop connection
[boot] Resolving Hermes backend
[boot] Connecting to remote Hermes backend at http://100.x.x.x:9119
Hermes backend exited (SIGTERM)
[boot] Remote Hermes backend is ready
[boot] Resolving Hermes backend
[boot] Connecting to remote Hermes backend at http://100.x.x.x:9119
[boot] Remote Hermes backend is ready
[bootstrap] reset requested by renderer; clearing latched failure
[boot] Resolving Hermes backend
[boot] Connecting to remote Hermes backend at http://100.x.x.x:9119
[boot] Remote Hermes backend is ready
[boot] Restarting desktop connection
[boot] Resolving Hermes backend
[boot] Finding an open local port
[boot] Resolving Hermes runtime
[boot] Hermes runtime is ready
[boot] Starting Hermes backend via Hermes at /Users/<user>/.hermes/hermes-agent (venv: /Users/<user>/.hermes/hermes-agent/venv)
[boot] Waiting for Hermes backend to become ready
[boot] Hermes backend is ready. Finalizing desktop startup

Later repetitions show the same pattern:

[boot] Connecting to remote Hermes backend at http://100.x.x.x:9119
Hermes backend exited (SIGTERM)
[boot] Remote Hermes backend is ready
[boot] Resolving Hermes backend
[boot] Connecting to remote Hermes backend at http://100.x.x.x:9119
[boot] Remote Hermes backend is ready
[boot] Restarting desktop connection
[boot] Resolving Hermes backend
[boot] Finding an open local port
[boot] Resolving Hermes runtime
[boot] Hermes runtime is ready
[boot] Starting Hermes backend via Hermes at /Users/<user>/.hermes/hermes-agent (venv: /Users/<user>/.hermes/hermes-agent/venv)

Local fallback conflict also observed

ERROR:    [Errno 48] error while attempting to bind on address ('127.0.0.1', 9120): address already in use
Hermes Web UI → http://127.0.0.1:9120
Hermes backend exited (1)
[boot] Hermes backend exited before it became ready (1).
[boot] Desktop boot failed: Hermes backend exited before it became ready (1). Log: /Users/<user>/.hermes/logs/desktop.log

Why this seems relevant to this issue

The important part is not Tailscale reachability: the log says the remote backend is ready over http://100.x.x.x:9119. The problem seems to happen after the remote check succeeds, during connection persistence/restart, where Desktop appears to switch back into local-backend startup logic instead of holding the selected remote backend.

No session token, real tailnet IP, real domain, hostnames, or account identity are included in this excerpt.

[bscott]

Confirming the same failure mode on a Tailscale setup.

Environment

• Hermes Desktop 0.15.1 (macOS, Apple Silicon)
• Remote Hermes Agent 0.15.1 (release 2026.5.29) reached over Tailscale at http://<host>:9119
• Dashboard has __HERMES_AUTH_REQUIRED__=false

Symptoms

• desktop.log: Connecting to remote Hermes backend at http://<host>:9119 → Remote Hermes backend is ready (the /api/status boot probe passes), but the UI then shows "Could not connect to Hermes gateway."
• A direct WebSocket handshake to ws://<host>:9119/api/ws?token=<session_token> returns HTTP 403, regardless of token value or Origin header.

Diagnosis (matches the already-closed root-cause issues)
The REST host-allow check passes by hostname and the token is correct (verified it equals the server's _SESSION_TOKEN injected into the dashboard HTML), so the 403 is the WS admission gate _ws_request_is_allowed() in hermes_cli/web_server.py, not auth. For a packaged Electron client hitting a remote bind, the _ws_client_is_allowed() loopback-peer guard and the _ws_host_origin_is_allowed() non-web-Origin (file:///null) guard can't both be satisfied — the same root cause as #37399 and #34396.

This appears already fixed in main but not released: #34396 → PR #35141, and #37399 → PRs #37405 / #37747. Those merged after the 0.15.1 tag (2026-05-29), so a 0.15.1 install (which the updater reports as latest, behind: 0) can't pick them up. Could a release including these be cut?

Workaround that works today: an SSH loopback tunnel from the client so the dashboard sees a loopback peer:

ssh -N -L 127.0.0.1:9119:127.0.0.1:9119 user@<host>

then point Desktop at http://127.0.0.1:9119.

[obahareth]

I'm facing this too, and relaunchinig the app after it goes in this state makes it infinitely stuck in Connecting.

[isamch]

any one have the solution for this probleme, do i need hermes agent in docker??