原文要点
原文完整内容
I've been trying to get reliable browser automation working with Claude Code for months and I'm still at maybe 50% success rate. Would love to hear what actually works for people in practice.
\\My current setup:\\
- Google Chrome Beta installed as a separate instance
- Logged in with my main account, launched with --remote-debugging-port so it can be controlled remotely
- Using agent-browser CLI tool to connect and interact
- Headless mode for most tasks
\\The problems I keep hitting:\\
- Claude tries WebFetch first, gets blocked by sites that reject AI crawlers, then has to fall back to browser
- agent-browser sessions hang randomly — timeouts with nothing happening
- Pages that are slow to load cause cascading failures
- Claude loses track of which tool to use (fetch vs browser vs MCP) and wastes context trying wrong approaches
- When it does work, the flow is fragile — one missed wait or stale ref breaks the whole chain
\\What I've tried:\\
- Playwright MCP (too much context bloat, 33 tools eating tokens)
- Direct Playwright scripts (better but feedback loop is slow)
- agent-browser skill (promising but reliability issues)
- Various [CLAUDE.md](http://CLAUDE.md) instructions to guide tool selection
I searched this sub and found a lot of good discussion — people recommending Playwright CLI directly over MCP, Docker-based Playwright being more stable, OpenBrowser MCP for token efficiency, dev-browser skill, subagent patterns to isolate browser context.
This is my current best working skill [https://github.com/dandaka/skills/blob/main/real-browser/skill.md](https://github.com/dandaka/skills/blob/main/real-browser/skill.md)
\\What I'd love to hear from you:\\ 1. What browser tool/setup do you actually use daily? 2. How do you handle the WebFetch → browser fallback gracefully? 3. Any tips for making sessions more reliable (fewer hangs/timeouts)? 4. Do you use a subagent for browser work to protect main context? 5. For those using agent-browser or similar CLI tools — how do you deal with ref lifecycle and page transitions?
Thanks in advance — this feels like one of the biggest pain points in the Claude Code workflow right now.
原文配图
原帖关键讨论
maybe all checkpoints
Disclosure: I am the author of Panerelay. Your Chrome Beta + remote-debugging-port + agent-browser setup is exactly the workflow that pushed me to build it.
Panerelay plugs into agent-browser as a local provider, but the browser side is the Chrome session you already use. The extension exposes only tabs you explicitly authorize, and your profile/login state stays in Chrome. There is no need to relaunch Chrome with a debug port or approve a fresh direct-CDP attachment for every agent session. Agent-side tab selection is virtual, so background automation does not activate the page or steal focus.
The command surface remains normal agent-browser:
agent-browser --provider panerelay tab list
Repo: https://github.com/F-loat/panerelay (MIT)
This deliberately does not claim to fix stale refs, waits, or anti-bot behavior. I still use the same discipline you mentioned: re-snapshot after page changes, wait for specific state, and isolate browser work when it gets long. The project only removes the launch/session/authorization and focus friction around using your real logged-in browser.
Browser Use with Browser Harness is worth trying — it runs one persistent real browser session and uses screenshots plus page-state checks instead of dumping the whole DOM at the agent, so you don't get the stale refs or context explosion. If you want profiles that survive across sessions or a live URL you can actually watch while it runs, their cloud browser covers that too.
This week, Opera Neon released an MCP connector that lets you connect Claude Code directly to the browser, controlling it fully, including access to other models than Anthropics, Deep Research, and Agentic Browsing
The biggest reliability win for me was stopping browser automation from depending on “whatever tab is active right now.”
Full disclosure: I’m building an open-source macOS MCP called Mac MCP: https://github.com/bulutarkan/mac-mcp
The browser layer gives Safari/Chrome tabs stable handles that survive tab-index changes, and every action can target that exact tab in the background. After navigation/state changes I re-observe instead of trusting stale refs, and there’s a bounded no-progress breaker so an agent doesn’t sit there retrying the same dead action forever.
For logged-in work I prefer the user’s real browser profile rather than a disposable automation profile. It doesn’t magically solve anti-bot systems, but it removes a lot of the session/login/focus churn that made long runs flaky for me.
I still keep API/CLI first when they exist; browser control is the fallback for the long tail of sites and internal tools that don’t expose a useful interface.