Windows v0.54.0 release still drops Google/GitHub OAuth callbacks after #2469/#2511

[ElioNeto]

Original issue tinyhumansai#2521 by @anweat on 2026-05-23T08:08:45Z

---

Title

Windows v0.54.0 release still drops Google/GitHub OAuth callbacks after tinyhumansai#2469/tinyhumansai#2511

Body

Summary

The latest published Windows release (v0.54.0, published 2026-05-19) still reproduces the Windows OAuth callback issue described in tinyhumansai#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 tinyhumansai#2469 and further hardened by tinyhumansai#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

• OS: Windows
• OpenHuman install path: F:\ProgramFile\OpenHuman\OpenHuman.exe
• Installed executable timestamp: 2026-05-19
• Latest GitHub release checked: v0.54.0
• Release publish time: 2026-05-19T07:17:46Z
• Release target commit: c25fc8e5fd3e7716f416571cd53b34247c94ddbe
• main currently contains fix(tauri): forward Windows local-runtime OAuth callbacks tinyhumansai/openhuman#2469 and feat(auth): loopback OAuth redirect with deep-link fallback tinyhumansai/openhuman#2511, after the release commit

Reproduction

1. Install/Open OpenHuman v0.54.0 on Windows.
2. Choose the local/native runtime.
3. Click Google or GitHub on the welcome screen.
4. Complete OAuth in the system browser.
5. 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

• OAuth deep link "openhuman://auth?token=..." is ignored on Windows 11 — app stays on login screen tinyhumansai/openhuman#2466: same symptom, closed by fix(tauri): forward Windows local-runtime OAuth callbacks tinyhumansai/openhuman#2469
• fix(tauri): forward Windows local-runtime OAuth callbacks tinyhumansai/openhuman#2469: fix(tauri): forward Windows local-runtime OAuth callbacks, merged 2026-05-22
• feat(auth): loopback OAuth redirect with deep-link fallback tinyhumansai/openhuman#2511: feat(auth): loopback OAuth redirect with deep-link fallback, merged 2026-05-23

Requested action

Could you publish a new Windows release/build that includes tinyhumansai#2469/tinyhumansai#2511, or reopen/track this as a release packaging issue until the latest public installer contains the OAuth callback fix?