The short version: if you use Muse to run YouTube or Facebook uploads through its browser, the step where the browser picks the video file off the machine no longer works. We hit the wall ourselves on 26 October 2026, mid-task, and the message is not subtle:
Access to local files on your machine is disabled by your administrator
Before the panic spreads: this does not mean Muse cannot upload files at all. It means the browser cannot pick them. There is a difference — and a workaround we proved the same night. But if your automation was built on "Muse renders the file, then Muse's browser grabs it and uploads it" — and a lot of YouTube and Facebook automation was — that design just broke.
What exactly happens
Our setup was the obvious one. Muse rendered a short video on its own machine (a Remotion clip), opened YouTube Studio in its browser, signed in, clicked Create → Upload videos — and at the moment the file selection dialog should have opened, Chrome showed the message above instead. No dialog, no file, no upload. The click is treated as if you pressed Cancel.
- It is not YouTube or Facebook blocking you. The message comes from the browser itself, before the site ever sees a file. The same wall waits on any site whose upload button opens the system file picker — Business Suite, a Page composer, any attach-a-file form.
- It is not just uploads. The switch covers every file selection dialog — opening files, save-as, importing bookmarks. Uploads are simply where automation feels it first.
- There is nothing to click through. It is not a permission prompt you can approve. The dialog is replaced by the message, every time.
Why it happens: a Chrome policy, switched off on purpose
That sentence is not custom Muse wording. It is Chrome's standard infobar for a long-standing enterprise policy called AllowFileSelectionDialogs ("Allow invocation of file selection dialogs"). Google's own description says that when the policy is disabled, whenever a user performs an action that would provoke a file selection dialog — uploading files is Google's own example — "a message is displayed instead and the user is assumed to have clicked Cancel." Mozilla documented the identical behaviour — same infobar, word for word — when Firefox implemented the same policy.
Why disable file dialogs on purpose? The CIS security benchmark for Chrome recommends exactly this setting for high-security environments: a file dialog is a two-way door. Out through it goes your data — uploads are the classic exfiltration channel. In through it come malicious downloads. Closing the door is a recognised data-loss-prevention move.
Now place that inside Muse. Muse does not run on your computer: every user gets a dedicated secure computer in the cloud — a Secure VM — with its own browser, and researchers at Cequence have noted that Meta hosts and updates those browsers centrally. That managed browser sits on a machine holding your signed-in life: email, social accounts, saved sessions. A web page that could reach through the browser and help itself to files on that machine would be a hole in the whole design. Meta has not published its reasoning for this setting, and we won't invent a quote. But the policy, its rationale and the architecture point the same way: the "administrator" in that message is the platform, and the door is closed deliberately.
Is this new? The honest answer
The mechanism is not new. AllowFileSelectionDialogs has been in Chrome's enterprise policy list since at least 2020, and Firefox matched it in 2024. What is new is personal AI agents shipping with centrally managed browsers at scale — Muse itself only launched on 8 September 2026.
For Muse specifically, we could find no announcement, changelog entry or Meta statement about the file-dialog setting, despite searching product documentation, help pages, community forums and news coverage. Our own dated observation is 26 October 2026. Anyone who gives you a more precise "Meta flipped the switch on X" date is guessing.
What is dated is the climate. The weeks before we hit the wall were a rolling security hardening for Muse: a macOS zero-day disclosed on 21 September and hotfixed within about twelve hours; Amazon blocking Muse from shopping on 20 September; Meta pausing conversation sharing on 20 October after a security firm's report, then restoring it two days later once fixed. Nor is Muse alone: OpenAI's Lockdown Mode (June) disables file downloads to cut off prompt-injection exfiltration, and mid-October brought reports of file access tightening in ChatGPT's agent products too. The direction of travel is consistent: agent platforms are clamping how files move, on purpose. The picker block fits that pattern.
Who this actually affects
- Hit: anyone whose YouTube or Facebook workflow runs through Muse's browser with the media on Muse's machine — Studio uploads, Business Suite and Page composer uploads, "render then post" pipelines. The render half still works; the hand-off is what changed.
- Hit: any browser task that ends in "…and pick the file" — CV uploads, marketplace photos, cloud-drive uploads through web interfaces. Same wall, same message.
- Not hit: posting through APIs and connectors. Those routes never open a file picker, so this restriction does not touch them. They have their own setup hurdles — a separate story.
- Not hit: your own Chrome on your own computer. Browsing, clicking and form-filling inside Muse's browser still work; files still come out of Muse as protected downloads, and you can still upload files into a chat yourself.
What still works: hand the file to the browser
If you just want your uploads back, this is the part that matters. Muse's own browser documentation describes the intended channel: files are passed to a browser task through file grants, and "uploading files" sits in the permission category that can only be set to Ask or Deny — never quietly allowed. The browser is not supposed to fetch files off the disk. It is supposed to be handed them, explicitly, one task at a time.
That is exactly what we did after the picker refused us. Same night, same video, same channel:
- Muse rendered the clip on its machine and verified the file — codec, dimensions, a frame check. (The rendering half of our pipeline is written up in our local render guide.)
- The browser task was re-issued with the MP4 granted to it through the platform.
- The browser attached the granted file directly to YouTube Studio's upload input — no picker involved — set the title, marked it "not made for kids", chose Unlisted, and published.
- Studio reported upload and processing complete, and the video was in the channel's Content list with the right title and visibility.
So the corrected headline is more precise than the scary one: Muse cannot pick files from its own server — but it can still upload files it has been handed. The cost is real: the handover is explicit and per-task, so an unattended pipeline that assumed the browser could help itself to a folder of renders will stall here until rebuilt around handovers — or APIs. Keep the usual discipline, too: test uploads as Unlisted, and approve title, description and visibility before anything goes public.
The bottom line
If you were doing YouTube or Facebook automation with Muse and it "suddenly stopped working", you have not been banned, your account is not broken, and YouTube has not changed anything. The file door in the agent's managed browser is closed — most likely as deliberate security policy, in line with what the whole agent industry has been doing through 2026 — and it is not coming back through any setting you control. Rebuild the workflow so files are handed to the browser explicitly, or move the posting step to an API. Do not waste an afternoon retrying the picker or hunting through Chrome settings.
We cover Meta's Muse models as well as the agent. If the model side interests you, see our write-up of Meta Muse Glimmer, the 30B open agentic model.
Frequently Asked Questions
Can Muse upload files to YouTube at all now?
Yes — but not by picking them. When the file is granted to the browser task through the platform, the browser can attach it to YouTube Studio's upload form and complete the upload. We verified this end to end on the night of 26–27 October 2026 with a rendered test clip, published as Unlisted.
Why does the message say "your administrator"?
Because it is a managed browser. The message is Chrome's standard wording for its AllowFileSelectionDialogs policy being disabled. The "administrator" is whoever manages the browser — for Muse's hosted browser, the platform, not you and not the website.
Can I turn file dialogs back on in settings?
There is no user-facing switch; the restriction is applied to the managed browser itself. Muse's own browser permissions govern whether the agent may upload at all (Ask or Deny) — they do not reopen file dialogs for web pages.
Does this affect Facebook too, or only YouTube?
Both, and everywhere else. The block lives in the browser, not the site, so any upload flow that relies on the system file picker — Facebook's composers and Business Suite included — reaches the same message. We verified it on YouTube Studio; the mechanism is site-independent.
When did this restriction start?
Nobody outside Meta can say precisely. The Chrome policy behind the message has existed since at least 2020, Muse launched on 8 September 2026, and no public announcement or changelog entry covers the setting. We first encountered it on 26 October 2026.
Is the block specific to Chrome — would Firefox lift it?
No. The block is a management policy applied to the browser — Chrome's AllowFileSelectionDialogs setting switched off — not a quirk of Chrome itself. Muse's browser is hosted and supplied by the platform, so it can't be swapped for Firefox in the first place. Firefox also implements an equivalent enterprise policy with the same effect when an administrator sets it; Mozilla matched Chrome's behaviour. Any admin-locked browser behaves the same. Browsers you run yourself, on your own machine, have no such policy applied and pick files normally — the restriction lives in Muse's managed browser, not on your computer.
Is Meta planning to fix or lift this restriction?
There is no public indication of that. We found no announcement, changelog entry or help-page note — checked in October 2026 — framing the block as a bug, a known issue, or something temporary. Muse's own browser documentation instead prescribes the designed alternative: files reach the browser through explicit per-task grants. That is what a platform documents for behaviour it intends to keep. The restriction also fits the product's wider consent-and-containment design. Treat the file-grant route as the standing way to upload; if the policy ever changes, the documentation would be the first place it shows.
Be the first to share a useful question or thought.