Adom Google

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:

1. 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?
2. 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.

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:

1. 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?
2. 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.

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.