Remote access is split across `kimi web --host` and Remote Control: dead flags, duplicated entry points, inconsistent hardening

Summary

kimi web --host and Remote Control both expose the same web UI to remote devices, but they are wired as two separate features with overlapping entry points, dead CLI flags, duplicated startup code, and inconsistent hardening. This is fine today but will get harder to maintain as more server options are added.

Findings

1. Six entry points for one feature

• kimi rc, kimi remote (alias), kimi web --rc, kimi web --remote-control (apps/kimi-code/src/cli/sub/web/index.ts, run.ts)
• /remote-control, /rc in the TUI (apps/kimi-code/src/tui/commands/registry.ts)
• plus the POST /api/v1/remote-control toggle from the web UI

2. kimi rc advertises server flags it cannot use

buildWebCommand mounts every server option on the rc command too:

• --host and --dangerous-bypass-auth are rejected at runtime (run.ts handleWebCommand), yet show up in kimi rc --help.
• --allowed-host, --insecure-no-tls, --allow-remote-shutdown only matter for non-loopback binds (packages/kap-server/src/start.ts). rc forces loopback, so they are silent no-ops.

3. --insecure-no-tls is dead everywhere

It is declared with default true and no --no-insecure-no-tls negation, so the "refuse non-loopback bind without TLS" check in startServer can never trigger from the CLI. Either drop the flag or make the default false.

4. Duplicated Remote Control startup code

handleRemoteControlCommand in apps/kimi-code/src/tui/commands/web.ts re-implements the onReady block of run.ts almost verbatim (token read, startRemoteControl, QR generation, pending-status queue, banner). The only difference is the session deep link.

5. Two independent tunnel starters in the same process

startServer always creates its own createRemoteControlManager, while the CLI calls startRemoteControl directly. They are only kept from colliding by the machine-wide lock file. With kimi rc, the web UI toggle returns REMOTE_CONTROL_ALREADY_RUNNING for a tunnel the same process owns.

6. Hardening asymmetry

On a non-loopback bind the server disables terminals, debug endpoints and remote shutdown and enables the auth-failure limiter (start.ts). Remote Control keeps the server on loopback, so none of these apply even though the UI is reachable from the public internet through the relay. Remote Control therefore exposes a wider surface than --host does. This should at least be a deliberate, documented decision.

7. Docs wording

• docs/en/guides/remote-control.md says kimi web --remote-control "exposes it to the public internet"; technically it is a relay tunnel, no port is opened.
• docs/en/release-notes/changelog.md (0.x entry for --host) says --host can "expose the server to the internet"; it binds 0.0.0.0, reachability depends on NAT/firewall.

Suggestion

Treat remote access as one feature with two transports (direct bind vs relay). Concretely:

• Register only the relevant flags on kimi rc (or model it as a mode of kimi web and drop the separate command).
• Remove or fix --insecure-no-tls.
• Share the Remote Control startup routine between run.ts and the TUI command.
• Let the CLI use the server's RemoteControlManager instead of a second startRemoteControl path.
• Decide whether Remote Control should inherit the non-loopback hardening (terminals, shutdown, limiter) and document the choice.

Start with apps/kimi-code/src/cli/sub/web/index.ts and run.ts, then compare apps/kimi-code/src/tui/commands/web.ts and packages/kap-server/src/start.ts. Trace the existing Remote Control startup, server flags, tunnel manager, and non-loopback hardening before choosing the shared design. Done means one coherent remote-access model, no dead or misleading flags, no duplicated startup path, deliberate hardening, and corrected wording in the two listed documentation files.