Qwen Code 0.24.1 Browser Use: control signed-in Chrome tabs without leaving access behind

Quick answer

Qwen Code 0.24.1 adds Browser Use through a built-in skill, a Playwright-based SDK, and a Chrome Native Messaging relay. It can work with tabs in your existing Chrome profile, including signed-in sessions. That is useful, but it is also the security boundary: the model can receive task-relevant page content through your configured model provider.

Use a dedicated Chrome profile, inspect the exact tab returned by browser.user.openTabs(), claim only that object, and finish with browser.tabs.finalize(). Disabling the skill in /skills prevents future discovery; it does not disconnect an active session, erase instructions already loaded into the current conversation, or remove the persistent native host. Full removal requires uninstalling the native host and the Chrome extension.

Who this is for

This guide is for developers evaluating Qwen Code Browser Use on macOS or Linux with Chrome 125 or newer, especially against an already signed-in site.

This is not the same boundary as Qwen Code Remote Serve, which exposes a daemon and bearer-token route. Browser Use does not require qwen serve or an exposed Chrome debugging port. If your workflow also loads arbitrary JavaScript or MCP tools, audit that separate runtime with the Qwen Code Node REPL and MCP checklist.

What changed in 0.24.1

The official 0.24.1 release, published September 19, lists two Browser Use changes: a Playwright-based Browser SDK and a Chrome Native Messaging relay. The tagged source is commit e443e2d2384e3ba61d783bd96a265082298f4fe8.

The Chrome extension is not bundled with Qwen Code and the official documentation provides no Chrome Web Store listing. Build it from the repository and load it unpacked. The first Browser Use task registers a native host in the user account; later sessions reuse it.

Official source and documentation confirm these boundaries:

Layer	What becomes available	What stops it
Skill discovery	The model can see the Browser Use skill	Disable it in /skills, then start a fresh conversation
Conversation instructions	The current conversation may already contain loaded skill instructions	Start a new conversation; toggling the skill does not erase them
Runtime and tab claim	The runtime can list eligible tabs and claim an exact tab	Finalize or end the runtime; do not retain stale handles
Native host	Chrome can reconnect to the local Qwen relay	Run the native-host uninstall command
Chrome extension	The profile grants tabs, debugger, history, native messaging, storage, and tab-group permissions	Disable or uninstall the extension from that profile

The extension communicates with Qwen Code locally, but the workflow is not necessarily end-to-end local. Task-relevant browser data may reach the configured model provider. Treat that route and its retention policy as part of the design.

A reversible Browser Use workflow

1. Isolate the browser profile

Create a dedicated Chrome profile with only the accounts and sites needed for the canary. Install the unpacked official extension there and record its ID, profile, Qwen Code version, and source commit.

2. Start with a harmless read-only task

Open a local fixture or non-sensitive page. Ask Qwen Code to enumerate tabs, read a unique marker, and stop. Avoid any action that can publish, purchase, delete, or send.

3. Discover, then claim the exact object

Use the exact browser.user.openTabs() result in browser.user.claimTab(). The SDK checks that title and URL have not changed and fails closed when discovery is stale. Never guess a tab ID.

New tabs inherit the selected Chrome profile's cookies and signed-in state. That is convenient, but it is also why the profile must be deliberately scoped.

4. Keep the task and evidence minimal

Give one bounded objective, a stop condition, and forbidden actions. Keep only acceptance evidence; redact tokens, cookies, private query strings, and unrelated page content.

5. Finalize every run

End with browser.tabs.finalize({ keep: [] }) when no tab is a deliverable. Created tabs close; claimed user tabs are released without closing. List an intentional deliverable explicitly in keep.

A kernel reset invalidates JavaScript handles but does not reset Chrome or its signed-in profile. After a reset, initialize the runtime again and rediscover the tab instead of reusing an old handle.

Disable versus remove: a decision tree

Do you only want future conversations to stop discovering Browser Use?
  yes -> disable the skill in /skills, then start a new conversation
  no  -> continue

Do you need to end control for the current run?
  yes -> call browser.tabs.finalize(), end the runtime, and verify the tab is released
  no  -> continue the bounded canary

Do you want Chrome unable to reconnect to Qwen Code later?
  yes -> uninstall the native host AND disable or remove the Chrome extension
  no  -> keep both installed and document the residual access path

The official extension README documents these native-host checks:

node /runtime/scripts/native-host-setup.js status
node /runtime/scripts/native-host-setup.js uninstall

The launcher and manifests persist after Qwen Code exits. Removing only the host is incomplete: an installed extension can allow a later task to register it again. Verify both sides.

Five canaries before real accounts

1. Wrong-profile denial: run against a profile without the target account and confirm the task cannot silently reach the daily profile.
2. Stale-tab denial: discover a tab, change its URL, then prove the old discovery object cannot be claimed.
3. Provider boundary: use a unique harmless marker and confirm exactly which prompt, page evidence, and logs contain it.
4. Finalize behavior: verify created tabs close, claimed tabs stay open but are released, and no task can mutate them afterward.
5. Removal persistence: exit Qwen Code, check native-host status, uninstall it and the extension, restart Chrome, and prove Browser Use cannot reconnect.

These are acceptance tests, not reported results. This source-based guide does not replace testing your own profile, provider, and policy controls.

Common mistakes

• Assuming a local extension means page data never reaches a model provider.
• Disabling the skill and treating an already loaded conversation as revoked.
• Closing Qwen Code but leaving the native host and extension installed.
• Claiming a guessed tab ID or reusing a stale discovery object.
• Letting a first canary operate in a daily signed-in profile.
• Forgetting that a runtime reset loses handles, not browser state.

Building something? Turn your product page into a show people want to watch with PromoFast—hosted, embeddable, and ready to export.

FAQ

Does Browser Use require qwen serve?

No. The official extension README says the Browser Use path uses the built-in skill, SDK, Node REPL, and Native Messaging relay without qwen serve or an exposed Chrome debugging port.

Can it use an existing signed-in session?

Yes. It can claim eligible existing tabs and new tabs share the selected profile's signed-in state. Use a dedicated profile and least privilege.

Is disabling the skill a kill switch?

Not for an active or already loaded conversation. Disable it for future discovery, start a new conversation, finalize the current runtime, and remove the host plus extension when you need full revocation.

Does 0.24.1 officially support Windows Browser Use?

The documented automatic native-host setup is for macOS and Linux. Do not infer Windows support from the generic Chrome extension alone.

Sources

• Qwen Code 0.24.1 release
• Qwen Code Browser Use documentation
• Official Chrome extension README at v0.24.1
• Official Chrome extension privacy disclosure at v0.24.1
• Official Browser Use skill instructions at v0.24.1
• Official Chrome runtime documentation source at v0.24.1

Originally published on IndieSeek.