v1.9.0 — Browser use, interactive 2FA

What's new

n8n-claw stops being read-only on the web. Until now the agent could read pages (Crawl4AI as Web Reader, SearXNG as Web Search) but couldn't do anything — it couldn't sign you up for a newsletter, fill a contact form, click a button, log into a site to fetch private data, or run any multi-step UI flow. v1.9.0 ships Browser Use as a built-in capability: a real headless Chromium driven by an agentic LLM loop, exposed to the main agent as a single browser_action tool with three modes (task, list_sessions, close_session).

End-to-end validated on 2026-05-11 against the live VPS — newsletter signup on jens.marketing in 70s (5 LLM steps), seven-field pizza-order form on httpbin in 65s, top-5 HN stories with article-content summaries in 206s (12 steps), and a full interactive-2FA login round-trip to GitHub that actually starred a real repo as the authenticated user.

This is not a skill — it's a built-in agent capability like Memory or Web Reader. No install step. Pull v1.9.0, run setup.sh --force, and browser_action is wired into every chat.

The cherry on top emerged unplanned during real-world testing: interactive 2FA works end-to-end without any TOTP generator built into the bridge. The agent hits the 2FA wall, returns a focused message asking for the code, the keep-alive session pool keeps the 2FA page loaded in the live Chromium, the user reads the code from their authenticator app and sends it as the next Telegram message, the agent makes a follow-up browser_action call with the matching domain — the code lands on the still-open form, GitHub redirects to the dashboard, every subsequent task on that domain inherits the authenticated session. This was not a designed feature; it falls out of keep_alive=True plus the agent behaving sensibly when it doesn't have a tool for something — and it covers TOTP, SMS, and email-magic-link 2FA. The only 2FA flavour it can't cover is hardware-key / WebAuthn / passkey, because that needs a physical USB device the bridge doesn't have.

How it works under the hood

Browser Use 0.12.6 ships only an stdio MCP server, which n8n's HTTP-based MCP Client cannot speak to. So this release does not register a skill in mcp_registry — instead it ships a thin FastAPI sidecar (browser-bridge/, ~200 lines of Python) that adapts Browser Use's SDK to a normal HTTP API and runs alongside the existing bridges (email-bridge, file-bridge, discord-bridge). The agent's tool call → workflows/browser-use.json sub-workflow → http://browser-bridge:3400/tasks → live Chromium.

This shape gives us two things Browser Use doesn't have natively:

1. Keep-alive session pool keyed by (user_id, domain) — works around the broken save_storage_state in Browser Use 0.12.6 (Issue #1002, reproduced during the spike) by simply keeping the Chromium process alive between tool calls. Max 5 concurrent live browsers (BROWSER_BRIDGE_MAX_SESSIONS), 30-min idle eviction (BROWSER_BRIDGE_IDLE_TIMEOUT_S), LRU-evicted when full. All sessions die on container restart by design — this is the v1 trade-off until upstream fixes the persistence bug.
2. Per-request LLM provider routing — bridge reads tools_config.llm_provider on every POST /tasks and instantiates the matching browser_use.llm.Chat* class with the corresponding env-supplied API key. Switching providers does not require a bridge restart, and the bridge always follows whichever provider the main agent is currently configured for.

Critical Chromium args (--no-sandbox --disable-dev-shm-usage --disable-gpu + chromium_sandbox=False) are hardcoded in session_pool.py — without these the browser launch times out at 30 s on a headless Linux VPS. Spike-validated, future-proofed.

Engine decision — why Browser Use, not Skyvern

Data-driven, not vibes. A hands-on spike against Skyvern 1.0.36+ (the obvious AGPL alternative) on three identical tasks showed Browser Use winning decisively on the use case that matters: form fills.

Task	Skyvern	Browser Use
Newsletter signup (jens.marketing)	✅ 58 s / 3 steps	✅ 52 s / 5 steps
Cookie persistence (httpbin)	✅ with workaround	❌ save_storage_state raises ValueError
7-field pizza-order form (httpbin)	✅ 585 s / 16 steps	✅ 65 s / 4 steps

That 9× gap on form fill is not a tuning issue, it's an architecture gap — Skyvern is vision-based and bills one action per step (~36 s/step end-to-end including LLM call + screenshot + reasoning), Browser Use is DOM-based and bundles up to 5 actions per step. Skyvern Issue #4439 ("4–5 min for 5–6 fields") has been open since December and matches what was measured.

License pointed the same way: Browser Use is MIT, Skyvern is AGPL-3.0 with a network-clause that would have closed the door on the dmo-claw commercial fork. The cookie-persistence bug we worked around in browser-bridge's session pool is upstream-fixable; the Skyvern speed gap is architectural and would not have improved.

Validated

• Newsletter signup (executions 104677/104678) — jens.marketing, 70 s, 5 steps, agent dismissed cookie banner + navigated to signup form + entered email + checked privacy checkbox + submitted, returned the double-opt-in confirmation text. First production use of the feature.
• Session-pool reuse across separate tool calls (executions 104708 / 104711) — set freddy=test2 on httpbin.org with domain=httpbin.org, separate Telegram message minutes later called GET /cookies with the same domain and got {"freddy": "test2"} back. The v1 keep-alive design works end-to-end; persistent logins are real, just bounded by container lifetime.
• Interactive 2FA round-trip on GitHub (executions 104757 → 104760 → 104763 → 104776) — login with username + password hits the 2FA wall and returns cleanly with a "send me the code" message. User sends the 6-digit code as the next Telegram message; agent enters it on the still-open form; GitHub redirects to dashboard. Follow-up tasks (Star repo, read private notifications inbox) inherit the authenticated session. First documented interactive-2FA flow in n8n-claw.
• Multi-step browse + summarise (execution 104780) — top 5 HN stories with article-content summaries. 12 steps, 206 s, 5 different external sites opened, accurate 2-sentence summary each.

Breaking changes

None. No schema changes, no migration. The browser-bridge service is additive in docker-compose; the workflow + agent toolWorkflow are additive in n8n. Existing functionality is unaffected. setup.sh --force is required to install the new sub-workflow and re-seed the agents.browser_use system-prompt row.

Known limitations

• Anti-bot-protected sites are out of scope. Doctolib was the smoke test: two attempts, both timed out before reaching the appointment slots. Open-source headless Chromium without a residential-proxy network gets fingerprinted and slow-walked by serious bot detection (Cloudflare Bot Management, Datadome, etc.). Skyvern's Cloud product solves this with residential proxies + anti-bot fingerprint randomisation; open-source Skyvern hits the same wall. Plain mainstream sites without aggressive detection (GitHub, Hacker News, jens.marketing, httpbin, Substack-style forms) work fine.
• Hardware-key 2FA / WebAuthn / passkeys are not supported. Interactive 2FA covers TOTP, SMS code, and email-magic-link — anything where the second factor is a string the user can paste. WebAuthn requires a physical USB device the bridge cannot present.
• Sessions are in-memory only. Container restart (or setup.sh --force) wipes every pooled browser. Persistence-across-reboots needs Browser Use to fix save_storage_state (Issue #1002) — until then, expect to re-authenticate on each fresh deploy. The 30-min idle eviction also kills idle sessions inside one container lifetime.
• GitHub Personal Access Tokens are not valid UI-login passwords. PATs work for git push over HTTPS and for the REST API, not for github.com/login. Use real password + interactive 2FA instead — that's the validated path.
• CAPTCHAs. No solver. If a CAPTCHA appears the bridge returns the screenshot URL and asks the user to handle it. Browser Use 0.12.6 doesn't surface CAPTCHAs as cleanly as it does 2FA prompts — mileage may vary by site.

Resource impact

• ~500 MB – 1 GB RAM per active browser session. At the 5-session pool cap, expect up to ~3 GB peak. mem_limit: 3g on the service is a hard ceiling. VPS recommendation stays at 2 GB minimum (idle bridge is ~200 MB; the heavy footprint only materialises while a task is running).
• Container image is ~1.5 GB (Python 3.12-slim + Playwright + Chromium binary). One-time build; rebuilds via Docker layer cache are fast.
• LLM-token usage — typical task is 4–12 LLM round-trips with vision-enabled prompts (~5–20k tokens per round-trip including screenshot). A newsletter signup costs roughly the same as a moderate-length conversation turn.

Examples — what you can ask your agent

Plain natural language, no special prefixes. The agent routes anything that needs UI interaction to browser_action.

Newsletter / contact forms:

Sign me up for the Lenny's Newsletter on lennysnewsletter.com with my email

Agent finds the signup form, enters the email, submits, returns the confirmation.

Logged-in actions with interactive 2FA:

Log into github.com with username freddy-schuetz and password X — and star browser-use/browser-use after

Agent submits credentials, hits 2FA wall, asks for the code, you reply with the TOTP, agent enters it, then stars the repo. All on the same live browser session.

Multi-step research with content extraction:

Open the top 5 stories on Hacker News, read each, and give me a 2-sentence summary per story

Agent navigates, clicks into each story, reads, returns a tidy summary table.

Persistent logins across calls:

Read my latest GitHub notifications

If you're still inside the 30-min idle window from an earlier login, the agent reuses the existing session. If not, it'll prompt you to log in again.

Cookie-based session debugging:

Go to httpbin.org/cookies/set?env=prod and tell me what URL you ended up on

Test target for verifying the session pool — set with domain=httpbin.org, read again on a later call to confirm cookies are preserved.

Install

git pull
./setup.sh --force

That's it. The browser-bridge container is built locally (~3–5 min one-time, ~30 s on rebuild), the Browser Use sub-workflow is imported and activated, the Browser Action tool is wired into the AI Agent, and the agents.browser_use system-prompt row is seeded. No credentials to enter — the bridge inherits the same LLM-provider API key the main agent uses.

Pricing note

The browser-bridge service itself is free (MIT-licensed open source). LLM token costs apply: each browser task is 4–12 LLM round-trips with vision-enabled screenshots, so it's noticeably more expensive than a plain chat turn — roughly comparable to a few Crawl4AI fetches. Use the Web Reader (free, no LLM round-trip) for plain page reads, and reserve browser_action for things that genuinely need a browser (forms, clicks, logged-in state).