Title
Windows v0.54.0 release still drops Google/GitHub OAuth callbacks after #2469/#2511
Body
Summary
The latest published Windows release (v0.54.0, published 2026-05-19) still reproduces the Windows OAuth callback issue described in #2466: after completing Google or GitHub sign-in in the browser, clicking the "Open OpenHuman" option launches/focuses OpenHuman but the app remains on the welcome/login screen.
This appears to be fixed on main by #2469 and further hardened by #2511, but the latest downloadable Windows installer predates both fixes. Users who uninstall/reinstall from the current release still receive a build that cannot consume the OAuth callback.
Environment
Reproduction
- Install/Open OpenHuman v0.54.0 on Windows.
- Choose the local/native runtime.
- Click Google or GitHub on the welcome screen.
- Complete OAuth in the system browser.
- On the OpenHuman redirect page, choose the option to open OpenHuman.
Expected: OpenHuman consumes the OAuth callback and logs in.
Actual: OpenHuman remains on the welcome/login screen.
Diagnostics
The app is running and healthy:
- Main process is listening on
127.0.0.1:7788, 127.0.0.1:19222, and another local port.
- The WebView remains at
http://tauri.localhost/#/.
- Local storage does not contain auth/session/user keys after the callback.
The Windows protocol handler is registered:
HKEY_CLASSES_ROOT\openhuman
URL Protocol:
openhuman\shell\open\command = "F:\ProgramFile\OpenHuman\OpenHuman.exe" "%1"
During OAuth callback attempts, the log repeatedly shows secondary launches being discarded:
[startup] platform: arch=x86_64 os=windows
[single-instance] pre-CEF mutex held by primary; secondary exiting (OPENHUMAN-TAURI-A fix)
No corresponding auth, oauth, callback, deep-link, or token-consumption log line appears, and the UI state does not change.
Related
Requested action
Could you publish a new Windows release/build that includes #2469/#2511, or reopen/track this as a release packaging issue until the latest public installer contains the OAuth callback fix?
Title
Windows v0.54.0 release still drops Google/GitHub OAuth callbacks after #2469/#2511
Body
Summary
The latest published Windows release (
v0.54.0, published 2026-05-19) still reproduces the Windows OAuth callback issue described in #2466: after completing Google or GitHub sign-in in the browser, clicking the "Open OpenHuman" option launches/focuses OpenHuman but the app remains on the welcome/login screen.This appears to be fixed on
mainby #2469 and further hardened by #2511, but the latest downloadable Windows installer predates both fixes. Users who uninstall/reinstall from the current release still receive a build that cannot consume the OAuth callback.Environment
F:\ProgramFile\OpenHuman\OpenHuman.exev0.54.0c25fc8e5fd3e7716f416571cd53b34247c94ddbemaincurrently contains fix(tauri): forward Windows local-runtime OAuth callbacks #2469 and feat(auth): loopback OAuth redirect with deep-link fallback #2511, after the release commitReproduction
Expected: OpenHuman consumes the OAuth callback and logs in.
Actual: OpenHuman remains on the welcome/login screen.
Diagnostics
The app is running and healthy:
127.0.0.1:7788,127.0.0.1:19222, and another local port.http://tauri.localhost/#/.The Windows protocol handler is registered:
During OAuth callback attempts, the log repeatedly shows secondary launches being discarded:
No corresponding
auth,oauth,callback,deep-link, or token-consumption log line appears, and the UI state does not change.Related
fix(tauri): forward Windows local-runtime OAuth callbacks, merged 2026-05-22feat(auth): loopback OAuth redirect with deep-link fallback, merged 2026-05-23Requested action
Could you publish a new Windows release/build that includes #2469/#2511, or reopen/track this as a release packaging issue until the latest public installer contains the OAuth callback fix?