Day 3/30 – Claude Code Challenge (Marketing Edition)
Giving Browser Access via Playwright
Next up: giving Claude Code browser access via Playwright.
Why?
With Playwright, you are adding browser capabilities unlocks what standard web fetch can’t handle:
→ JS-heavy websites
→ Multi-page scraping/pagination
→ Screenshots
→ Actions that require being logged in to your own accounts
→ Perform actions on websites (such as clicks, form fills etc)
Use Case of Playwright: Landing Page Analysis
With Playwright, I can analyze the full funnel of a competitor exactly as a real prospect would experience it.
For example: Landing page
→ Click “Submit” on whitepaper (page 1)
→ Fill qualification form (page 2)
→ Reach scheduling page (page 3)
→ Reach confirmation page (page 4)
Playwright can automatically progress through each step, just like a human user. It clicks buttons, fills forms, waits for the next page to load, and captures the resulting state.
At every stage, it extracts and catalogues the page without requiring me to manually go through the funnel.
Playwright over Puppeteer
When working with headless browsers, there are two dominant options:
Puppeteer (maintained by Google)
I went with Playwright over Puppeteer primarily because it has an official MCP server maintained by Microsoft. Puppeteer’s MCP implementation has been deprecated, which makes Playwright the more reliable choice for long-term use with Claude Code.
Official support also reduces the risk of breakage. Deprecated or unofficial MCP servers may stop working, fall behind browser updates, or introduce unexpected issues. Since my workflows depend on consistent browser automation for landing page analysis and funnel extraction, stability is critical.
Note: Playwright spins up a fresh browser instance each time (think of it like a new incognito window), so you can't use your existing browser sessions.
I think this opens up alot of potential in marketing research and data collection.
Handling Playwright Chrome Auth
The main issue I hit with Playwright was authentication.
By default, Playwright spins up a fresh browser profile every run. Think “new incognito window.” Clean session, zero cookies, zero logins.
That’s great for test isolation. It’s terrible for real-world research.
Because if your workflow needs access to anything behind a login (LinkedIn, ad libraries, SaaS dashboards, analytics tools), you end up re-authenticating constantly. Same sites. Same MFA. Same pain.
Then I saw a simple fix:
Make a copy of your default Chrome profile and point Playwright to that copied profile.
Now Playwright launches with an already-authenticated state. Your cookies, sessions, and stored logins persist across runs. You get the best of both worlds:
Not touching your real day-to-day Chrome profile
Keeping a stable “automation” profile with persistent auth
No repeated logins every time you run a script
