n8n Browser Use: What It Does and How to Lock It Down

On October 6, n8n shipped 2.43.0 with a one-line changelog entry: "Release Browser Use to all users." That line removed a PostHog feature flag. Before it, Browser Use only showed up on instances that were in the experiment, which is why a thread on the n8n forum titled "What is this and how can I try it?" got the answer "there's probably nothing to test right now." Now there is, and almost nobody has written down what it does.

Here's the short version. The n8n Assistant (the agent in the editor's side chat that builds and edits workflows) gets a new connection type. You install the n8n Browser Use extension (about 7,000 users when I checked), hit Connect browserin the Assistant's + menu, and the agent can now open tabs, read pages and click around in your actual Chrome. The test plan in the release PR shows the intended use: "Walk me through the Slack admin to get my OAuth Client ID and Client Secret."

That's the pitch: the most annoying part of n8n, hunting for API keys in someone else's dashboard, handed to the agent. It's a good idea. It also means an LLM is operating a browser that's logged into everything you are.

No, and Google makes this confusing. Search "n8n browser use" and most of page one is about the community node from the Browser Use company. Different product, different risk:

If you want a browser as a step in a production workflow, the native feature isn't it. It lives in the editor chat and needs your Chrome open. For runtime browsing, the node or an API is still the answer, and an API beats both whenever one exists. I measured that gap in computer-use agents vs structured APIs.

I pulled the n8n 2.43.3 source to find out, because the UI doesn't say. The browser toolkit lives in @n8n/mcp-browser, and its README is blunt: it "gives AI agents full control over Chrome" using "their actual profile, cookies, and sessions." I counted 32 tools:

navigate, back, forward, reload, tab_open, tab_list, tab_focus, tab_close
click, type, press, hover, drag, select, scroll, upload, dialog, wait
snapshot, screenshot, content, pdf, console, network
cookies, storage, evaluate            <- the ones to think about
capture_secret, create_credential     <- the reason it exists
connect, disconnect

browser_evaluate runs JavaScript in the page. browser_cookies and browser_storageread session state. On paper that's everything needed to lift a session out of your browser. So the guardrails matter, and there are three:

• Per-domain approval.Every tool call that touches a new host stops and asks: deny once, allow once, or allow for session. This rides on the Assistant's fetchUrl permission, which defaults to require_approval. Set it to blockedand every browser call fails with "Browser access blocked by admin."
• Credential writes ask every time. browser_create_credential is gated by createCredential, and there's deliberately no allow-for-session option. One click per credential.
• Secret redaction. Tool output passes through 73 regex patterns ported from gitleaks (Anthropic, OpenAI, AWS, Stripe keys, private keys and so on) before the model sees it. Captured secrets go to an in-memory buffer and straight into the credential, not into the chat.

The weak spot is "allow for session." Once you click it for a domain, the agent stops asking about that host for the rest of the session, including reads of its cookies. Combine that with a page that contains instructions aimed at the model, and you have the exact prompt-injection setup I wrote about in n8n prompt injection defense. Click "allow once" and accept the extra prompts.

1. Run n8n 2.43.0 or later with the Assistant configured. Check Settings > n8n Agent: the Browser Use toggle has to be on (it is by default).
2. Use desktop Chrome or another Chromium browser. The editor checks for the Blink engine and hides the feature on phones and tablets, including an iPad in desktop mode.
3. Install the extension in a dedicated Chrome profile. More on that below.
4. Open the Assistant, click +, then Connect browser. n8n mints a one-time link with a bu_token. It's valid for 5 minutes until the first connect. After that the session holds until you disconnect or n8n restarts.
5. Ask for something specific."Open the Google Cloud console and create OAuth credentials for this workflow" works better than "set up Google."

One thing changed in the same release: the "Set up automatically" option on the credential card is now hidden for everyone. You can still ask for browser-based setup in the chat. It just isn't a one-click button anymore.

This is where self-hosters will lose an evening. The extension doesn't talk to n8n over normal HTTP. It opens a WebSocket to /browser-use/extension/<sessionId>, and n8n builds that address like this:

// packages/cli/src/modules/instance-ai/browser/instance-ai-browser-session.service.ts
const base = new URL(this.urlService.getInstanceBaseUrl());
const scheme = base.protocol === 'https:' ? 'wss' : 'ws';
return `${scheme}://${base.host}`;   // host only, path dropped

Four ways that breaks:

• No public base URL. The base URL comes from N8N_EDITOR_BASE_URL, then WEBHOOK_URL, then protocol + host + port. Behind a proxy with none of those set, the extension tries ws://localhost:5678 and fails.
• Subpath installs. If n8n lives at example.com/n8n/, the path gets dropped and the extension connects to wss://example.com/browser-use/.... Your proxy has to route /browser-use/ at the domain root to n8n, or it lands on whatever else lives there.
• The proxy eats the upgrade. nginx needs the Upgrade and Connection headers forwarded on that path. Cloudflare Tunnel passes WebSockets by default, and in the 2.43.3 code a plain HTTP hit on those routes gets a 426from n8n. A 404 or your proxy's error page means the path isn't reaching n8n at all.
• The link expired. Five minutes. Generate a new one.

# nginx: same server block as the editor
location /browser-use/ {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 3600s;
}

One more I'd test before trusting it: the browser session lives in memory on the n8n process that created it, and the agent reaches it over 127.0.0.1. On a multi-main setup behind a load balancer, the extension's WebSocket needs to land on that same main. I haven't run it in multi-main, so treat that as a question, not a finding. If you're already fighting proxies on other self-hosted tools, my ComfyUI reverse proxy write-up covers the Cloudflare side.

On a solo or dev instance, yes, with a separate Chrome profile. On a shared or client instance, turn it off until you've decided who gets it.

The profile is the real control. Make a Chrome profile called something like "n8n agent," log it into only the consoles you set up credentials in (Google Cloud, Slack admin, HubSpot developer), and install the extension there and nowhere else. Then the worst an over-eager approval can expose is a handful of admin sessions you meant to share anyway, not your email and bank.

On client instances I'd flip the switch off at the env level, because the UI toggle can be flipped back by any admin:

# docker-compose.yml, n8n service
environment:
  - N8N_INSTANCE_AI_BROWSER_USE_ENABLED=false
  - N8N_EDITOR_BASE_URL=https://n8n.client.com/

There's a related switch, N8N_INSTANCE_AI_LOCAL_GATEWAY_DISABLED, for the Assistant's local computer tools (filesystem and shell through the local gateway). Different channel, same question. If you're already gating what agents can do, the approval pattern in n8n human-in-the-loop approvals is the same idea applied to your own workflows.

My own n8n runs in Docker on a Mac mini behind a Cloudflare Tunnel, and it's still on 2.38.3, so this isn't a "I've used it for a month" review. It's the checklist I ran before upgrading. I read the 2.43.3 tag directly: the browser session service, the MCP browser toolkit, the permission gate, the config class and the release PR (#39762). My instance already sets N8N_EDITOR_BASE_URL and WEBHOOK_URLto the public https host, so the base URL trap doesn't apply to me. The profile decision does. For how this compares with Anthropic's own browser tooling, see Claude's browser use tool vs computer use.