feat(acp): opt-in toggle to allow insecure ws:// for local agents

[aatchison]

Why

A user running a local ACP agent binary connects over cleartext ws://127.0.0.1:<port>. Today the custom-agent dialog accepts ws:// unconditionally (only iOS blocks it). This makes that an explicit, default-off opt-in instead — secure wss:// is required unless the user knowingly enables insecure local agents.

What

• local-settings-store: new persisted allowInsecureAcp (default false).
• validateAgentUrl: now takes { isIos, allowInsecure }; rejects ws:// by default with a clear message ("Enable 'Allow insecure local agents' in Developer Settings"). wss:// always allowed; iOS still rejects ws:// regardless (Apple ATS).
• Add-custom-agent dialog: reads the setting and passes it through.
• Developer Settings → Agents: a toggle to enable it (with a localhost/local-binary explanation).
• Tests: updated for the new signature + gating (default-deny, opt-in allow, iOS-still-rejects).

bun run type-check clean, eslint clean, 24/24 dialog tests pass.

Base

Stacked on #967 (coding-agent-broker-provider) — that's where the remote-ACP provider + this validation live; there's no ACP code on main yet. Re-targets main once #967 lands. Pairs with the local shim binary (https://github.com/thunderbird/thunderbolt-coding-agent/pull/115).

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes agent connection URL policy (cleartext WebSocket), but risk is mitigated by default-off opt-in, developer-only toggle, and unchanged iOS ATS rules.

Overview
Cleartext ws:// custom ACP agent URLs are off by default; wss:// stays allowed everywhere. Users can enable “Allow insecure local agents” in Developer Settings for localhost-style agents (e.g. ws://127.0.0.1).

A persisted allowInsecureAcp flag (default false) is added to the local settings store. validateAgentUrl now takes { isIos, allowInsecure } and rejects ws:// unless opted in, with copy pointing to Developer Settings; iOS still blocks ws:// even when opted in (ATS). The add-custom-agent dialog reads the setting and passes it into validation. Tests cover default-deny, opt-in allow, and iOS behavior.

^{Reviewed by Cursor Bugbot for commit 26029c1. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Semgrep Security Scan

No security issues found.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 26029c1. Configure here.}

[cursor]

Add stays enabled after opt-in off

Low Severity

canSubmit still keys off a prior successful connection test, but URL validity now also depends on allowInsecureAcp. If the user disables “Allow insecure local agents” while the dialog still has a tested ws:// URL, the inline error appears yet Add Agent can remain enabled; handleSubmit then no-ops without feedback.

 

^{Reviewed by Cursor Bugbot for commit 26029c1. Configure here.}

[github-actions]

PR Metrics

Metric	Value
Lines changed (prod code)	+48 / -6
JS bundle size (gzipped)	🟡 682.3 KB → 727.0 KB (+44.7 KB, +6.6%)
Test coverage	🟡 78.09% → 76.71% (-1.4%)
Performance (preview)	Preview not ready — Render deploy may have timed out
Accessibility	—
Best Practices	—
SEO	—

Updated Tue, 16 Jun 2026 22:23:26 GMT · run #1929

[cjroth]

Thoughts:

• This would only work on desktop because the browser will block ws:// due to insecure mixed content
• This is probably something regular (non-dev) users will run into when running local agents
• Can we remove the toggle and instead just allow ws:// but show a warning under the text input if it's ws:// that says something like "This is an insecure URL, only proceed if you know what you are doing"?
• I can't recall if we added the connection check when adding ACP agents, but we should confirm that it works in desktop + web for ws:// as well as wss://