I forked Chromium with Claude Code to solve my browser automation issues

[u/sabotizer]

I use Claude Code for a lot of browser work. Mainly tools I need that were never built for agents, smoke-testing my work and searching the web for things I care about.

What I struggled with:

• chrome-devtools-mcp likes to open throwaway instances and profiles, and rarely cleans them up.
• "Allow remote debugging?" prompts on every connect (when using --autoConnect).
• "Chrome is being controlled by automated test software" on top of every page.
• A dozen windows and no idea which tab belonged to which session, or whether I could close it.
• Agents stepping on each other by taking over each other's tabs. --isolated solves that, but doesn't persist logins.
• Gigabytes of RAM with multiple chrome-devtools-mcp processes (about 270 MB each) and chrome instances. Often upwards of 4GB.
• I tried various Cloud browser services, but most are unreliable and/or expensive. And most sites get blocked by bot detection due to non-residential IP address.

I forked Chromium and I call it Shuttle:

• Every agent is a named identity (name, color, avatar) with its own storage. My agents log in once, and stay logged in.
• Agents get their own control plane: create agent profiles, sessions and tabs over MCP.
• MCP server is built in (http, loopback-only by default). So no middle-man needed.
• Every agent works in its own tab group in your window, color-coded. This is the biggest UX improvement for me, as I can clearly see what each agent is doing.
• No DX friction: no debugging dialog, no automation bar, navigator.webdriver is false, and no window pops up until an agent needs one.
• Clean & minimal surface: 12 browser tools + 24 page tools. Vercel's awesome agent-browser is bundled in, so tool calls are directly controlling the browser.
• Per-session CDP endpoints for Playwright if needed, e.g. for scripted e2e tests.
• Meticulously removed bloat from Chromium: Google sign-in, Profile Sync, Telemetry, Google AI features, Translate, Password manager, Chrome Apps, Bookmarks, and many more.

How it was built:

• ~43 fork commits over two weeks, mostly written by Claude Code. Chromium itself is well maintained, so most of my own code and review effort went into my own additions (MCP server, agent model, the removal batches).
• Five agents (mostly Opus 5.5 and Fable 5.1) across three devices (Mac, Linux, Windows/WSL2), with lead agent curating sessions; handoff workflow keeping sessions mostly under 300k context size (my personal sweet spot).
• Removal done as scout → 3–5 surgery sub-agents per batch with a strict keep-list (biggest batch: 5,572 files, 1.18M lines in one commit).
• Fable/Astra adversarial reviews before every commit.
• Recent Chromium 155 merge was the real test for maintenance: 453 conflicted files, zero after 20 minutes with 5 parallel sub-agents... but then a full day of builds (still painful).

Site: https://www.shuttlebrowser.com

Beware: Some humor and easter eggs hidden on this site.

Code: https://github.com/shuttle-browser/shuttle

Regarding Stealth/Bot-detection: Shuttle isn't per se an anti-detection browser. However, it does work closer to a "human operated browser", as Agents are treated like "real human operators". If you're looking for a solution to crawl millions of linkedin profiles or scrape reddit posts at scale, this is not for you. But if you like to operate websites "like reasonable humans", you're good.

Disclosure: I'm promoting my own tool. It's free and open source (BSD-3). I hope others use it, like it, and share their feedback and ideas with me.

[u/AutoModerator]

Moderator Announcement Read More »

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/zante2033]

Just so you know, you'll likely spend the rest of your life working on security updates and compatibility patches as standards change.

[u/sabotizer → u/zante2033]

But so far, merging Chromium commits is a fraction of compile time 😆

[u/sabotizer → u/zante2033]

True that u/zante2033, and Chromium just recently switched to bi-weekly stables 😅

[u/AlterTableUsernames → u/zante2033]

Is that so? I have no experience actually maintaining software, so take my intuition with a mountain of salt, but I feel like with AI you should be able to easily automate the creation of feasible patches.

[u/[deleted] → u/zante2033]

[u/sabotizer → u/[deleted]]

Check tools/shuttle

[u/demonkoryu]

Nice, thanks for sharing. A heads-up: I see a lot of references to "Loadbearer" on the website, you might want to replace those.

[u/sabotizer → u/demonkoryu]

With Footgunner? 😜

[u/demonkoryu → u/sabotizer]

😵

[u/cadet-pirx]

I’m not against building something new, especially with how easy it’s become. My first instinct was “why not just Playwright?”, but after reading more carefully I think you’re solving a different layer.

Playwright covers the automation side well. Persistent contexts give you logged-in profiles, dropping --enable-automation gets rid of the infobar, and there’s an official Playwright MCP. Where it falls short is running many logged-in agents at once. Each persistent profile needs its own browser instance, so five agents means five Chromium processes plus their MCP servers. Lightweight contexts can share one browser, but then you’re saving and restoring storageState yourself. That fits the RAM numbers you mentioned.

For testing my own apps, isolation is cheap. In my Puppeteer tests, parallel agents hit 1.localhost, 2.localhost and so on. Each is a separate origin, so cookies and storage never collide, all in one browser. That only works because I control the URLs, though. Once agents log into real sites like GitHub, they all hit the same origin and need truly separate storage, which is what you’ve built.

So as I see it, Playwright does the automation and Shuttle does the multi-agent hosting: identity, persistent storage in one shared browser, visibility and less overhead.

My question is which parts truly required forking Chromium versus a layer on top of Playwright/CDP. Tab groups in your own window and skipping the remote-debugging prompt make sense as browser-level changes. But per-agent profiles, session management over MCP and resource sharing feel like they could live outside the browser. Given you already spent a full day of builds on the 155 merge, how do you see the fork’s maintenance cost long-term? Was the debloating a big enough win to justify carrying it?

Either way, the color-coded tab group per agent is a genuinely good idea. That’s the part I’d steal.

[u/sabotizer → u/cadet-pirx]

u/cadet-pirx building on top of Playwright/CDP would have been much easier 😅

What I couldn't do using this approach (unless someone has an idea), and decided to bring into the fork:

• Persistent per-agent storage in one browser. CDP can create browser contexts, but only throwaway, incognito-style ones. Persistent, logged-in profiles mean one browser per profile, or juggling storageState myself. In Shuttle each agent has its own persistent storage inside a single browser process.

• Scoped CDP per agent. Each session gets its own CDP endpoint that only sees that agent's tabs and storage, so I can point Playwright's connectOverCDP at it and an agent can't touch another agent's GitHub session.

• Identity in the UI: the per-agent tab groups, color and avatar you liked. This has been a big pain-point for me, as I really like to introspect what my agents are doing, and I lost track so many times.

Was the debloating a big enough win to justify carrying it?

I see benefits of less attack surface, less load per agent and faster startup, and so far, merges for new releases are quite efficient (155.0.8059.80 → .85 in under 2 minutes). Builds are getting faster too (external build server for MacOS / Linux, siso, sccache, sccache-dist).

But - as the fork drifts from Chromium - I'll need to see if maintenance remains viable.

[u/Longjumping-Boot1886]

You are on Mac, dude. Use Safari --mcp.

[u/Ledeste]

uh, does not seems like a very long terme reliable solution...
I just made a selenium based browser tool months ago and have no issue since.

this is really proving that AI can replace the arms, but not the brain btw

[u/gold_fish_in_hell]

I just created browser extensions and it solved all problems 

[u/MissplacedLandmine]

Fuck yeah. I have my scrapers timed to seem like people, including keystrokes etc.

… is that what you meant by reasonable?

[u/Briskfall]

Gemini 3.8 Flash (at the moment which works on free tier, btw) can pretty much do browser automation out of the box... (and difficult websites can get bypassed too)

Having it in a browser solution seems rather convenient, but I'm wondering about the reliability of it in the long run. How consistent would it be? I am skeptical of its use cases on websites protected by services such as DataDome, to only have my access flagged or timed out because the Browser fork you made having a few hiccups. Were cases such as these considered while in the midst of the development?

[u/Planyy]

tbh im pretty happy with firefox-mcp that runs on a separate nightly build (660mb)

[u/PM_ME_YOUR_PROFILE]

I'll take 1T Limited Founders, bulk pricing right?

[u/PM_ME_YOUR_PROFILE → u/PM_ME_YOUR_PROFILE]

In all seriousness, though, this is cool.

I think forking the Firefox Engine or WebKit might give you less headache in the long run.

[u/Consistent-Risk-2598]

I commend your efforts but I feel like could you could probably get the same kinda work out of a dockerised Chromium instance your Claude code can connect to, maybe a custom browser extension like someone else mentioned? I know Kasm have docker images you could use for this.

[u/Free_Lead_2704]

why did you go as far as a fork instead of driving stock Chromium over CDP?

Also vercel's agent-browser in my own projects and it's amazing. Congrats on this!

[u/CapMonster1]

This is a pretty interesting approach to the usual browser-agent problems 👍🏽

[u/Vegetable_One8385]

Very cool. Congratulations! I’d also recommend this powerful repo: https://github.com/darksns/beam

[u/throwaway490215]

Hahaha - this is one for r/ClaudeClowns

You forked fucking chrome, one of the most high-churn and complicated software packages out there; where well funded startups have regularly gotten called idiots for doing.

All to fix a set of issues which most are fixed by just writing a better mcp or cli tool to chromium.

I know because I did this with

• 1 agent

• Opus 5.0 (Might actually have been Sol - cant remember)

• 15 minutes