CRM-20-Accessibility

Background

First task of the CRM-20 ongoing project (per Talbot’s request when the Maximizer→Twenty migration completed). Twenty is currently only reachable at http://localhost:3000 — local-machine-only. Two asks:

1. Desktop shortcut for one-click local access — done already, see below.
2. Secure remote access from other devices (iPad, Android, other browsers) — planned here, not yet built.

Tasks

• Desktop shortcut with icon for local access
• Decide + implement a secure remote-access approach

---

Claude Response — 2026-07-16

Desktop shortcut — done

~/utils/crm-20/Open-Twenty.ps1 (boots WSL/Docker via wsl -e true if not already running, polls /healthz, opens the default browser) + a Desktop shortcut (“Twenty CRM.lnk”) that invokes it. Talbot approved -ExecutionPolicy Bypass scoped to this one shortcut (asked explicitly — the harness flags that flag as a security-weakening pattern needing sign-off).

Remote access — recommendation, not yet built

Recommended: Cloudflare Tunnel (cloudflared), layered with Twenty’s own login (already real auth, not “simple auth” in the weak sense) plus 2FA if Twenty supports it out of the box. Rationale: fits Talbot’s existing Cloudflare stack (KB deploys already use Cloudflare Pages), no router port-forwarding, TLS handled automatically, and a tunnel only exposes what you explicitly route — nothing else on the LAN is reachable.

Alternative: Tailscale, if Talbot only ever needs his own devices (iPad, Android) and never a “share this link with someone else” use case — simpler to set up, more private by construction (no public hostname at all, just a private mesh network), but each device needs the Tailscale app installed and joined to the same tailnet.

Three real constraints to solve, not just “add a tunnel”:

1. SERVER_URL is baked to http://localhost:3000 in twenty/.env — a public hostname (Cloudflare Tunnel) or tailnet address (Tailscale) needs SERVER_URL changed to match, and the stack restarted, or auth redirects/CORS will break.
2. Containers are restart: always, but WSL itself does not auto-start on Windows boot. Remote access needs the physical machine on + WSL running + Docker up — this is a real operational dependency, not just “add a tunnel and forget it.” Options: a Windows Scheduled Task to launch WSL at login/boot, or accept that remote access only works when Talbot’s desktop happens to be on.
3. This exposes 18,774 real contacts’ PII to the internet (even via tunnel) — “simple auth” must mean real auth over TLS. Do not use HTTP Basic Auth over plaintext, and don’t skip 2FA if Twenty offers it, given the CASL-relevant emailStatus data now in Twenty.

Recommendation for Talbot’s decision

• Cloudflare Tunnel + Twenty’s built-in auth (+ 2FA if available) — my default recommendation
• Tailscale — if remote access is only ever Talbot’s own devices, never shared
• Neither yet — local-only is fine for now, revisit later

Next Steps for Talbot:

• Pick a remote-access approach (or defer)
• If picking one, confirm whether WSL-boot-on-Windows-startup should be set up as a follow-on task (needed either way for remote access to be reliably available)

Talbot Response

---