Programmatic releases — four ways to present the setting

The control removes a security guarantee, is changed rarely, and flipping it costs a confirmation dialog plus a hardware key tap. Each alternative below optimizes for a different reading of that: mockups are shown in the dashboard's light theme, in the risky (enabled) state where the designs differ most.

Baseline

Current design

  • The label sits far from the switch it names — on wide screens the eye has to bridge the whole card (proximity).
  • The switch uses the brand color when enabled, visually rewarding the less-secure state.
  • The rule "changing this always requires a tap" is buried in the paragraph, and there's no record of who enabled it.
As shipped
Programmatic releases
Allow releases without a security token
✓ When enabled, this app can be released programmatically (e.g. todesktop release in CI) without a security-token tap. Changing this setting always requires a security-token tap.
Option A

Settings row — smallest change

The standard settings-row shape: bold label with its description stacked beneath it, control on the right. Two behavioral tweaks: the switch turns amber when on (state = caution, not brand success), and a small key hint under the switch sets the expectation of a WebAuthn prompt before the browser suddenly shows one.

  • Fixes proximity and scan order without inventing a new pattern.
  • One-line diff conceptually — keeps the Switch and all current logic.
Enabled state
Programmatic releases
Allow releases without a security token
Lets todesktop release and the API release this app without a security-token tap — useful for CI.
✓ Changes need a key tap
Option B

Status-first, button-driven — honest about the ceremony

A toggle promises an instant, reversible flick — but this control opens a confirmation modal, then demands a hardware tap, and snaps back if either fails. A status pill plus a button with an ellipsis ("Allow…") matches that interaction cost, and the pill makes the security posture readable at a glance. Room for the audit trail the API already stores.

  • State reads as Protected / Unprotected, not on/off.
  • "Enabled by dave@todesktop.com on 3 Jul 2026" — accountability for a shared team setting.
  • Needs the audit fields (updatedAt, updatedBy) exposed on the read endpoint.
Protected (default)
Programmatic releases
Security token required
Every release needs a physical security-token tap. todesktop release and API releases are blocked.
Allow releases without a token…
Bypass enabled
Programmatic releases
Releases don't require a token
Anyone with a valid access token can release this app from CI or the API — no key tap.
Enabled by dave@todesktop.com · 3 Jul 2026
Require security token
Option C

Security card with a live warning — the setting confesses

Keep the switch, but when the bypass is on, the card grows a persistent amber alert that restates the consequence and carries the audit line. The risk isn't only visible during the confirmation modal — it's visible every time anyone opens settings. Pairs well with renaming the card "Security" if more security settings accumulate later.

  • The warning is state, not ceremony — it persists as long as the risk does.
  • Familiar from GitHub's danger-zone vernacular, but calmer: amber, not red, since this is a sanctioned trade-off.
Enabled state
Programmatic releases
Allow releases without a security token
For CI pipelines that run todesktop release unattended.
✓
This app can be released without a security-token tap. Enabled by dave@todesktop.com on 3 Jul 2026.

Recommendation

Option B is the best fit for what this control actually is: a rare, deliberate security decision made on behalf of a team. The button stops the switch from lying about interaction cost, the pill gives the page a glanceable security posture, and the audit line adds accountability. If you want to ship without touching the API, Option A is a 20-minute change and fixes the two biggest issues (proximity, reward-colored risk); C's persistent alert can be layered onto either later.