Cloud Disconnect: one-click unconfirmed header button fully deregisters the tower — likely cause of repeated cloud drops during uplink flaps #1370

Symptom

Tower dropped its cloud.codevos.ai registration twice today (2026-08-08 18:28:03Z and 20:25:41Z), each requiring a fresh OAuth. The owner experienced this as "the tower keeps disconnecting from cloud — it's been robust until now."

What the log shows (both incidents, identical signature)

Tunnel: connected → disconnected          ← + ~5 rapid connect/disconnect cycles (~60ms apart)
Server-side deregister succeeded for tower <id>
Cloud config removed or invalid, disconnecting tunnel

This is the POST /api/tunnel/disconnect handler signature (tower-tunnel.ts ~443–490): tunnel teardown → server-side DELETE → deleteCloudConfig() → config-watcher notice. Not a network failure and not key revocation:

• The tunnel client treats invalid_api_key/auth_failed as log-and-advise only — it never deregisters (tunnel-client.ts:429).
• The CLI afx tower disconnect deletes the local config before signaling Tower, so the Tower-side handler would find no config and could not log "Server-side deregister succeeded". Both incidents show the config still present when the handler ran → a direct POST.
• Cron sweep across all registered workspaces: no task invokes tower/tunnel commands.
• Active sibling agent sessions in other workspaces were polled and deny issuing it.

The hazard

The only production caller of that POST in the codebase is the dashboard header's cloud control (apps/web/src/components/CloudStatus.tsx:117-125):

• One click, no confirmation, adjacent to the "Open" link.
• In the disconnected state, a Connect button renders in the same header position.

Independent evidence (a sibling workspace's monitors + a cron comment dated 2026-08-04) shows the host uplink has been flapping for days, including a documented outage window overlapping the 20:25Z incident. During a flap the header control flips between Connect and Disconnect under the cursor; a click aimed at Connect/Open can land on Disconnect — and a single unconfirmed click deregisters the tower server-side and deletes local credentials.

Proposed fixes

1. Confirmation dialog on the dashboard Disconnect button (it is a destructive, credential-deleting action; cf. how destructive actions are gated elsewhere).
2. Source attribution logging on POST /api/tunnel/connect|disconnect (remote address, user-agent, and whether the request arrived via the tunnel proxy) so the next incident is attributable from the log alone.
3. Defense in depth: have Tower reject tunnel-proxied requests to /api/tunnel/* management endpoints if that path isn't already blocked — a cloud-side actor should not be able to deregister the tower through its own tunnel.
4. Optional: debounce/disable the header cloud control while the tunnel state is actively flapping (state changed < 2s ago) to remove the click-target swap hazard.