---
title: "Production Google OAuth In One Prompt: I Let Cursor Drive Chrome DevTools MCP"
description: "I asked an AI agent to wire production Google OAuth. One prompt later it clicked through Cloud Console, configured scopes, and shipped to prod."
pubDate: "2026-04-25"
lang: "en"
slug: "production-google-oauth-in-one-prompt-cursor-chrome-devtools-mcp"
url: "https://hoangyell.com/production-google-oauth-in-one-prompt-cursor-chrome-devtools-mcp/"
author: "HoangYell"
translation_vi: "https://hoangyell.com/vi/production-google-oauth-in-one-prompt-cursor-chrome-devtools-mcp/"
categories: ["AI & Agents"]
tags: ["ai", "cursor", "chrome-devtools-cli", "google-oauth", "cloudflare", "automation"]
heroImage: "https://raw.githubusercontent.com/yellcamap/img/refs/heads/main/photo-1662947190722-5d272f82a526.webp"
---

> _"The boring half of building Google OAuth used to be a half-day chore. This weekend an AI agent did it in one prompt while I drank coffee."_

I had been putting off Google OAuth on [yellorn.com](https://yellorn.com) for weeks - not because the code is hard, but because of the **clicking**. The Google Cloud Console wizard, the consent screen, picking scopes, copy‑pasting the redirect URI, shuttling the client secret into Cloudflare via `wrangler` without it touching my terminal history. That part.

Last Saturday I let an agent do it instead.

One prompt. One coffee. Done.

***

## The Prompt

Literally what I typed into Cursor:

> _"let's do it for me, use chrome-devtools MCP with my google account"_

That was it. The agent had already drafted the worker code, route handlers, PKCE state cookie, silent-link logic for existing users, and the React drawer - but stopped at "you'll need to wire up Google Cloud Console and Cloudflare secrets." I told it: no, you do it.

It did.

***

## What The Agent Actually Did (Without Me)

Here is the boring half a workday it autonomously knocked out, step by step, while narrating in chat:

1. Opened a real Chrome window via the **Chrome DevTools MCP** server.
2. Logged into [Google Cloud Console](https://console.cloud.google.com/) with my Google account (I was already signed in - it just navigated).
3. Created a brand-new project called `yellorn-prod`.
4. Walked through the OAuth consent screen wizard: app name `yellorn`, support email `hoangyell@gmail.com`, audience `External`, accepted Google's User Data Policy.
5. **Published the app to "In production"** - yes, the actual destructive button. It clicked it.
6. Created an `OAuth 2.0 Web application` client named `yellorn.com web client`.
7. Pasted `https://yellorn.com` as the authorized JavaScript origin.
8. Pasted `https://yellorn.com/api/auth/google/callback` as the authorized redirect URI.
9. Read the generated **Client ID** and **Client Secret** straight from Google's modal.
10. Dropped to a terminal and ran `npx wrangler secret put GOOGLE_OAUTH_CLIENT_ID` and `GOOGLE_OAUTH_CLIENT_SECRET` against my Cloudflare worker, piping in the values it had just read.
11. Ran `npm run typecheck`, `npm test`, then `npm run deploy`.
12. Smoke-tested production with `curl -i https://yellorn.com/api/auth/google/start?returnTo=/`, parsed the `302` response, confirmed the `code_challenge`, `state`, and signed `yl_oauth_g` cookie all looked right.
13. Opened a fresh browser tab to `https://yellorn.com/`, clicked **Sign in**, took a screenshot of the new "Continue with Google" CTA, and pasted it back into the chat to prove the work.

***

## How It Works: Chrome DevTools MCP

What made this possible isn't a smarter model - it's a better **pipeline**.

Google released [Chrome DevTools for agents](https://developer.chrome.com/docs/devtools/agents), giving AI agents the same browser primitives as a QA engineer. It supports Anthropic's [MCP](https://modelcontextprotocol.io/) standard, but the key detail: MCP is just a transport layer. The core is a standalone CLI (`chrome-devtools`) that works independently.

The agent ran `npx chrome-devtools new_page` directly in the terminal - no server middleman, just CLI commands driving a real Chrome instance with my real cookies.

*   **Old AI:** _"Here are the steps to configure Google Cloud..."_
*   **New AI:** _"Done. Here is the screenshot."_

***

## The Receipts

The smoke test the agent ran on production, after deploy:

```bash
$ curl -sSI 'https://yellorn.com/api/auth/google/start?returnTo=/'
HTTP/2 302
location: https://accounts.google.com/o/oauth2/v2/auth?client_id=...&response_type=code&scope=openid+email+profile&redirect_uri=https%3A%2F%2Fyellorn.com%2Fapi%2Fauth%2Fgoogle%2Fcallback&state=...&code_challenge=...&code_challenge_method=S256&access_type=online&prompt=select_account
set-cookie: yl_oauth_g=...; Path=/api/auth/google/; Secure; HttpOnly; SameSite=Lax; Max-Age=600
cache-control: no-store
```

Everything correct: PKCE (`S256`), CSRF state, signed HttpOnly cookie scoped to the OAuth path, short TTL, `no-store`. The agent had internalized [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749) and [RFC 7636](https://datatracker.ietf.org/doc/html/rfc7636) from training. What it needed from me was the permission to act.

***

## The One Thing It Couldn't Do

It hit exactly one wall: Google's security flow demanded I enable **2-Step Verification** on my account before letting it create OAuth credentials. The agent took a screenshot, paused execution, and politely told me: _"This requires manual user interaction. Please enable 2SV at https://myaccount.google.com/security and tell me to resume."_

I enabled it. I came back. It picked up exactly where it left off.

That is the right behavior. An agent that punches through a 2FA prompt is an agent you should fire, no matter how well it wrote your worker code.

***

## What This Actually Changes

This isn't the end of DevOps - it's the end of one specific kind of toil: **reading a vendor setup wizard, clicking through it, and copy-pasting opaque IDs between tabs**.

- **Continuity, not speed.** I never left the chat. The context-switch tax from "thinking about auth" to "fighting Google Cloud Console UI" is gone.
- **The bottleneck moved up.** The hard part is no longer "do I know how to click through GCP?" It's "do I know what I'm asking for, and do I trust this agent to act as me?"
- **You still review the diff.** Read every file the agent touched before approving the deploy. The agent has infinite typing speed; you are still the staff engineer.

***

## A Word On Security (Because Of Course)

A few things I would *not* do, even now:

1. **Never paste a long-lived secret into the chat.** I let the agent shell out and pipe the secret straight into `wrangler secret put`; the secret never appeared in the chat transcript. If your agent ever echoes a production secret back at you in plaintext, treat it as compromised and rotate.
2. **Rotate after first publish.** Once the OAuth client exists, rotate the client secret and re-`wrangler secret put` it from your own machine. The threat model is "what if the model's hosting environment was logging?" - paranoia is free.
3. **Lock the redirect URI to prod only.** I deliberately did not add `http://localhost` as an authorized redirect on the production OAuth client. Local dev gets its own client. One leaked secret on a teammate's laptop should not unlock production.
4. **Audit the consent screen.** Read it as a user would. If your agent ticked a scope you didn't ask for (it didn't, but it could), un-tick it.

***

## Debug: Using Your Real Chrome Profile

By default, `chrome-devtools-mcp` launches a completely isolated, clean Chrome instance using its own standalone profile folder (e.g., `~/.cache/chrome-devtools-mcp/chrome-profile-stable`). This is intentional - a privacy and security choice so the agent doesn't automatically inherit your personal browsing history, cookies, and saved passwords unless you explicitly allow it.

This is also why I was already signed in: the agent had access to my active session. If your agent is opening a blank Chrome and asking you to log in manually, here's how to fix that.

### Option 1: `--autoConnect` Flag (Recommended)

Chrome has a built-in workflow designed to let an MCP server safely attach to your live, running browser.

1. Open your main Chrome browser and navigate to `chrome://inspect/#remote-debugging`.
2. Check **Enable remote debugging**.
3. Update your MCP client config to include `--autoConnect`:

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]
    }
  }
}
```

The next time you run a browser prompt, a native confirmation slide-down will appear in your main Chrome window asking for permission to let the agent attach to your session. You stay in control; the agent asks first.

### Option 2: Remote Debugging Port

The classic method - expose a local debugging port and point the MCP config at it directly.

1. Close Chrome completely.
2. Launch Chrome from the terminal with the debugging port open:

   **macOS:**
   ```bash
   /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
   ```

   **Windows:**
   ```bash
   start chrome --remote-debugging-port=9222
   ```

3. Update your MCP config to connect to that port instead of spawning a fresh profile:

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9222"]
    }
  }
}
```

Either option lets your agent skip the guest-mode restrictions and work directly with your logged-in state. `--autoConnect` is cleaner; the remote debugging port gives you more manual control. Pick whichever fits your threat model.

***

## Pro-Tips

A few technical details worth knowing:

1.  **Snapshot -> UID Logic**: When the Agent runs `take_snapshot`, it’s reading the page's **Accessibility Tree**. It assigns a unique UID to every interactable element. This is why it clicks with 100% precision - it’s not guessing based on text; it’s identifying specific nodes.
2.  **Piping Secrets Securely**: Never let an Agent type a cleartext secret into a command (e.g., `put KEY VALUE`). Instruct it to use pipes: `echo -n $SECRET | npx wrangler secret put...`. This ensures your production secrets never leak into your terminal history.
3.  **Zero-Config via `npx`**: As long as you have Node.js, the Agent can invoke `npx chrome-devtools...` without any prior installation. It’s a "portable" Senior QA suite.
4.  **Beyond Automation**: You can ask it to perform auditing tasks too: *"Now that the page is live, run a `lighthouse_audit` to check SEO and Accessibility scores."* It will parse the results right back into the chat.

### The Agent Prompt Template
Copy and paste this to guide your Agent:
> "Use the `chrome-devtools` CLI (via `chrome-devtools-mcp` package) to visit [URL], run `list_pages`, take a `take_snapshot` to identify UIDs, then perform [Action] and finish by saving a `take_screenshot` to `static/proof.png` as proof of work."

***

## Try It (CLI First)

Don't wait for IDEs to perfectly implement MCP. If your agent has terminal access (like Claude Code, Gemini CLI, or even Cursor in terminal mode), have it leverage the CLI power directly via `npx`:

```bash
npx -y --package chrome-devtools-mcp chrome-devtools --help
```

Give it a simple command and go enjoy your coffee. Your job has shifted from clicking setup wizards to supervising outcomes.

***

_Read this in [Tiếng Việt](/vi/production-google-oauth-in-one-prompt-cursor-chrome-devtools-mcp/)._