iOS Error
That confirms the iOS app needed the daemon endpoint origin fix, not more Tailscale work. I’ll leave the current setup as-is:
- Tailscale Serve -> tokenless mobile server on
127.0.0.1:3000 - Cave daemon running
ts.netorigin allowed for daemon API calls
- Tailscale Serve -> tokenless mobile server on
- That makes sense. Safari likely primed the Tailscale/cert/session path, then the app’s requests started resolving cleanly. Net result: desktop config is fixed and the phone can connect.
Yes. This is a real bug. What likely happened:
- The app could reach the desktop, but daemon startup/status was stuck behind the bad
forbidden originpath. - After I patched the origin rule, Safari was the first client to successfully hit the web UI/API over
https:/...ts.net. - That request triggered or cleared the daemon bootstrap path.
- Once the daemon was running/recognized, the native app worked.
So Safari didn’t fix Tailscale. It accidentally completed a first-run bootstrap step the iOS app should have completed itself, or at least retried cleanly. Bug shape: CovenCave iOS native connect can remain failed until the same desktop URL is opened in Safari once. Expected behavior: native app should perform the same bootstrap/daemon status/start flow, or show a precise actionable error.
- The app could reach the desktop, but daemon startup/status was stuck behind the bad
2 Comments
Sign in to comment
Great debugging work — you've nailed the shape of this bug exactly. The iOS app shouldn't need a browser to complete its first-run daemon bootstrap; it should handle that flow itself and surface a clear, actionable error if it can't. We've filed this internally and it's on the fix list.
Update: native connection refresh and Tailscale recovery paths have improved substantially since this report. A clean first-run device test is still needed to prove the app no longer depends on opening the URL in Safari first, so this remains Under Review rather than being marked fixed without evidence.