Skip to content

fix(dashboard): allow WebSocket connections from non-loopback IPs with --insecure - #17922

Closed
kelsia14 wants to merge 2 commits into
NousResearch:mainfrom
kelsia14:fix/dashboard-ws-insecure
Closed

kelsia14 wants to merge 2 commits into
NousResearch:mainfrom
kelsia14:fix/dashboard-ws-insecure

Conversation

@kelsia14

Copy link
Copy Markdown
Contributor

Problem

The dashboard Chat tab uses WebSocket endpoints (/api/pty, /api/ws, /api/pub, /api/events) that were restricted to localhost only. This prevented the Chat TUI from working when the dashboard is bound to a VPN/Tailscale interface with --insecure.

Solution

  • Add _ALLOW_PUBLIC global to track --insecure flag
  • Check _ALLOW_PUBLIC in all 4 WebSocket endpoints before rejecting non-loopback connections
  • Respect the same security model as HTTP: if user explicitly uses --insecure, WebSocket should follow

Testing

Tested with dashboard bound to Tailscale interface (100.x.x.x) using --insecure --tui flags. Chat TUI now connects and remains stable over WebSocket.

Security Note

This change respects the existing --insecure security model. When --insecure is not used, WebSocket connections remain restricted to localhost.

…h --insecure

The dashboard Chat tab uses WebSocket endpoints (/api/pty, /api/ws,
/api/pub, /api/events) that were restricted to localhost only. This
prevented the Chat TUI from working when the dashboard is bound to a
VPN/Tailscale interface with --insecure.

Changes:
- Add _ALLOW_PUBLIC global to track --insecure flag
- Check _ALLOW_PUBLIC in all 4 WebSocket endpoints before rejecting
  non-loopback connections
- Respect the same security model as HTTP: if user explicitly uses
  --insecure, WebSocket should follow
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/cli CLI entry point, hermes_cli/, setup wizard labels Apr 30, 2026
@alt-glitch

Copy link
Copy Markdown
Contributor

Likely duplicate of #17887 — same root cause: WebSocket endpoints don't check --insecure flag for non-loopback connections. Also see #17440.

@alt-glitch

Copy link
Copy Markdown
Contributor

Likely duplicate of #17887 — same root cause: WebSocket endpoints don't check --insecure flag for non-loopback connections.

@kelsia14

Copy link
Copy Markdown
Contributor Author

Closing as duplicate of #17887. Thanks for the heads up!

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

Labels

comp/cli CLI entry point, hermes_cli/, setup wizard P2 Medium — degraded but workaround exists type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants