Summary
Pocket Desktop failed while uploading a just-finished meeting. The upload reached roughly 10%, then the app reported that the session was stale/invalid and said I needed to sign in again.
I was still signed in at the time. To complete the requested re-authentication flow, I had to sign out and sign back in.
During that process, Pocket also reported that an update was available and ran an update. Afterward, Google sign-in repeatedly failed. Google authentication appeared to complete, but the desktop auth callback returned a generic authentication error page.
User-facing error
Authentication Error
Something went wrong during authentication.
Please close this window and try again.
The error page was hosted at:
production.heypocketai.com
The visible URL path during the failure looked like a desktop auth callback:
/api/v1/auth/desktop/callback
Timeline
- A meeting finished recording.
- Pocket started uploading or processing the recording.
- Upload progressed to approximately 10%.
- Pocket reported that the session was stale, invalid, or similar, and prompted me to sign in again.
- I was still signed in, but had to sign out to complete the requested re-auth flow.
- During this time, Pocket reported that an update was available and ran an update.
- After the update/sign-out/sign-in flow, Google authentication repeatedly failed with the production callback Authentication Error.
What I tried
- Let Pocket run the prompted update.
- Signed out of Pocket on the web.
- Signed out of Pocket Desktop.
- Revoked Pocket’s Google access from my Google account permissions.
- Re-authenticated with Google.
- Cleared/restored Pocket Desktop embedded WebView auth cache during troubleshooting.
- Attempted reinstall/update using the downloaded Pocket 0.3.85 installer.
The same authentication error persisted.
Local environment
OS: Windows
Pocket install path:
C:\Users\Rob Landry\AppData\Local\Pocket\Pocket.exe
Pocket local app data path:
C:\Users\Rob Landry\AppData\Local\com.openvisionengineering.pocket-desktop-app
Pocket roaming data path:
C:\Users\Rob Landry\AppData\Roaming\com.openvisionengineering.pocket-desktop-app
Version / installer mismatch observed
Windows uninstall metadata reports Pocket version 0.3.85.
However, the actual executable at the normal launch path reports:
FileVersion: 0.3.63
ProductVersion: 0.3.63
ProductName: Pocket
CompanyName: Open Vision Engineering, Inc
A downloaded installer was found at:
C:\Users\Rob Landry\AppData\Local\Temp\Pocket-0.3.85-updater-Cmc9gn\Pocket-0.3.85-installer.exe
The installer reports version 0.3.85, but after running it, the installed Pocket.exe remained byte-for-byte identical to the previous 0.3.63 executable.
Observed result:
- uninstall.exe updated to 0.3.85
- Windows uninstall registry metadata updated to 0.3.85
- Start Menu shortcut timestamp updated
- Pocket.exe stayed identical to the old executable and still reports 0.3.63
This may be harmless stale version metadata, but it looks like a packaging/update inconsistency and may be related to the auth failure.
WebView / auth storage findings
Pocket Desktop appears to use an embedded WebView profile under:
C:\Users\Rob Landry\AppData\Local\com.openvisionengineering.pocket-desktop-app\EBWebView
Firebase auth storage was found in the WebView IndexedDB:
EBWebView\Default\IndexedDB\http_tauri.localhost_0.indexeddb.leveldb
Resetting the embedded WebView profile and cookies did not resolve the auth error. The same callback error persisted after Pocket recreated a clean WebView profile.
Recording / upload side effect
The local audio file survived at:
C:\Users\Rob Landry\AppData\Roaming\com.openvisionengineering.pocket-desktop-app\local_recordings\desktop_1782426387990_ekybgz.ogg
Approximate recording details:
Recording ID: desktop_1782426387990_ekybgz
Size: 17,823,578 bytes
Duration: about 3,942 seconds / about 65.7 minutes
Start timestamp from ID: 2026-06-25T22:26:27.990Z
Local time: 2026-06-25 3:26 PM PDT
At one point during troubleshooting, the active SQLite database had no rows in recordings, local_recordings, upload_queue, recording_details, or meetings.
The audio file existed on disk, but there was no active upload queue row for it. This suggested the recording may have been orphaned during auth/session failure or during the app’s interrupted finish/upload path.
Note: After troubleshooting, local Pocket state was rolled back to its previous condition.
Public issue search
I did not find obvious public/current reports for:
- heypocketai.com authentication outage
- production.heypocketai.com Authentication Error
- Pocket AI Google sign-in failures
- Open Vision Engineering Pocket auth failures
This may still be a private production issue, account-specific backend issue, or recently introduced desktop callback bug.
Suspected causes
- Pocket production desktop callback is rejecting a valid Google auth result.
- Account-specific auth/session state is invalid on Pocket’s backend.
- Upload flow is incorrectly invalidating or failing to refresh a still-active session.
- Pocket Desktop installer/update metadata is inconsistent, leaving the app in a mixed 0.3.85 registry / 0.3.63 executable state.
- The app may not gracefully recover local recordings/upload queue entries when auth fails during a finish/upload operation.
Requested help
Please check:
- Server logs for the failing desktop callback on production.heypocketai.com.
- Google OAuth callback handling for this user/account.
- Why an upload at roughly 10% reported a stale/invalid session even though I was still signed in.
- Whether Windows installer 0.3.85 is expected to install a Pocket.exe that still reports and hashes like 0.3.63.
- Whether orphaned local recordings can be recovered/requeued safely after auth failure.
Attribution
This report was drafted with help from OpenAI Codex, which assisted with local troubleshooting, organizing the findings, and identifying likely failure points.
