Skip to content

feat: allow Raycast's OAuth redirect for device sign-in - #1007

Open
chrismessina wants to merge 2 commits into
dev-null-sh:productionfrom
chrismessina:feat/raycast-oauth-redirect
Open

chrismessina wants to merge 2 commits into
dev-null-sh:productionfrom
chrismessina:feat/raycast-oauth-redirect

Conversation

@chrismessina

Copy link
Copy Markdown
Contributor

Summary

The /dev/null Raycast extension posts commits through the CLI endpoint, signed with the user's GitHub SSH key. To show feeds, follow people, star commits and open Remotes, it needs the v1 API, which only accepts a key approved as a device through /mobile/authorize. That page only redirects to devnull://, so the code can't get back to Raycast.

This adds Raycast's OAuth redirect, raycast://oauth?package_name=Extension, to the allowed prefixes. It's the redirect Raycast's own OAuth client uses (OAuth.PKCEClient with RedirectMethod.App). The extension can then sign in the way the app does: it sends its SSH key's fingerprint, a device name and a PKCE challenge, the user approves on the web, and it redeems the code with POST /api/v1/devices, signed by that key.

Changes

  • config/mobile.php: one more entry in redirect_uri_prefixes.
  • MobileAuthorizationControllerTest: a test that approving redirects to the Raycast URL with the code and state added after its existing query. Three expected validation messages are updated, since they list the allowed prefixes.

A code is bound to the key's fingerprint and the PKCE challenge, and redeeming it takes a signature from that key and the verifier, so an app that intercepts the raycast:// callback can't use the code. package_name=Extension is Raycast's fixed placeholder, not the extension's identity; the approval page shows the device name the extension sends.

Validation

Local, on macOS with PHP 8.5.12 and PostgreSQL 18 with pgvector 0.8.7:

  • vendor/bin/pest --parallel: 3,971 passed on this revision.
  • tests/Feature/Controllers/MobileAuthorizationControllerTest.php: 20 passed. With the config line reverted, 4 fail: the new test and the three message tests.
  • pint --test and rector --dry-run on the two changed files: clean. phpstan: no errors.
  • Not run locally: coverage (no pcov) and the bun suites (no JavaScript changed). Hosted CI runs both.

Independent review

Codex reviewed 877532e..736ebfe from source: CODE: PASS. Two non-blocking notes, not changed here:

  • Like devnull://, this is a prefix match, so it also accepts longer URLs that start with the Raycast one. They still need the key and the verifier.
  • The error page says "Start signing in again from the /dev/null app", which reads oddly for someone coming from Raycast.

Source review only: no browser check and no end-to-end Raycast sign-in.

Limitations

  • The extension's sign-in isn't built yet; this unblocks it, so the full flow hasn't run end to end.
  • The approval page's error copy still names the /dev/null app.

chrismessina and others added 2 commits October 22, 2026 14:43
Add raycast://oauth?package_name=Extension, the redirect Raycast's
OAuth.PKCEClient uses (RedirectMethod.App), to the authorize page's
allowed redirect prefixes, so the /dev/null Raycast extension can approve
its SSH key as a device the way the app does.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@chrismessina
chrismessina marked this pull request as ready for review October 22, 2026 23:17
@jubianchi

Copy link
Copy Markdown
Contributor

@chrismessina, config/mobile.php is gone since 5be0cc2 (Oct 27): the allowed redirects are now a pattern in ShowMobileAuthorizationRequest::parameterRules(), which accepts devnull:// and a loopback http://127.0.0.1:<port>. So raycast:// is still refused, but a loopback redirect is now allowed, if the extension can listen on a local port.

#585 also proposes a device code sign-in (RFC 8628), which needs no redirect at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants