tui: require explicit confirmation when starting external server on non-loopback without OPENCODE_SERVER_PASSWORD

[MaxMiksa]

Description

The TUI entrypoint (opencode / tui thread) can start an external HTTP server when network options are configured (e.g. --hostname, --port, --mdns, or global config). This uses a worker RPC call to server.listen(...).

If OPENCODE_SERVER_PASSWORD is unset, this server runs unauthenticated. Unlike serve and web, the TUI path currently has no guardrail for the insecure + non-loopback case.

Suggested fix

Apply the same guardrail as serve/web:

• If hostname is non-loopback and OPENCODE_SERVER_PASSWORD is unset:
  • On TTY: prompt for confirmation (default No).
  • On non-TTY: refuse to start unless --yes is provided.

Steps to reproduce

1. Ensure OPENCODE_SERVER_PASSWORD is unset.
2. Start TUI with external server enabled, e.g. opencode --hostname 0.0.0.0 (or configure global server.mdns=true).
3. Observe the HTTP server starts unauthenticated.

Environment

• OS: Windows 11
• Terminal: Windows Terminal

[github-actions]

This issue is part of a series of related security improvements. Related issues applying similar guardrails to other entry points:

• serve: require explicit confirmation when binding non-loopback without OPENCODE_SERVER_PASSWORD #10948: serve: require explicit confirmation when binding non-loopback without OPENCODE_SERVER_PASSWORD
• web: require explicit confirmation when binding non-loopback without OPENCODE_SERVER_PASSWORD #10958: web: require explicit confirmation when binding non-loopback without OPENCODE_SERVER_PASSWORD

These are related enhancements rather than duplicates, as they address the same security concern across different entry points (TUI, serve, and web).

[github-actions]

To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.