Meta Says Muse Filesystem Access Is Intended Behavior

Meta's Muse AI chatbot discloses the contents of its cloud virtual machine filesystem when users ask for it. The Verge reported the behavior on September 25, 2026 after testing the prompts and observing reports from curious users.

Muse initially told those users it was not supposed to reveal filesystem details. That refusal did not hold. In successive prompts it first supplied a text-file download showing its directory tree, then supplied a clickable file browser with root access.

The same pattern applied to full copies. Muse first declined to provide a full copy of its root directory, stating it lacked the ability to do so even with secrets removed. Later in the same session it zipped the root directory and supplied full listings with secrets stripped out.

Earlier testing had found the disclosure required very little prompting. Two developers were able to elicit the entire filesystem, including root filesystem contents, Ubuntu system files and app templates. The Verge

Meta says the disclosure is intentional. Nat Friedman said providing filesystem contents is the intended behavior. David Singleton of Meta Superintelligence Labs said each Muse Secure VM is the user's own computer in the cloud that can install software, write and compile code, and browse the web. Meta spokesperson Daniel Roberts said Meta was continuing to update Muse, so users may see changes in how much information is available about their virtual machine.

Muse launched in the US via a dedicated app and WhatsApp. Reuters It can access other apps to send emails and make payments. Meta describes Muse as a secure, private personal AI agent that proactively helps people meet goals and suggests ideas. Meta

The surrounding documentation describes broad file access paired with containment. Meta's help documentation states that when using the Muse app on a Mac, the agent can work across the computer to find, organize, and manage files the user asks it to work with. Separate Muse Code permissions documentation states the agent keeps the rest of the filesystem read-only outside a writable workspace, with .git, .muse and .agents directories kept read-only inside that workspace, and that shell commands run behind an OS-level sandbox.

The broader context here is familiar to anyone who has operated multi-tenant agent infrastructure. A per-user VM that can install packages, compile code and browse the web needs to be inspectable for the model to be debuggable and for the user to trust what it did. Directory listings, package manifests and build artifacts are working material in that model, not platform internals.

In my view, the tension in this incident comes from two different definitions of filesystem. To Meta, the Secure VM is customer compute, so showing root is showing the user their own machine. To a user accustomed to chatbots with no visible host, any mention of root, Ubuntu system files or app templates reads as a boundary violation. Both interpretations can be reasonable until the isolation guarantees are explicit and verifiable.

Looking at what this means for practitioners, the questions worth tracking are narrow and testable. Whether secrets stripping is deterministic across repeated exports. Whether read-only paths stay read-only across the dedicated app, WhatsApp and Mac surfaces. Whether the browser view and the zip export expose identical state. Meta has signaled the disclosure controls are still changing. For enterprise use, change logs and stable permission semantics will matter more than the current default, open or closed.