Production Google OAuth In One Prompt: I Let Cursor Drive Chrome DevTools MCP

“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 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 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, giving AI agents the same browser primitives as a QA engineer. It supports Anthropic’s MCP 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:

$ 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 and RFC 7636 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:

{
  "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:

   /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

   Windows:

   start chrome --remote-debugging-port=9222

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

{
  "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:

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.