Skip to content

feat(console): serve apple-app-site-association for iOS pair links - #58540

Merged
kitlangton merged 1 commit into
devfrom
ios-pair-links
Oct 25, 2026
Merged

kitlangton merged 1 commit into
devfrom
ios-pair-links

Conversation

@kitlangton

Copy link
Copy Markdown
Contributor

What it does. https://opencode.ai/pair#… links (the pairing links opencode pair prints) open in Safari today. This serves an Apple App Site Association file so iOS opens them in the OpenCode iOS app instead. Only /pair and /pair/* open the app; every other opencode.ai URL keeps opening in the browser.

How it works.

  1. The console middleware answers GET/HEAD /.well-known/apple-app-site-association with the JSON below, Content-Type: application/json, no redirect, before any other handling.
  2. It lives in middleware because SolidStart's file router skips dot directories (fast-glob without dot), and a static file in public/ would be served without an extension as application/octet-stream.
{"applinks":{"details":[{"appIDs":["5NZ4Q7NXJ4.ai.opencode.mobilecode"],"components":[{"/":"/pair","comment":"pairing links, payload in the fragment"},{"/":"/pair/*"}]}]}}

The app side (applinks:opencode.ai entitlement and the /pair#<base64url {"code","urls"}> handler) is already shipping in the iOS app.

Risk. Small: one exact path in the opencode.ai console worker. Nothing else changes, and /pair itself still 404s in a browser. Apple's CDN caches AASA files, so devices pick this up within about a day of deploy. To check after deploy:

curl -si https://opencode.ai/.well-known/apple-app-site-association
curl -s https://app-site-association.cdn-apple.com/a/v1/opencode.ai

Proof.

  • bun test in packages/console/app: 49 pass, including new test/appleAppSiteAssociation.test.ts (body, content type, HEAD, other paths and methods ignored).
  • bun run typecheck:tsc: pass. bun run build: pass.
  • Built worker under wrangler dev: GET /.well-known/apple-app-site-association → 200, Content-Type: application/json, the JSON above; /pair → 404 as before.

@opencode-agent opencode-agent Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I ran the console app with vite dev on the base and on this branch. On the base, /.well-known/apple-app-site-association returns 404 (HTML). On this branch, GET returns 200 with application/json and the expected AASA JSON, HEAD returns the same headers with no body, and /pair still returns 404. bun test (49 pass) and typecheck:tsc both pass. Handling this first in the middleware, before locale and redirect handling, is the right place given that the file router skips dot directories.

Public API: unchanged (no SDK, server API, CLI, config or plugin surface). The site now serves one new public URL on opencode.ai, which only affects how iOS opens /pair links.

No blocking concerns.

@kitlangton
kitlangton merged commit 71d29ef into dev Oct 25, 2026
13 checks passed
@kitlangton
kitlangton deleted the ios-pair-links branch October 25, 2026 22:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant