[Bug]: Desktop Remote gateway shows legacy session-token field, not username/password Sign In — can't connect to basic-auth backend

[bsubedi26]

Summary

Settings → Gateway → Remote gateway only offers a Remote URL field and blocks Save with "Remote gateway incomplete.

Enter a remote URL and session token before switching to remote." There's no username/password Sign In option, even though the target backend has basic auth enabled and serves a proper Sign In (username/password) page when hit directly in a browser.

Environment

Desktop version: Version 0.18.2 (0.17.0)
OS: macOS (Apple Silicon)
Backend: official Docker image nousresearch/hermes-agent:latest, version 0.18.2, started via gateway run with HERMES_DASHBOARD=1
Backend auth: HERMES_DASHBOARD_BASIC_AUTH_USERNAME / _PASSWORD / _SECRET set; confirmed via curl http://:9119/api/status.

Steps to Reproduce

Backend running on a LAN host (Linux), port 9119 reachable.
On macOS, open Hermes Desktop → Settings → Gateway.
Select "Remote gateway", enter http://:9119 as Remote URL.
Click "Save and reconnect".

Expected Behavior

Per the docs (Web Dashboard / Desktop guides) and the 0.17.0 "Surface Release" notes, Desktop should probe /api/status, detect auth_providers: ["basic"], and present a username/password Sign In (same flow as /login in the browser) — no manual token entry required.

Actual Behavior

Panel shows only a Remote URL field and the message "Could not reach this gateway yet. Check the URL — the auth method will appear once it responds."

Clicking Save immediately throws "Remote gateway incomplete: Enter a remote URL and session token before switching to remote." with no request ever attempted — desktop.log remains 0 bytes after the click.

Opening the same URL directly in Safari works correctly and renders the full username/password Sign In page ("PUBLIC BIND · AUTH REQUIRED").

Test remote button is greyed out / non-interactive.

Ruled out macOS Local Network permission — not listed under System Settings → Privacy & Security → Local Network, and tccutil reset LocalNetwork (with and without sudo) fails with "tccutil: Failed to reset LocalNetwork".
Confirmed backend itself is healthy and reachable (curl to /api/status returns full JSON with gateway_running: true).

Fully uninstalled (~/.hermes, ~/Library/Application Support/Hermes, ~/.local/bin/hermes removed) and reinstalled fresh — same behavior persists.

Additional notes
This looks like the client never successfully completes the /api/status reachability probe from the Electron process, so it never learns auth_providers and falls back to a legacy token-entry UX that has no matching input field, making Remote gateway mode unusable against a basic-auth backend from this build.

Affected Component

Other, Setup / Installation

Messaging Platform (if gateway-related)

No response

Debug Report

n/a

Operating System

macOS 26.5.1

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

[tazmaniax]

Additional reproduction from a separate macOS setup, with socket-level evidence that may help remove the needs-repro label:

Environment

• Hermes Desktop: 0.17.0
• Remote Hermes backend: 0.19.0
• macOS on Apple Silicon
• Backend behind an HTTPS reverse proxy on the same LAN, using basic/password auth

Confirmed behavior

• The Desktop remote-gateway probe fails before HTTP with:

  connect EHOSTUNREACH <LAN-gateway-IP>:443 - Local (<client-LAN-IP>:<ephemeral-port>)
  

• Connecting directly to the backend's private LAN address/port fails identically, so this is not specific to the reverse proxy or Caddy route.
• From another already-authorized process on the same Mac, GET /api/status succeeds and reports:
  • overall: "ok"
  • auth_required: true
  • auth_providers: ["basic"]
• Hermes does not appear in System Settings → Privacy & Security → Local Network, and no Local Network permission prompt is shown.
• Because /api/status is never reached, Desktop cannot discover basic auth and falls into the incomplete legacy session-token state described in this issue.

Packaging finding

The current desktop packaging config declares microphone/audio usage descriptions under build.mac.extendInfo, but does not declare NSLocalNetworkUsageDescription:

https://github.com/NousResearch/hermes-agent/blob/main/apps/desktop/package.json

Apple documents that apps making direct unicast connections to local-network addresses should declare this key:

https://developer.apple.com/documentation/bundleresources/information-property-list/nslocalnetworkusagedescription

Adding the key to a local build makes the declaration appear in Info.plist, but an ad-hoc-signed build still does not receive a stable Local Network permission entry. That is consistent with Apple's guidance that Local Network Privacy depends on stable code-signing identity:

https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy

As a further control, an identical small Node relay:

• succeeds when run from a process that already has LAN access;
• fails with the same EHOSTUNREACH when run by launchd.

That strongly points to macOS Local Network Privacy/process identity, rather than DNS, routing, TLS, reverse-proxy configuration, or backend health.

Proposed fix

1. Add to build.mac.extendInfo:

   "NSLocalNetworkUsageDescription": "Hermes connects to Hermes gateways on your local network."

2. Ensure release artifacts retain this key and are signed/notarized with Hermes' stable release identity.
3. Add a packaging test that asserts the built app's Info.plist contains the key.
4. Surface the underlying EHOSTUNREACH/Local Network permission failure instead of asking for a session token when auth discovery never ran.