Design local CLI/operator access for secure reverse-proxy daemon binds

[Aaronontheweb]

Summary

Secure reverse-proxy mode currently requires the daemon to reject loopback final hops and bind to a non-loopback internal IP, but local CLI/operator flows still assume loopback-local trust.

Problem

DaemonApi.ResolveEndpoint() still defaults local CLI traffic to http://127.0.0.1:5199 unless a client override exists, while LoopbackAuthenticationHandler returns NoResult in reverse-proxy mode and SessionHub.GeneratePairingCode() explicitly requires LocalProcess.

This creates an unresolved product/design gap for daemon-host operators when the daemon only binds a non-loopback internal IP:

• netclaw daemon pair may no longer have a valid local operator auth path
• local health/status flows may need different endpoint resolution rules
• any fix must preserve the fail-closed trust boundary that rejects loopback final-hop proxying

Why this is follow-up work

The current PR/change is about exposure validation, trusted proxy handling, tunnel process checks, and startup/onboarding failure surfacing. Solving local operator access in secure reverse-proxy mode needs an explicit product/security decision, not an implicit implementation tweak.

Questions to answer

1. What is the supported local-operator auth path when ExposureMode=reverse-proxy?
2. Should local CLI commands resolve to the configured daemon bind address automatically, or stay on explicit client overrides only?
3. Should daemon-host operator workflows use bearer auth, a separate local-only scheme, or an explicitly documented SSH/container-only path?
4. Which commands must remain usable from the daemon host without prior remote pairing?

Proposed next steps

• Open an OpenSpec change for this behavior before implementation
• Decide local operator trust/auth model for secure reverse-proxy mode
• Update CLI endpoint resolution, hub/operator flows, and operator docs/skills together
• Add integration coverage for daemon-host local CLI behavior under reverse-proxy

[Aaronontheweb]

Related follow-up filed: #868\n\n#868 tracks the broader transport-vs-auth design question for reverse-proxy and tunnel deployments. This issue remains scoped to daemon-host local CLI/operator access once that model is clarified.