Muse web browser sessions are getting a manual override. On 27 September 2026, TestingCatalog, which tracks unreleased features in AI apps, posted a short video with the caption: “Muse agent users will soon be able to take over and operate the Muse web browser if needed.” A follow-up post from the same account minutes later narrowed the claim with three words: “via the web app”.
In practice, a person using Muse at muse.ai will be able to stop watching the agent’s browser and start driving it, clicking and typing inside the same session that Meta’s agent was using a moment earlier. Meta has not announced the control or given a release date, and features seen in test builds can change or be dropped before they reach users.
We covered the wider build, including a new screen tab and a voice-calling widget, in our report on the Muse agent’s dedicated VM tab. This article focuses on the takeover itself: how manual control of the Muse web browser works, when you would want it, what Meta says happens to the agent and your passwords while you drive, and how the design compares with ChatGPT agent, Operator and Claude in Chrome.
Table of contents
- What TestingCatalog Showed About the Muse Web Browser
- How Manual Control of the Muse Web Browser Works
- When to Take Over the Muse Web Browser
- Why the Muse Web Browser Still Needs a Human Hand
- Manual Control and Muse Web Browser Security
- Muse Web Browser Takeover Compared With Other Agents
- Takeover Is One of Several Muse Web Browser Controls
- What Is Confirmed About the Muse Web Browser Takeover
- Muse Web Browser Advice for Muse Agent Users and IT Teams
- Frequently Asked Questions About the Muse Web Browser Takeover
- References
What TestingCatalog Showed About the Muse Web Browser
The evidence so far is thin but specific: one video, one caption and one clarification, all posted to Threads on the same day.
The clip and its caption
The takeover post went up on the evening of 27 September (UK time) with a video attached and a light-hearted sign-off: “Muse users = Musers”. It followed an earlier post that day showing a dedicated tab where people can watch the screen of the agent’s virtual machine (VM). The two features belong together. A screen you can watch is the natural place for a control that lets you take the wheel.
TestingCatalog did not say when the control will ship or who will get it first. It described manual control of the Muse web browser as something users “will soon be able” to do, which is how the site usually labels a feature found in a build rather than one in a public release.
“Via the web app”: what the clarification adds
The follow-up post matters because Muse runs in several places. Meta’s launch announcement says Muse is “rolling out in the US on iOS, Android, and muse.ai”, and there is also a Muse app for the Mac. The clarification ties the new control to the web client at muse.ai, not to the phone apps or the Mac.
It does not say whether the phone apps already offer something similar. Meta’s 8 September security post says users “can see what Muse is doing in the browser and take over at any time” without naming a platform. The web control may be new, or it may bring the web client into line with the others. Meta has not said which.
How takeover fits with the Muse web browser screen tab
The screen tab and the takeover control answer different questions. The tab answers “what is the agent doing?” The takeover answers “what do I do when it is wrong, stuck, or at a step it should not handle alone?” Together they turn the Muse web browser from something the agent uses on your behalf into something you share with it.
How Manual Control of the Muse Web Browser Works
Meta has published more about the machinery behind Muse’s browser than most agent makers, so it is possible to describe what a takeover involves before the web control ships.
A real browser on a computer you never see
“You and your Muse share your own dedicated computer in the cloud,” Meta’s security post on Muse says. “Each Virtual Machine(VM) is an isolated linux box with a browser.” That browser is “a real up-to-date Chromium based browser running behind a virtualization layer”. When you watch the agent work, you are watching a live browser on a Meta-hosted machine assigned to you, not a replay.
Manual control means your clicks and keystrokes travel from the muse.ai tab on your own computer to the Muse web browser on that VM. Meta has not described the streaming technology it uses. The principle is the same as any remote desktop tool: the picture comes to you, and your input goes back to the machine.
The agent stops when you start
Meta’s design treats takeover as a hard handover. “When the user takes over control of the browser, or while secure credential storage is filling a form, the agent is paused and can’t act at all,” the security post says. If a person and an agent could both act in the same browser at once, each could undo the other’s work. Worse, a hidden instruction on the page could steer the agent while the person’s attention was on a form.
The agent never drives the Muse web browser directly in the first place. A “separate broker” manages the Chrome DevTools Protocol connection, and the browser sub-agent “sees an accessibility tree snapshot of the page — not the raw DOM”. It cannot run JavaScript in the page, and Chrome developer tools are disabled. Because the agent only reaches the Muse web browser through that narrow channel, pausing it is a clean switch.
Handing the Muse web browser back
Meta has not described how the agent resumes after you finish. OpenAI’s help centre for ChatGPT agent shows why this is harder than it sounds. “After you complete the required step and return control, the agent attempts to continue from the prior workflow state,” it says, adding that “in some cases it may need to re-establish the run or prompt you again”.
The difficulty is that the page has changed while the agent was paused. You may have logged in, closed a pop-up or moved to a different page. A good resume step has to take a fresh look at the Muse web browser before acting, rather than carrying on from where the agent thinks it left off.
What the agent can see of your session
Because the sub-agent reads an accessibility tree rather than raw page code, Meta says “it can’t read credentials entered from the credential store”. The company’s launch announcement goes further: “Muse has no visibility into people’s passwords or payment methods. Any credentials a person shares go into secure storage, so Muse can use them without seeing them, including passwords a person types into the browser themselves.”
That final clause is the one that matters most for manual control. It says a password you type into the Muse web browser yourself is treated like one entered through Muse’s dedicated login screen. Meta has not explained how it detects and diverts a typed password, so treat it as a stated design goal rather than something users can check for themselves.
When to Take Over the Muse Web Browser
Meta’s design essay on Muse describes the default like this: Muse “allows for standard browsing of the web and stops for anything hard to undo”. Manual control covers the ground between those two states, where a step is neither routine browsing nor a formal approval.
Logins and passwords in the Muse web browser
Signing in is the most common reason to take over. “One of the most common things users want is to sign in to websites in the browser,” Meta’s security post says. It built “a custom UI on the client to capture your username and password” and route them “directly to authd”, a credential service kept outside the agent’s container. Manual control gives a second route for sites where that screen does not fit, such as unusual login flows. Meta has also said 1Password support is coming “so Muse can use logins a person already has”.
One-time codes and password resets
Here Meta’s own design makes a person necessary. “Muse’s email connector filters out one-time tokens, password reset links, and login magic links via both deterministic filters and a classifier model,” the security post says. The reasoning is sound: an agent that could read those codes could be tricked into using your inbox to take over your other accounts.
The consequence is that when a site sends a verification code, the agent cannot fetch it for you. A person has to, and the Muse web browser is where they will type it.
CAPTCHAs and human checks
Sites use CAPTCHAs to tell people from software. OpenAI trained Operator “to proactively ask the user to take over for tasks that require login, payment details, or when solving CAPTCHAs”. Meta has not said how Muse handles them. A takeover control is the obvious answer, because the check is designed for a person sitting at the Muse web browser.
Choices only you can make
Some steps are matters of taste rather than rules. In the closed alpha, TestingCatalog saw Muse use a browser widget to “open a cinema website, select seats, and handle the booking”. Picking a seat, a room with a view or a delivery slot is often quicker to do than to describe. Manual control lets you make the choice in the Muse web browser and hand the rest of the task back.
When the agent is stuck in the Muse web browser
Agents still fail, as the next section shows. A page redesign, a pop-up the model misreads or an unusual form can leave the agent looping. The screen tab tells you something is wrong. Taking over lets you fix it without abandoning the task and starting again.
Sites that do not want agents
Manual control does not change a site’s rules. On 20 September, Amazon began showing Muse users a message that “Continued access by an unauthorized AI agent violates Amazon’s Conditions of Use”, as we reported in our coverage of Amazon’s Muse block. Meta’s security post notes that “When Muse browses the internet, it will appear as your activity”. A person typing into the Muse web browser is still browsing from Meta’s VM, so takeover is not a way around a site that has refused agents.
| Situation | Why a person may be needed | What Muse does by design |
|---|---|---|
| Signing in | The agent must never see the password | Custom credential screen routes it to authd; the agent is paused while it fills the form |
| Verification code or reset link | The agent cannot read these from email | Email connector filters out one-time tokens, reset links and magic links |
| CAPTCHA | The check is meant for a human | Not stated by Meta |
| Checkout | Real money is at stake | Detects checkout pages and asks for approval with the exact purchase details every time |
| High-risk form | Submitting may be hard to undo | Classifiers block the action or ask the user to review it |
| Seat, size or slot choice | Quicker to pick than to describe | Asks in chat; takeover lets you pick directly |
| Agent stuck or looping | Fixing one step saves restarting the task | Activity log and screen view show the problem |
Why the Muse Web Browser Still Needs a Human Hand
Two kinds of published evidence explain why serious browser agents ship with a takeover control. Agents still fail a meaningful share of web tasks, and web pages can be used to attack them.
Web agents still miss a real share of tasks
WebArena is a benchmark of realistic tasks on self-hosted shopping, forum, code and content management sites. When it was published in 2023, its authors reported that their “best GPT-4-based agent only achieves an end-to-end task success rate of 14.41%, significantly lower than the human performance of 78.24%”. In January 2025, OpenAI reported 58.1% for its Computer-Using Agent, the model behind Operator, against a previous best of 57.1% for web browsing agents.
That is a big improvement, but read the other way it means about 42 of every 100 tasks still failed (100 − 58.1 = 41.9), against about 22 for humans (100 − 78.24 = 21.76). Newer models have been released since, and Muse runs on Meta’s own Muse Spark, which has no published WebArena score. The point is the pattern: even strong agents fail often enough that a person needs a way into the Muse web browser.
Full computer use is harder still
OSWorld tests agents on whole operating systems, such as Ubuntu, Windows and macOS, rather than single websites. OpenAI reported 38.1% for its Computer-Using Agent in January 2025, against a previous best of 22.0% and human performance of 72.4%. On that measure, the best agent of the time completed roughly half as many tasks as a person (38.1 ÷ 72.4 = 0.53).
Pages can attack the agent
The second reason is prompt injection: instructions hidden in a page, image or file that try to steer the agent. Anthropic tested Claude in Chrome against “123 test cases representing 29 different attack scenarios”. Without its new safety measures, attacks succeeded 23.6% of the time; with them, 11.2%. On a “challenge” set of four browser-specific attack types, the new measures cut the success rate “from 35.7% to 0%”.
Meta takes the problem just as seriously. Its security post cites Simon Willison’s “lethal trifecta” of access to private data, exposure to untrusted content and the ability to communicate externally. Muse runs classifiers that look for prompt injection “within the DOM of the web page”, “via images/media on the web page” and “via files downloaded via the browser”. Its bug bounty pays “up to $130,000 for successful prompt injection attempts that affect one user”.
A person who can take over the Muse web browser is the final layer. Someone watching a suspicious page can simply decline to do what it says.
What these numbers do not tell you
None of these figures measure Muse. They are vendor and academic results on fixed test sets from 2023 and 2025, and newer models perform better. They are here because they show the size of the gap that a takeover control exists to cover, not to predict how often a Muse user will need to step in.
Manual Control and Muse Web Browser Security
Takeover changes the security picture in both directions. It gives the user a way to stop a problem, and it puts a person’s own actions into the agent’s workspace.
Pausing protects the sensitive moment
The most sensitive seconds in any agent session are when a password or card number is on screen. Meta pauses the agent both when a person takes over the Muse web browser and when its credential store fills a form. While the secret is being entered, the agent cannot click, type or read the field, which limits what a confused or manipulated agent could do with it.
What happens to the Muse web browser screen while you drive
OpenAI is explicit about its own product. “While you control the browser, screenshots are not captured,” its help centre says, and Operator’s launch page says it “does not collect or screenshot information entered by the user”. Meta has not published an equivalent statement about takeover in the Muse web browser. It says the sub-agent reads an accessibility tree and that typed passwords go to secure storage, but not whether the view you drive is logged. That is a fair question to ask before using the feature on sensitive accounts.
Meta has also promised Muse Confidential VM “later this year”, in which “the whole VM, including a person’s data and conversations with Muse, is encrypted with a key only they hold, so not even Meta can access it”. That would change the privacy picture for everything inside the Muse web browser, takeover sessions included.
Your session stays behind when you leave
A browser keeps you signed in after you log in, and that is the point of taking over for a login. You sign in, hand back, and the agent carries on inside a session it could not open itself. It also means the agent can then act as you on that site, within Meta’s approval rules. OpenAI advises ChatGPT agent users to “Clear remote browser data after sensitive sessions”, and the same habit makes sense in the Muse web browser: sign out of sites you no longer need the agent to use.
Muse’s security record so far
Muse’s first month has shown why the details matter. A researcher published a working hijack of the Mac app, covered in our report on the Muse security flaw, and Meta later strengthened its Muse safety warning after a bug bounty report. Neither involved browser takeover, but both are reminders that an agent with its own browser, your logins and your email is a new kind of endpoint. It is basic cybersecurity practice to be able to see such a system and to stop it.
Muse Web Browser Takeover Compared With Other Agents
Takeover is now a standard feature of browser agents, but the implementations differ in ways that matter for anyone comparing them with the Muse web browser.
Operator set the pattern
OpenAI’s Operator launched as a research preview on 23 January 2025. “Users can choose to take over control of the remote browser at any point,” OpenAI said. Operator also had a watch mode: “On particularly sensitive sites, such as email or financial services, Operator requires close supervision of its actions.” And before “submitting an order or sending an email, Operator should ask for approval.”
ChatGPT agent made it mainstream
ChatGPT agent, launched on 17 July 2025, brought Operator’s browser into ChatGPT. “You can easily interrupt, take over the browser, or stop tasks at any point,” OpenAI said. Users take over from a menu, and when a task needs a login, “ChatGPT agent will pause and prompt you to take control of the virtual browser”. Its Watch Mode means “Certain critical tasks, like sending emails, require your active oversight.”
Claude in Chrome works in your own browser
Anthropic took a different route. Claude in Chrome is an extension that acts inside the browser you already use, piloted with “1,000 Max plan users” from 25 August 2025 and later released in beta to all Max plan subscribers. There is no remote browser to take over, because you are already sitting at it. Control comes through site-level permissions and confirmations before “high-risk actions like publishing, purchasing, or sharing personal data”.
The Muse web browser versus your own computer
The split matters for Muse, which now uses both models. The Muse web browser runs on Meta’s cloud VM, so a takeover control is the only way to act inside it. Muse for Mac is different. Meta’s Connect recap says “With your permission, Muse can now drive any app on your Mac”, which puts the agent on your own machine, where you can simply reach for the mouse. Our Connect roundup of the Muse updates covers that launch.
| Feature | Muse (web) | ChatGPT agent | Operator (2025) | Claude in Chrome |
|---|---|---|---|---|
| Where the browser runs | Chromium on a dedicated cloud VM per user | “Its own virtual computer” | A remote browser | Your own Chrome |
| How you take control | “Take over at any time” (8 September); a web app control shown as coming soon | “Take over browser” from a menu; prompted for logins | Takeover at any point; asked for logins, payments and CAPTCHAs | Not needed: you are already at the browser |
| Agent during takeover | “Paused and can’t act at all” | Pauses, then tries to resume from the prior state | Hands control back to the user | Not applicable |
| Screen capture while you drive | Not stated; typed passwords go to secure storage | “Screenshots are not captured” | Does not collect or screenshot what the user enters | Not applicable |
| Extra supervision | Stops for anything hard to undo; approval at every checkout | Watch Mode for critical tasks such as sending email | Watch mode on email and financial sites | Site permissions; high-risk categories such as financial services blocked |
Takeover Is One of Several Muse Web Browser Controls
Manual control sits alongside other safeguards that often do more of the work, because they apply whether or not anyone is watching.
Approval cards, not chat messages
When an action needs permission, Meta’s Sentinel service presents “A dialog … directly within the client UI — not via their conversation with Muse”. That stops a web page open in the Muse web browser from faking a permission request inside the chat. Approvals can be “one-time, session-scoped, task-scoped, time-bounded, or perpetual”, and Sentinel “decides which grant types to present”.
Avoiding banner blindness
Meta’s designers are wary of asking too often. Their essay says they “wanted to avoid banner blindness — where people approve everything to make it go away”. So the default “stops for anything hard to undo”, and users can change it “to be more or less cautious”. Takeover fits that approach. It is a control you reach for when you choose, not a prompt that interrupts you.
Checkout gets special treatment
Purchases are handled most carefully. On sites where your card is already saved, Muse detects “that you’re on a checkout page” and asks for approval “with the exact details of the purchase every time”. Elsewhere, it pays with a single-use card through Link by Stripe, and the credential is “tied to that particular merchant, a particular dollar amount, and only valid for a limited period of time”.
| Control | What it does | Who starts it |
|---|---|---|
| Screen view | Shows the live browser on the agent’s VM | The user |
| Manual takeover | Pauses the agent while a person drives the browser | The user (web app control in testing) |
| Credential screen | Captures a username and password and sends them to authd | The user, when signing in |
| Sentinel approval | A dialog outside the chat for connector actions and network requests | Sentinel |
| Browser classifiers | Block or flag data leaks, prompt injection and high-risk forms | Automatic |
| Checkout approval | Shows the exact purchase details every time | Automatic at checkout |
| Single-use card | Limited to one merchant, one amount and a short period | Automatic at payment |
What Is Confirmed About the Muse Web Browser Takeover
Most of this story comes from a test build, so the evidence behind each claim matters.
Confirmed by Meta
Meta has confirmed the dedicated cloud VM, the Chromium browser, the ability to see and take over the browser, the pause during takeover and credential filling, the credential screen, Sentinel approvals and checkout approvals. It has also said that passwords typed into the browser go to secure storage. These come from its security post, its launch announcement and its design essay.
Seen only in testing
The dedicated takeover control in the web app has only been seen in a video and caption shared by TestingCatalog on 27 September, with the “via the web app” clarification. Meta has not announced it, so the version users eventually get could look different.
Still unknown
It is not known when the web control will ship, whether it will reach every user at once, or whether the phone and Mac apps will get the same control. Meta has also not said whether the screen is recorded while a person drives the Muse web browser, or how the agent re-reads the page when control is handed back.
| Claim | Source | Evidence level |
|---|---|---|
| Users can see the browser and take over at any time | Meta AI Research, 8 September | Confirmed by Meta |
| The agent is paused during takeover | Meta AI Research, 8 September | Confirmed by Meta |
| Passwords typed into the browser go to secure storage | Meta launch announcement, 8 September | Confirmed by Meta |
| Email connector filters out one-time codes and reset links | Meta AI Research, 8 September | Confirmed by Meta |
| A takeover control is coming to the web app | TestingCatalog on Threads, 27 September | Seen in a test build |
| Screen recording during takeover, resume behaviour, release date | None | Unknown |
Muse Web Browser Advice for Muse Agent Users and IT Teams
None of this needs action today, but the takeover control is a good prompt to think about how an agent with its own browser is used at home and at work.
Before you rely on takeover
Use Muse’s credential screen for logins where it works, and keep manual entry in the Muse web browser for flows it cannot handle. Expect to supply verification codes yourself, since the agent cannot read them. Watch the screen on unfamiliar sites, take over when a page looks wrong, and prefer one-time or task-scoped approvals until you trust how the agent behaves on a given site. Sign out of sites the agent no longer needs.
For IT and security teams
A consumer agent with its own browser, stored logins and access to email is effectively a new endpoint outside your estate. If staff sign a Muse agent into work accounts, sessions for company systems can sit on a Meta-hosted VM. Cover personal AI agents in acceptable use policies, and include agent-held sessions in penetration testing scopes where they touch company systems. A written AI strategy that says which agents may act on company data, and under whose approval, is the simplest control of all.
Frequently Asked Questions About the Muse Web Browser Takeover
Can I take over the Muse web browser today?
Meta’s 8 September security post says users can see what Muse is doing in the browser and take over at any time. A dedicated control for this in the web app was shown on 27 September as coming soon, and Meta has not announced a date.
Does Muse keep working while I control the Muse web browser?
No. Meta says that when a user takes over the browser, “the agent is paused and can’t act at all”. It is also paused while Muse’s credential store fills in a login form.
Can Muse see a password I type into the Muse web browser?
Meta says Muse has no visibility into passwords, “including passwords a person types into the browser themselves”, which go to secure storage. It has not explained how that works for typed entries.
Why can’t Muse enter verification codes for me?
Muse’s email connector deliberately filters out one-time tokens, password reset links and login magic links, so that nobody can trick the agent into taking over your other accounts. You enter those codes yourself.
Is takeover the same as the new screen tab?
No. The screen tab lets you watch the agent’s browser. Takeover lets you control it. Both were seen in Muse web builds shared by TestingCatalog on 27 September.
References
TestingCatalog on Threads: Muse agent users will soon be able to take over the Muse web browser
TestingCatalog on Threads: via the web app
TestingCatalog: Meta prepares screen viewing and web voice calls for Muse
TestingCatalog: Meta’s Muse agent enters closed alpha with invite codes
Meta AI Research: How We Built Safety Into Muse
Meta: Introducing Muse, the World’s First Personal AI Agent Built for Everyone
Meta: Everything We Announced at Meta Connect 2026
OpenAI: Introducing ChatGPT agent
OpenAI Help Center: ChatGPT agent
Anthropic: Piloting Claude in Chrome
WebArena: A Realistic Web Environment for Building Autonomous Agents
OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.
