I’m running into a strange problem where I can’t actually access the OAuth consent screen editor for my project, even though I’ve already selected External and I have Owner permissions on the project. Every time I navigate to:
APIs & Services → OAuth consent screen
I’m only ever shown the “Overview” page, with no option to “CONFIGURE CONSENT SCREEN.” Clicking the blue Edit app button never appears, and there is no way for me to enter the required fields (App name, User support email, Developer contact email, etc.) to get it out of Draft.
I’ve tried:
Verifying I’m in the correct project via the project selector
but it still just redirects me to the Overview screen
Ensuring I have the Owner role and the “OAuth Configuration Admin” and “Service Usage Admin” permissions
Checking for any organization policies around OAuthExternalProject, but nothing obvious is blocking me
Has anyone else experienced this UI bug or know what permission or policy might be preventing the CONFIGURE CONSENT SCREEN button from appearing? Any ideas on how to unblock this so I can properly set up my OAuth consent screen?
Same issue for me. I can’t believe that google would be ignoring this. It’s bad enough that the UI for console is so terrible, but this is beyond the pale. The usual response is - blame the user.
I’m seeing a related but distinct symptom on the “Google Auth Platform” (new consent screen UI) that’s worth adding here: for me it’s not that the editor never appears — it’s that any interactive action inside it (opening a dropdown, clicking “Next” between wizard steps, or submitting “Create”) causes the tab to go fully unresponsive. Not just a slow spinner — JavaScript execution itself stops responding.
Reproduced this across 3 separate, unrelated Google accounts (to rule out an account/org permissions issue) 1. A Workspace account, existing project — froze switching publishing status from Production back to Testing.
A different Workspace account (same org), brand-new project — froze on the wizard’s step 1 to step 2 “Next” button, which shouldn’t need a server round-trip at all.
A personal @gmail.com account with no relation to that Workspace org, brand-new project — froze just opening the “User support email” dropdown.
All tested in fresh Chrome tabs on macOS, so it’s not stale tab/session state. Read-only pages (viewing an already-configured screen) and unrelated Console actions (enabling APIs, IAM) work fine — it’s specifically interactive Auth Platform wizard actions that lock up.
No paid support plan here so I can’t open a case directly. Anyone found a workaround, or is this being tracked anywhere?