Summary
colab drivemount fails with Error propagating: 400 in multi-account Google environments. The Drive credential propagation request hardcodes authuser=0, which does not necessarily correspond to the account the CLI authenticated as.
Environment
google-colab-cli 0.6.0 (installed with uv tool install)- macOS (Darwin 24.6.0), Python 3.12
- Auth provider:
oauth2
- Colab Pro; reproduced on both L4 and A100 sessions
- The account used by the CLI is not the browser's default Google account — it resolves to
authuser=6
Steps to reproduce
- Be signed in to several Google accounts in the browser, where the account used by
colab is not the first one (i.e. not authuser=0).
colab new -s test --gpu L4colab drivemount -s test- Open the printed authorization URL and grant access. The URL is built correctly — it contains
login_hint=<the CLI's authenticated account>.
- Press Enter as instructed.
Observed output:
[colab] Intercepted Drive Auth Request. Connecting to https://colab.research.google.com...
[colab] REQUIRED: Google Drive Authorization needed.
Please visit:
https://accounts.google.com/o/oauth2/v2/auth?...&login_hint=<authenticated-account>&...
Press Enter after you have granted access...
[colab] Authorizing VM...
[colab] Error propagating: 400
<!DOCTYPE html> ... <title>Error 400 (Bad Request)!!1</title> ...
Reproduced twice, on two different sessions, each time using a freshly printed authorization URL (so an expired state token is not the cause).
Root cause
In colab_cli/commands/automation.py, inside drivefs_hook:
url = f"{state.client.colab_domain}/tun/m/credentials-propagation/{s.endpoint}"
params = {
"authuser": "0", # <-- hardcoded
"authtype": "dfs_ephemeral",
"version": "2",
"dryrun": "true",
"propagate": "true",
"record": "false",
}authuser is hardcoded to "0". The OAuth consent is correctly requested for the authenticated account (the authorization URL carries the right login_hint), so the user grants access as the intended account. However, the subsequent propagation request asks the backend for authuser=0, which in a multi-account browser session is a different account. The backend rejects the mismatch with 400 Bad Request.
This is invisible to single-account users, for whom the authenticated account is authuser=0.
Suggested fix
Resolve authuser from the authenticated identity instead of hardcoding it. The CLI already knows the authenticated email (surfaced by the hidden colab whoami command), so mapping that to the correct authuser index would be the complete fix.
As a minimal, backwards-compatible first step, allow an override:
"authuser": os.environ.get("COLAB_AUTHUSER", "0"),or expose it as a flag, e.g. colab drivemount --authuser N.
Workaround status
I patched the line locally to read from an environment variable, intending to run:
COLAB_AUTHUSER=6 colab drivemount -s test
I have not yet been able to verify this workaround end-to-end — the session's kernel was busy with a long-running job at the time of writing, and drivemount requires an interactive TTY. I will update this issue once I have confirmed whether overriding authuser resolves the 400.
The root-cause analysis above stands on its own regardless: the hardcoded authuser=0 is inconsistent with the login_hint used in the very same flow.
Summary
colab drivemountfails withError propagating: 400in multi-account Google environments. The Drive credential propagation request hardcodesauthuser=0, which does not necessarily correspond to the account the CLI authenticated as.Environment
google-colab-cli0.6.0 (installed withuv tool install)oauth2authuser=6Steps to reproduce
colabis not the first one (i.e. notauthuser=0).colab new -s test --gpu L4colab drivemount -s testlogin_hint=<the CLI's authenticated account>.Observed output:
Reproduced twice, on two different sessions, each time using a freshly printed authorization URL (so an expired
statetoken is not the cause).Root cause
In
colab_cli/commands/automation.py, insidedrivefs_hook:authuseris hardcoded to"0". The OAuth consent is correctly requested for the authenticated account (the authorization URL carries the rightlogin_hint), so the user grants access as the intended account. However, the subsequent propagation request asks the backend forauthuser=0, which in a multi-account browser session is a different account. The backend rejects the mismatch with400 Bad Request.This is invisible to single-account users, for whom the authenticated account is
authuser=0.Suggested fix
Resolve
authuserfrom the authenticated identity instead of hardcoding it. The CLI already knows the authenticated email (surfaced by the hiddencolab whoamicommand), so mapping that to the correctauthuserindex would be the complete fix.As a minimal, backwards-compatible first step, allow an override:
or expose it as a flag, e.g.
colab drivemount --authuser N.Workaround status
I patched the line locally to read from an environment variable, intending to run:
COLAB_AUTHUSER=6 colab drivemount -s testI have not yet been able to verify this workaround end-to-end — the session's kernel was busy with a long-running job at the time of writing, and
drivemountrequires an interactive TTY. I will update this issue once I have confirmed whether overridingauthuserresolves the 400.The root-cause analysis above stands on its own regardless: the hardcoded
authuser=0is inconsistent with thelogin_hintused in the very same flow.