Is there an existing issue for this?
Current behavior
On Plane for macOS, Google OAuth completes successfully in the browser and macOS returns control to Plane, but the desktop app remains on the sign-in screen.
Browser sign-in for the same account works normally.
Steps to reproduce
- Install Plane for macOS v3.0.0.
- Choose Plane Cloud.
- Select Continue with Google.
- Complete Google sign-in in the browser.
- Allow the browser to return to Plane.
- Observe that Plane returns to the sign-in screen instead of completing the session.
Root cause
The OAuth flow now returns a versioned desktop handoff envelope:
plane://open?v=1&o=<base64url-origin>&p=<base64url-path>
The v3.0.0 desktop client receives the deep link, but interprets the scheme host (open) as a literal web path. It therefore navigates the current instance to /open instead of decoding the origin and enclosed /d/auth/?token=... path.
The web auth guard then redirects the unauthenticated /open request back to sign-in. Local macOS unified logs confirm that the GURL AppleEvent reaches Plane, and Plane's persisted tab state ends at /?next_path=/open/, so this is not a Google OAuth or macOS protocol-registration failure.
Expected behavior
A valid version 1 handoff for the current Plane instance should continue to its enclosed same-origin path and complete desktop authentication. Malformed, unsupported, cross-instance, and cross-origin handoffs should be rejected.
Environment
- Plane desktop: v3.0.0
- Build:
260714bxbai235k
- Bundle ID:
com.todesktop.2405288gp0ar3qc
- Platform: macOS
- Variant: Plane Cloud
Proposed compatibility fix
Add a public web fallback for /open that:
- accepts only handoff version 1;
- base64url-decodes
o and p;
- requires the embedded origin and destination origin to match the current instance; and
- redirects invalid envelopes to sign-in.
A focused regression patch with origin-safety tests is ready. The desktop client should also decode the envelope directly in a future release.
Is there an existing issue for this?
Current behavior
On Plane for macOS, Google OAuth completes successfully in the browser and macOS returns control to Plane, but the desktop app remains on the sign-in screen.
Browser sign-in for the same account works normally.
Steps to reproduce
Root cause
The OAuth flow now returns a versioned desktop handoff envelope:
The v3.0.0 desktop client receives the deep link, but interprets the scheme host (
open) as a literal web path. It therefore navigates the current instance to/openinstead of decoding the origin and enclosed/d/auth/?token=...path.The web auth guard then redirects the unauthenticated
/openrequest back to sign-in. Local macOS unified logs confirm that theGURLAppleEvent reaches Plane, and Plane's persisted tab state ends at/?next_path=/open/, so this is not a Google OAuth or macOS protocol-registration failure.Expected behavior
A valid version 1 handoff for the current Plane instance should continue to its enclosed same-origin path and complete desktop authentication. Malformed, unsupported, cross-instance, and cross-origin handoffs should be rejected.
Environment
260714bxbai235kcom.todesktop.2405288gp0ar3qcProposed compatibility fix
Add a public web fallback for
/openthat:oandp;A focused regression patch with origin-safety tests is ready. The desktop client should also decode the envelope directly in a future release.