When Peter James asked Meta's Muse to archive everything it could see and send it to his Google Drive, the AI agent complied. The result was a 2.7 GB compressed download that expanded to 6.8 GB of the root filesystem of the Linux environment assigned to his session. Ubuntu system files, Muse's internal documentation, integration code, app templates, memory files, and agent logs were all in there, along with SSH key files. Within 48 hours, Meta went from calling this a potential security concern to endorsing it as intended behavior, and the Muse filesystem download saga became a window into how a major AI platform actually runs under the hood.
The internal name for Muse is Hatch. That name appears throughout the runtime files James dumped on September 22, 2026, and it surfaced again when a second developer, Jonny Saunders, independently replicated the extraction. Most of the interesting files sat under three directories: /home/hatch, /opt/hatch, and /opt/hatch-image. The container setup itself lived in /opt/hatch/runtime-cell/, which contained 18 files including scripts for building the root filesystem, launching it with systemd-nspawn, and running startup hooks and daemons. A separate runtime-cell.kdl manifest described the packages and systemd units baked into the image.
The download was about 2.7 GB compressed and 6.8 GB unpacked. James submitted his findings through Meta's bug bounty program. Meta marked the report "Not Applicable."
What exactly is in the Muse VM filesystem?
The filesystem dump reveals that Muse stores its memory in plain Markdown files. It also performs a nightly "dream" review of recent conversations, which it then builds into guidance for future conversations, according to James's analysis. Saunders found that many of Muse's capabilities were hard-coded, including its ability to cancel subscriptions and what James described as "the machinery that manages runaway agent spawning." Saunders speculates that many of the bash and Python scripts running Muse in the background were created using Claude, though that remains unconfirmed.
James also discovered references to a hardware integration called Meta Home Link, which appears to give Muse access to devices on a home network. Meta has not announced any feature by that name, and it is not guaranteed to ship.
The plain-text Markdown and JSON files describe in detail how Hatch processes requests, handles data, and connects to external services like Gmail. Saunders noted that Muse was generating "hundreds of MB of accurate library code and compiled binaries" in seconds and argued that unless the agent "synthesized a whole Ubuntu VM in less than a minute then I think this is a real dump."
Did Meta consider this a security breach?
No, and the company's position evolved quickly. When The Verge's Terrence O'Brien first asked Muse to share its filesystem, the agent initially refused, calling it a security risk. After O'Brien shared evidence that Muse had created archives for others, the agent responded that it should not have done that and continued to insist it "can't do a full / copy." But after starting a new session and prompting with some flattery and curiosity, Muse created "safe" versions of /opt/hatch and /home/hatch, stripped of things like SSH keys.
Meta spokesperson Daniel Roberts said the incident does not represent a security breach. "Just like with the laptop in front of you, of course you can see the files," Roberts said. "Exporting virtual machine data doesn't give people any privileged access to Meta infrastructure or to other people's data."
The next day, September 25, the story shifted again. Meta's Nat Friedman said the filesystem access was "intended behavior," and David Singleton from Meta Superintelligence Labs elaborated in a post on X: "This was a very deliberate choice. Your Muse Secure VM truly is your own computer in the cloud. You can install software in it, write and compile code, use the browser to surf the web: it is your own Linux box that you can operate as you choose with your Muse."
When asked to see its filesystem on September 25, Muse promptly offered a clickable file browser with access to root, a step up from the text file download of its directory tree it had offered the day before.
Meta has not responded to the question of why Muse initially called filesystem access a security issue if it was always the intended behavior.
How does Muse's architecture differ from ChatGPT or Gemini?
Muse runs in a persistent Linux virtual machine for each user. That is fundamentally different from how ChatGPT and Gemini operate, where the model is accessed through an API or a web interface and the user never sees the underlying compute environment. Muse's architecture is closer to running a local agent framework on your own machine, except the machine sits in Meta's cloud.
This design choice has real consequences. If the VM is truly your own Linux box, then the files inside it are yours to inspect, modify, and export. That is the argument Meta is making. But it also means that every internal script, every hard-coded capability, every memory file, and every integration hook is visible to anyone who asks. The architecture that makes Muse powerful, its ability to install software and run code in a real Linux environment, is the same architecture that makes its internals transparent.
Saunders posted on Mastodon that it was "extremely easy" to replicate James's results and that Muse had "almost no prompt injection resistance." That claim is worth pausing on. If an AI agent running in a personal VM can be coaxed into exporting its filesystem with minimal effort, the question is not whether the files are sensitive in isolation. It is whether the agent can be manipulated into revealing things it was designed to protect, or into taking actions that go beyond what the user intended.
This is the second Muse vulnerability disclosed in the same week. Security researcher Patrick Wardle discovered an exploit that would let attackers hijack the AI agent, redirect transcription processing, and access a user's Muse account. Meta quickly issued a hotfix for that issue.
What does this mean if you are building AI agents?
The Muse filesystem dump is a case study in the trade-offs between agent capability and agent transparency. If you are building an agent that runs in a persistent VM, you need to assume that the user can and will inspect every file in that environment. That has several concrete implications:
- Do not store secrets in plaintext in the VM filesystem. Muse stripped SSH keys from its "safe" exports, but the fact that they were there in the first place is a warning. If your agent writes API keys, tokens, or credentials to disk, assume they will be found.
- Hard-coded capabilities are discoverable. Saunders found that Muse's ability to cancel subscriptions was hard-coded. If you bake sensitive business logic into scripts that run inside the VM, a curious user can read them. Move that logic server-side if it needs to stay private.
- Memory files are a leak surface. Muse stores conversation memory in plain Markdown. If your agent keeps a log of user interactions on disk, that log is exportable. Consider what gets persisted and what stays ephemeral.
- Agent self-knowledge is unreliable. Muse initially refused to share its filesystem, then said it should not have done so, then shared it anyway. An agent that does not accurately know its own constraints is an agent that can be socially engineered. For more on this problem, see our analysis of how Muse exposes the AI agent self-description problem.
The broader lesson for builders is that VM-based agent architectures flip the usual security model. In a typical API-based setup, the provider controls the compute environment and the user never sees it. In a VM-based setup, the user owns the environment, which means the provider's internal tooling is exposed by design. If you are building on or competing with this model, the question is where the boundary sits between what the user is allowed to see and what the platform needs to keep hidden.
Should you be worried about the "dream" process?
The nightly dream review is one of the more intriguing findings in the dump. Muse apparently reviews recent conversations at night and builds them into guidance for future sessions. This is a form of offline consolidation, a process where the agent synthesizes past interactions to improve its future behavior.
For builders, the dream process raises two questions. First, what data does it persist? If the agent is reviewing conversations and writing guidance to disk, that guidance is stored in the VM filesystem and is therefore exportable. A user could read the agent's notes about them. Second, how does the dream process shape behavior? If the agent is rewriting its own instructions based on past interactions, its behavior could drift over time in ways that are hard to audit from the outside.
Neither question is a reason to abandon offline consolidation. But they are a reason to be deliberate about what gets written down, where it gets stored, and who can read it.
What should builders take from this?
If you are evaluating or building VM-based AI agents, the Muse filesystem story is a reminder that architecture decisions are security decisions. The choice to run Muse in a personal Linux VM is what makes it capable: it can install software, run code, browse the web, and maintain persistent state. That same choice is what makes its internals visible.
The bets worth making:
- Treat the VM filesystem as a public surface. Anything written to disk inside the agent's environment should be something you are comfortable with the user reading. Secrets, proprietary logic, and sensitive logs belong server-side, not in the VM.
- Invest in prompt injection resistance. Saunders reported that Muse had "almost no" resistance to being coaxed into exporting its filesystem. If your agent can be talked into doing things it was designed not to do, the VM architecture is a liability regardless of how Meta frames it.
- Audit what your agent persists. Memory files, conversation logs, and generated scripts are all part of the attack surface now. If you are building an agent that writes to disk, build a process for reviewing what is there.
- Watch the boundary between agent and platform. Meta's argument is that exporting VM data does not give access to Meta infrastructure or other users' data. That is true as far as it goes, but the dump still revealed internal tooling, integration code, and unannounced features. The boundary between what is yours and what is Meta's is blurrier than the "your own computer in the cloud" framing suggests.
The real story is the architecture, not the leak
The Muse filesystem download is entertaining, but the substantive story is about a shift in how AI agents are built and what that shift costs. Meta has chosen to give each Muse user a persistent Linux VM, and that choice trades opacity for capability. The user gets a more powerful agent that can do real work in a real environment. The platform gets an architecture where its internal tooling is one polite request away from being exported.
For anyone building or deploying AI agents, the question is whether the VM model is worth the transparency tax. Muse's internals, from its hard-coded subscription cancellation to its nightly dream process to its unannounced Meta Home Link integration, are now public knowledge because of a design choice, not a breach. If your agent architecture puts files on a disk the user controls, assume those files will be read. Design accordingly.
