Network access dialog warns about the restart, and marks disabling (not enabling) as destructive

Summary

The confirmation dialog for Settings → Network access warns about the restart, not about what the setting does. And it styles disabling network access as the destructive action, not enabling it.

Steps to reproduce

1. Desktop app → Settings → Connections → Network access.
2. Toggle it on.
3. Read the confirmation dialog.

Expected behavior

The dialog for widening an environment from this-machine-only to reachable-by-the-network says what that means for the person deciding.

Actual behavior

apps/web/src/components/settings/ConnectionsSettings.tsx:3247-3249

Enable network access?
T3 Code will restart to expose this environment over the network.

The only consequence named is the restart. And at :3260-3262 the destructive button variant is applied to the local-only branch:

variant={
  pendingDesktopServerExposureMode === "local-only" ? "destructive" : "default"
}

so the red, "are you sure" styling appears when the user narrows exposure, and the neutral default styling when they widen it. The visual hierarchy points the opposite way from the risk.

Once enabled, the row's description is "Exposed on all interfaces." (:3078-3079) — accurate, and still purely factual.

The asymmetry

The project has already written the right sentence. It is just in the docs:

docs/user/remote-access.md:288

Anyone with a valid pairing credential can create a session until that credential expires or is revoked.

Nothing of that character appears in the app. Searching both client apps for the phrasings that would carry it:

phrase	apps/web/src	apps/mobile/src	docs/
"like a password"	0	0	0
"Anyone with this"	0	0	0
"grants full"	0	0	0
"full access"	0	0	1
"run any command"	0	0	0

The Create pairing link dialog (:1094-1098) has the same shape:

Generate a one-time link that another device can use to pair with this backend as an authorized client.

The per-scope descriptions below it are neutral capability labels — "Use terminals — Create terminals and send input to running shells." The one place the app does editorialize is the AuthAccessWriteScope warning at :1163-1165 ("This client can create or revoke access for other devices"), which shows the pattern already exists and is just applied to one scope out of eight.

Impact

The people who read docs/user/remote-access.md are not the people who most need line 288. Someone toggling a switch in a settings panel is making the decision the doc describes, without the doc in front of them. This is a copy change, not an architecture change.

Suggested fix

• In the enable-branch of the exposure dialog, say who can then reach the environment and that pairing credentials are what gate it.
• Swap the destructive variant to the network-accessible branch, or drop it from both — as written it teaches the wrong instinct.
• Consider carrying remote-access.md:288's sentence into the pairing-link dialog, next to the scope list it describes.

Version

d7cf8aaa (main).

---

Noting CONTRIBUTING.md routes proposals to Ideas Discussions. Filing here since the button-variant inversion is a straightforward UI defect; happy to move the copy suggestions if you would prefer them there.

Start in apps/web/src/components/settings/ConnectionsSettings.tsx at lines 3247-3262, then read docs/user/remote-access.md:288 and the pairing-link dialog around lines 1094-1098 and 1163-1165. Verify the enable dialog explains network exposure and credential-gated access, the destructive styling matches the risky branch, and the relevant settings dialogs display the intended wording.