Allow alphaXiv login completion from a different device - #280
Open
gh0stwin wants to merge 6 commits into
Open
Conversation
* Make alphaXiv OAuth login work across devices The login flow previously assumed the browsing device and the token-storage device were the same machine: the callback server always bound 127.0.0.1:9876 and the redirect URI was fixed. Inside Docker the published port could not reach a loopback-only bind, and a browser on another device could never complete the flow. Client-side changes, applied to the bundled alpha-hub auth source: - ALPHAXIV_CALLBACK_PORT / ALPHAXIV_CALLBACK_HOST / ALPHAXIV_CALLBACK_BIND configure the callback port, redirect host, and bind address. Loopback hosts keep http and bind themselves; any other host uses https (the authorization server only accepts http for loopback) and defaults to binding 0.0.0.0. - Login now also accepts a pasted redirect URL: complete the sign-in anywhere, then paste the final 127.0.0.1:...?code=... address into the waiting CLI, which validates state and extracts the code. - The wait window extends from 120 seconds to 10 minutes for cross-device sign-in, and the wait timer is unref'd so a completed login no longer hangs the process. - A closed stdin no longer settles the wait with a null code; the normal same-device browser flow is unchanged. Behavioral tests execute the patched module with stubbed dependencies: redirect-URL parsing, host/port/bind configuration, the same-device browser callback, the paste fallback, bad-paste recovery, and piped stdin. Docs parity in RELEASES.md and the website alphaXiv guide. * Restrict alphaXiv callback redirect to loopback http only * Reject non-loopback alphaXiv callback host values * Keep the 120-second login wait and lead the PR with cross-device completion Per captain: the 10-minute wait window is dropped - the upstream 120-second login wait stays exactly as it was. The only remaining addition to the wait is an unref'd timer so a login completed through the paste path does not keep the process alive until the timer fires. The piped-stdin fix is retained. Docs now lead with the new capability: cross-device login completion was not possible before, and pasting the browser's final redirect URL is the universal path (zero network assumptions - the redirect URI is the token device's own loopback, which is why a remote browser can never reach the callback directly). The SSH reverse tunnel is documented as the hands-free option, and the callback port/bind configuration becomes supporting detail. * Drop the unref'd wait-timer tweak and keep the exact 120-second upstream wait the login wait returns to upstream's exact form - no extended window, no unref'd timer. The piped-stdin fix is retained. * Return promptly after a completed alphaXiv login by clearing the abandoned callback wait * Fix IPv6 loopback redirect/bind and EADDRINUSE retry detection in alphaXiv login
…etup (#1) * Add built-in model spec catalog to custom API-key provider setup feynman setup / feynman model login for custom API-key providers now pre-fills editable defaults (context length, max completion tokens, supported reasoning efforts) from a typed, reviewable static catalog covering OpenAI GPT, Anthropic Claude, Google Gemini, DeepSeek, Kimi, GLM, Qwen, MiMo, Hunyuan 3/4, MiniMax, and Nemotron. Unknown model ids prompt with safe fallbacks; every catalog value stays user-overridable, and pre-existing saved configs that omit the fields keep Pi's fallbacks. Runtime semantics verified against Pi's getSupportedThinkingLevels: null mappings are honored as unsupported, so unselected efforts are pinned to null. Token input accepts 128000 as well as 128k/1m forms. * Restrict spec catalog to open-weight families Per latest captain word: closed-weight models (GPT, Claude, Gemini, Grok) no longer appear in the built-in catalog at all - their providers ship their own runtime model registries, so their ids simply miss the catalog and prompt at setup with safe fallbacks. The catalog now carries the open-weight families only: DeepSeek, Kimi, GLM, Qwen, MiMo, Hunyuan, MiniMax, and Nemotron. Generic thinking-level-map and effort-derivation semantics are unchanged. * Forward reasoning effort at first-party endpoints via compat overrides * Document new setup per-model limit prompts in setup.md * Correct GLM aliases and add qwen3.8-flash-next with doc-verified specs Remove the aliases glm-5.3-highspeed and glm-5.2-highspeed: the captain verified those model ids do not exist, so setup would have mis-recognized them as the base rows. glm-5.3-flash and all other real aliases stay. Give qwen3.8-flash its own row with official Model Studio values (1,000,000 context, 131,072 max output) instead of nesting it under qwen3.8-max, and add qwen3.8-flash-next as its own entry per the official Qwen3.8-Flash-Next card: 262,144 native context (1,000,000 only via self-hosted YaRN scaling), 131,072 recommended final-response output, reasoning efforts xhigh (default) / medium / low. * Scope per-model limit prompts to custom API-key provider flow only * Make modelDefinitions optional to restore build * Fill catalog limits from cited hosted catalogs Fill contextWindow and maxTokens for every KNOWN_MODEL_SPECS row the vendor docs leave silent, citing the public hosted catalogs per the captain's verified readout (DeepInfra /v1/openai/models and Novita model metadata, both read 2026-09-08): DeepSeek 1048576/1048576, Kimi K3 1048576/1048576, K2.6/K2.7-Code 262144/262144, K2-0905 and K2-0711 100352 output (Novita), GLM-5.2 1048576/131072, GLM-5.1 202752/202752 (captain-cited DeepInfra values), Qwen3.8-Max 1000000/131072 (Novita, consistent with the official flash family), MiMo 131072 output, Hunyuan Hy3 262144 output, MiniMax M3/M2.7 131072 output, Nemotron Super/Ultra 262144 output. Hosted deployments disagree in places (Novita vs DeepInfra on DeepSeek/GLM-5.1/Qwen-Max output caps); the row comments name which source backs each value and where a conflicting deployment differs. Rows with no traceable source anywhere (Hunyuan Hy4, Nemotron Nano Omni) keep the prompt fallback and say so. * Refine setup.md sourcing wording to include hosted catalogs * Update spec-catalog.ts * Align spec-catalog tests with 33b19b3 values
…he pasted address
|
@gh0stwin is attempting to deploy a commit to the Advait Paliwal's projects Team on Vercel. A member of the Team first needs to authorize it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes
Completing the alphaXiv sign-in from a different device was not possible before: the login flow hard-assumed the browser device and the token-storage device were the same machine, so running Feynman in Docker (or anywhere the browser is not on the same host) made
feynman alpha loginunusable. This change creates the missing workflow, all changes are in the client-side in the bundled alpha-hub auth source.Paste the redirect URL (the headline; works everywhere, no network setup).
Run
feynman alpha login, complete the sign-in on any device you like, then paste the browser's final address —http://127.0.0.1:9876/callback?code=...into the waiting CLI. The page may fail to load on the browsing device, but the address bar still holds the URL; the CLI validates the OAuthstate, extracts the code, exchanges it, and stores credentials on the device runningfeynman.This path has zero network assumptions: the redirect URI is the token device's own loopback, which is exactly why a remote browser can never reach the callback directly — and why the paste path exists. The same-device browser flow is unchanged; the paste prompt simply coexists with it. Press Ctrl-C to cancel.
Supporting details
ALPHAXIV_CALLBACK_PORT(default9876) — callback port used in both the redirect URI and the server bind.ALPHAXIV_CALLBACK_BIND(default: the loopback callback host) — e.g.0.0.0.0inside Docker sodocker run -p 9876:9876delivers the redirect.ALPHAXIV_CALLBACK_HOSTis loopback-only (localhost,127.x,::1); a non-loopback value is rejected at startup with an error pointing to the paste path. The redirect URI is alwayshttp, because the alphaXiv authorization server only acceptshttpredirect URIs for loopback hosts. No TLS is terminated locally.ssh -R 9876:127.0.0.1:9876 user@browsing-device) makes the automatic callback completion work across devices with no pasting.Tests
Behavioral tests execute the real patched auth module with stubbed dependencies and a real HTTP server: redirect-URL parsing and rejection, host/port/bind configuration (including loopback-only rejection of non-loopback hosts), state-mismatch rejection, the unmodified same-device browser flow, the cross-device paste flow, recovery from a bad paste, and graceful handling of closed piped stdin. The patched source remains verified byte-for-byte against the asserted
patchedSha256.Docs
website/src/content/docs/tools/alphaxiv.md: new "Logging in from another device" section, paste-first, with the SSH tunnel variant and the env-var table.RELEASES.md: Unreleased entry leading with the cross-device completion capability.