“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. (By the way, yellorn.com is a personal project I built for my own workflows. It started as a “just for fun” thing, but fortunately it’s gained quite a bit of traction and users lately. I wrote a blog post about it here if you want to learn more). Not because the code is hard — the code is, frankly, the easy part. It was the clicking. The trip through Google Cloud Console, naming the project, ticking the consent screen, picking scopes, copy‑pasting the redirect URI, sweating the publishing status, generating the client secret, then shuttling that secret into Cloudflare via wrangler without leaking it to my terminal history. That part. The unfun part.

Last Saturday I just gave up and let an agent do it.

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. No checklist, no spec, no architecture doc. A throwaway sentence at the end of a thread where I had been describing the OAuth flow I wanted in yellorn.com. The agent had already drafted the worker code, the route handlers, the PKCE state cookie, the silent-link logic for existing email/password users, the React drawer with the “Continue with Google” button — but it stopped at “you’ll need to wire up Google Cloud Console and Cloudflare secrets.” Classic AI cop-out. 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 [email protected], 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.

I watched the cursor (the OS one, not the IDE one) move on its own. It was uncanny in the way the first time you saw your phone autocomplete a sentence was uncanny. You know it’s a tool. It still hits different when the tool clicks “Publish” for you.

The Magic Trick: Chrome DevTools & The MCP Plot Twist

What made this possible isn’t a smarter model—it’s a better pipeline.

Google quietly released Chrome DevTools for agents, giving AI agents the same primitives as a senior QA engineer. While it supports Anthropic’s MCP standard, here’s the plot twist: MCP is just a JSON-RPC fancy dress. At its core, this is a standalone CLI (chrome-devtools) that works 100% independently.

I had my agent fire off npx chrome-devtools new_page directly in the terminal. No protocol handshake, no server middleman—just pure 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.”

That’s the difference between a recipe and a chef.

The Receipts

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

1
2
3
4
5

$ 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

Every box ticked: PKCE (S256), CSRF state, signed HttpOnly cookie scoped to the OAuth path, short TTL, no-store. This is the kind of thing I would normally re-read RFC 6749 and RFC 7636 for at 11pm to make sure I didn’t miss anything. The agent had already internalized those RFCs from training; what it needed from me was just 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

I don’t think this is “the end of DevOps.” It is, however, the end of a very specific kind of toil: the toil of reading a vendor’s setup wizard, clicking through it, and copy-pasting opaque IDs between tabs. That toil is now negotiable. You can pay it yourself, or you can delegate it to the agent.

A few honest reflections after watching it happen:

• Speed is not the headline. Continuity is. I never had to leave the chat. The mental cost of context-switching from “thinking about the auth flow” to “fighting Google Cloud Console UI” is gone. That’s worth more than the saved minutes.
• Reading the agent’s plan is the new reading the docs. I didn’t memorize Google’s OAuth wizard. I read the agent’s narration. Same end state, lower cognitive load.
• 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?” That’s a healthier question.
• You still review the diff. Before approving the deploy I read every file the agent had touched. The agent is a junior with 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.

The fact that an AI can drive Google Cloud Console for you doesn’t mean it should drive without supervision. It means the supervision is the actual job.

Pro-Tips for Power Users (The Real Value)

To get the most out of your Agent’s new “hands,” keep these technical nuances in mind:

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

If you have Cursor (or any IDE with MCP support), Chrome DevTools MCP is a cursor.json config away. Hand it the keys, give it one sentence, and watch the cursor move.

Then go drink your coffee.

Read this in Tiếng Việt.