Google sign-in fails in a web app: what to check
A site can load fine in a Pake app while sign-in fails, for three look-alike reasons: the provider refuses embedded browsers, a pop-up opened in the wrong place, or a session was not kept. Read the error first, because Google's embedded browser refusal has no Pake setting that fixes it.
Read the actual error before changing settings
Google's OAuth policy says a developer must not direct an authorization request to an embedded user-agent, and a Pake app is such an embedded user-agent: it is a window around the system web view. Google's error reference lists disallowed_useragent as a user-facing error shown when the authorization endpoint is displayed inside an embedded user-agent that Google's policies disallow. See Google's secure-browser policy and error reference. Google's web server OAuth guide is more direct for Mac: iOS and macOS developers may encounter this error when opening authorization requests in WKWebView, which is the view a Pake app uses on macOS, and it also covers the case where an app opens a general web link in an embedded view and the user then reaches Google's sign-in from that site, which is exactly what "Continue with Google" inside a Pake window does.
Because the refusal comes from the sign-in page, not from Pake, changing the user agent is not a supported way around it. Use the service in a supported browser or its official client. Signing in in your browser also does not hand a separate Pake app the browser's cookies, since each has its own storage.
This applies to any site whose sign-in is "Continue with Google", not only Google's own products. A site that also offers its own email and password form is the practical exception, since that form does not go through Google. Pake also recognizes other providers' sign-in pages, but recognizing a page only keeps it inside the app and does not change any provider's policy.
How Pake routes sign-in links
Pake treats some addresses as authentication and keeps them inside the app instead of handing them to your browser. Its script recognizes accounts.google.com and the country variants, login.microsoftonline.com, appleid.apple.com, paths such as /oauth, /auth, /authorize, /signin and /login, Facebook dialog endpoints, and enterprise single sign-on from Okta, OneLogin and SAML or ADFS routes. With Open new windows in the app off, a click on such a link navigates the current window to it, so the whole redirect chain and the return trip stay in one web view. With it on, the sign-in opens as a separate pop-up window of the app on Windows, while on a Mac it still runs in the current window unless it is Sign in with Apple.
Anything that is not recognized as authentication follows the normal link rule. A link to the same site, or its parent domain, stays in the app, and other links open in your browser. That is the usual reason a sign-in "opens my browser": the provider lives on a domain the app treats as external. Internal URL regex under Advanced lets you keep it inside, and the CLI offers --safe-domain for trusted domains such as slack.com,okta.com.
Check whether the sign-in flow needs a new window
Some sites start sign-in in a pop-up. If clicking the button opens an unexpected browser window or does not complete the flow, try Open new windows in the app under Behavior, click Save Changes, and retry. Create an app describes the option, and Multiple windows is a separate setting that controls whether the app can show more than one window of its own.
This setting changes where new windows open. It does not promise compatibility with every sign-in provider and does not bypass the Google policy above. If the same refusal remains, return to a supported browser. Pake's own FAQ gives the same answer for the CLI options --new-window and --multi-window: they help pop-up-based sign-in but cannot override a provider's policy.
Check what the page cannot do on a Mac
Two Mac limits are easy to mistake for a bug. Pake keeps Sign in with Apple pop-ups on the native pop-up path so Apple's callback can return to the page that opened them, and other auth pop-ups may be navigated in the current window to avoid WebKit crashes. Passkeys and Touch ID sign-in are not available in Pake apps on macOS, because the system only offers them to browsers and to apps tied to the site's domain. Sign in with a password and a two-factor code instead.
Check why a working login disappears
If sign-in succeeds but disappears after quitting, inspect Incognito. It starts a clean session and deliberately does not retain sign-ins, cookies or site data. Turn it off when you want the app to keep those between sessions. The gallery's WeChat app runs in Incognito, which is why it asks for a QR scan every time.
A website can also expire sessions itself. Compare the behavior with the same service in your browser, and note whether the loss happens immediately after quitting or only after some time. Editing an app keeps its sign-ins, as Manage your apps explains. Do not delete the app's data as the first troubleshooting step.
What a working setup looks like
For a site that does allow embedded sign-in, the checklist is short. Create the app with Incognito off, leave Open new windows in the app off unless the sign-in opens a pop-up, sign in once, quit, and reopen to confirm you are still signed in. If you need a second account, use separate account apps. If the site asks for a browser it recognizes, the user agent guide covers that separate problem.
Report enough to identify the failing step
If the provider does not state an embedded-browser restriction and the settings above do not explain the behavior, report the website, operating system, Pake version, exact error text and the step where it appears. A screenshot with personal details hidden is useful; passwords, cookies and access tokens are not needed. Open an issue at github.com/tw93/Pake and say which app and which system you use.
The Pake FAQ covers sign-in limits.
FAQ
Can I just change the user agent to look like Chrome?
Not for Google. Their policy is about embedded browsers, and the user agent is not a supported way around it. See the user agent guide for sites that only check the string.
Is a browser-installed app a way out?
Pake's FAQ names the normal browser, a browser-installed app or a native desktop client as the options for sites like this. A Pake app is not one of them.
Why does the same site work in my browser?
A browser is a supported environment for the provider, while an embedded web view is not, and the two keep separate cookies.