Feature: configurable pi-web bind address, allowed hosts, and password

[Ran-Xing]

Summary

Please make the desktop app's bundled pi-web network settings configurable instead of always binding the server to 127.0.0.1.

The requested use case is exposing Pi Agent through an HTTPS reverse proxy at pi.xrsec.fun, with pi-web's existing host validation and Basic Auth enabled.

Current behavior

Pi Agent Desktop 0.4.1 starts the bundled Next.js server on a dynamically selected port, but the desktop launcher hard-codes the listen address to 127.0.0.1.

The persisted desktop preferences currently only contain:

{
  "serverPort": 38471
}

The bundled pi-web server already supports:

• PI_WEB_ALLOWED_HOSTS
• PI_WEB_PASSWORD
• PI_WEB_HOSTNAME

However, there is currently no supported desktop preference or launch configuration for passing these values to the child server, and no setting for changing the bind/listen address.

Requested behavior

Add supported desktop configuration for:

1. Listen/bind address, e.g. 0.0.0.0
2. Allowed hosts, e.g. pi.xrsec.fun
3. PI_WEB_PASSWORD for pi-web Basic Auth

For example, either extend ui-prefs.json:

{
  "serverPort": 38471,
  "serverHost": "0.0.0.0",
  "allowedHosts": ["pi.example.com"]
}

and store the password in macOS Keychain / the platform credential store, or provide an officially documented environment-variable/configuration mechanism inherited by the bundled server.

Security expectations

• Keep 127.0.0.1 as the default.
• Require an explicit opt-in before binding to a non-loopback address.
• When binding to a non-loopback address, require or strongly enforce PI_WEB_PASSWORD.
• Preserve PI_WEB_ALLOWED_HOSTS validation.
• Prefer HTTPS through a trusted reverse proxy/VPN; warn against exposing Basic Auth over plain HTTP.
• Do not persist the plaintext password in ui-prefs.json; use the OS credential store or another secret-safe mechanism.

Environment

• Pi Agent Desktop: 0.4.1
• Bundled pi-web: 0.8.7
• macOS arm64

[xuzijian2019]

I think the direction is reasonable and worth accepting, but overall changes would be quite big. I can start the PR prototype if all looks good. @abcwyc , could you please let us know how this looks?

Implementation could land in two stages:

• Stage 1 (cheap): a documented, supported way to pass PI_WEB_PASSWORD / PI_WEB_ALLOWED_HOSTS through to the bundled server. The child process already inherits the parent environment, but that's impractical when launched from Finder/Dock on macOS, so this would need an official mechanism (e.g. a config file read at launch) plus docs.
• Stage 2: a GUI/config opt-in for the bind address, with the password stored in the OS keychain rather than ui-prefs.json, host validation preserved, and the WebView still connecting over 127.0.0.1.