Google OAuth authorize fails: Error 400 invalid_request — missing response_type - Adom Google

by adom

Drive your whole Google Workspace from the terminal, run by your AI. Read Gmail, write Google Docs, build Google Sheets and Google Slides, search Google Drive, manage Google Calendar and Google Tasks, and post to Google Chat, plus any Google API and a zero-setup personal Gmail.

Overview Files Skills Discover Packages Releases Dependencies Issues1 Breadcrumbs Pull Requests Activity

Closed bug report

Google OAuth authorize fails: Error 400 invalid_request — missing response_type

AdityaAngajala · 3mo ago ·closed by John Lauer

Hit while signing in with Google as [email protected] (app shows as "Adom").

Google blocks the consent screen with:

Access blocked: Authorization Error Required parameter is missing: response_type Error 400: invalid_request

So the authorize URL is being built without response_type=code (or it's being dropped somewhere on the way to accounts.google.com). The failure happens before the consent screen ever renders, so no one can complete the Google authorization flow while this is broken.

Seen: 2026-07-17, from a sign-in initiated for the Adom OAuth client. Expected: Google consent screen for [email protected]. Actual: Google's "Access blocked: Authorization Error" page as above.

3 Replies

John Lauer · 3mo ago

Thanks for the detailed report. Investigated — and I do not think the bug is in adom-google itself. Every place adom-google builds a Google authorize URL includes response_type=code:

published CLI bin/adom-google: the gateway flow (cmd_auth) and the manual flow (_auth_manual) both set "response_type": "code" in the params dict before urlencode.
the copy bundled inside the adom mega-skill: same, response_type present.
even the legacy adom-gmail: same.

The gateway (john/service-oauth) does not build authorize URLs at all — it only relays the callback and does the code→token exchange. So no adom-google code path can emit an authorize URL missing response_type.

Since the consent screen shows the app as "Adom", the failing URL is being built by a different surface that shares the same "Adom" Google OAuth client (client_id 432727599812-...) — most likely a platform-level "Connect Google" web flow (Carbon / Hydrogen Desktop), whose backend I cannot see from a user container. That is where an authorize URL would get assembled server-side and could drop response_type.

To pinpoint it, two things would nail it:

How did you start the sign-in? A terminal adom-google auth? An HD / dashboard "Connect Google" button? A link on a wiki page? Something else?
The full failing URL from the browser address bar (an authorize URL carries no secrets — client_id/redirect_uri/scope only). The host + path + which params are present vs missing will tell us exactly which surface built it.

If it turns out to be the Carbon/HD Connect-Google flow, this should be re-filed against that repo — happy to help chase it there. If you actually ran adom-google auth and still got this, tell me the version (adom-google status / the package version) because that would be new and I will dig in immediately.

John Lauer · 3mo ago

Thanks for the detailed report. Investigated — and I do not think the bug is in adom-google itself. Every place adom-google builds a Google authorize URL includes response_type=code:

published CLI bin/adom-google: the gateway flow (cmd_auth) and the manual flow (_auth_manual) both set "response_type": "code" in the params dict before urlencode.
the copy bundled inside the adom mega-skill: same, response_type present.
even the legacy adom-gmail: same.

To pinpoint it, two things would nail it:

How did you start the sign-in? A terminal adom-google auth? An HD / dashboard "Connect Google" button? A link on a wiki page? Something else?
The full failing URL from the browser address bar (an authorize URL carries no secrets — client_id/redirect_uri/scope only). The host + path + which params are present vs missing will tell us exactly which surface built it.

John Lauer · 3mo ago

Root cause FOUND, and John is right — it is adom-google, my mistake in the earlier triage.

It is the classic unquoted-ampersand truncation. adom-google auth prints a Google consent URL full of & (client_id&redirect_uri&response_type=code&scope&...). When the AI opens that URL via an UNQUOTED shell/open command, the shell treats & as "run in background" and cuts the URL at the FIRST &. Google then receives only client_id=... and returns exactly your error: "Error 400: invalid_request — Required parameter is missing: response_type" (response_type is the first required param it checks after client_id). On retry the AI opens it quoted or via a browser tool that takes the URL as a value, and it works — which is why both employees could "push through."

Proven: building the real params dict and splitting the URL at the first & leaves only [client_id], and Google flags response_type. Exact match.

Fixed in [email protected] (bundle [email protected]):

adom-google auth now LEADS with a copy/paste-safe open command that carries the URL inside JSON (the & cannot truncate): adom-desktop nbrowser_open_window {"sessionId":"gauth","url":"<URL>"}.
It prints a loud warning: the URL has &, open it as ONE value, never unquoted in a shell, or you get "missing response_type".
The SETUP_HINT (what the installing AI reads) and the SKILL both carry the same warning up front.
Same treatment on the --manual flow.

Verified the emitted command shell-splits with response_type intact. Closing as fixed in 0.7.9; thanks for pinning it down with the two live repros.