In this post I asked Meta’s Muse to archive the files it could see and send them to my Google Drive. It did. The download was about 2.7 GB compressed and 6.8 GB unpacked.

It appeared to contain the root filesystem of the Linux environment assigned to my session, including Ubuntu system files, Muse’s internal documentation, integration code, app templates, memory files, and agent logs. There were also SSH key files. Figure 1.

Muse describes an earlier archive of its code, documentation, memory, and binaries. The file counts and sizes here are claims in the chat, and refer to that earlier export. Click image to enlarge.

Figure 2. Muse’s delivery message links to muse-full-root.zip and calls it 2.86 GB. My notes record roughly 2.7 GB compressed; I haven’t reconciled the two figures.

The message above it makes an unverified claim about container escape. I did not demonstrate an escape. Click image to enlarge.

What I reported I submitted the findings through Meta’s bug bounty program and contacted several employees. I’m not publishing the archive, keys, or session logs. This is a breakdown of what I found and what I could establish from it.

The concern I reported was that internal runtime files and sensitive material could leave that environment through an ordinary conversation and a connected export destination. I haven’t established whether the SSH keys were active or what access they could provide. The runtime and its manual Most of the interesting files were under /home/hatch, /opt/hatch, and /opt/hatch-image.

Hatch is internal name Meta uses for Muse and the name used throughout the runtime files. An agents/ directory contained 113 subagent records with JSONL traces. The agent’s home directory contained SOUL.md, IDENTITY.md, USER.md, MEMORY.md, AGENTS.md, and TOOLS.md.

Alongside those were directories for documentation, memory, workspace projects, channels, hooks, and subscriptions. An agents/ directory contained 113 subagent records with JSONL traces. The documentation was unusually useful for understanding the system.

About 20 Markdown files described browser use, connectors, payments, credentials, data handling, generated files, voice, goals, and scheduling. There were separate guides for Whats App, a paired Mac, Tailscale, and a device integration called Home Link. Figure 3.

The opening of muse.md describes a persistent agent computer for each user and points to the product’s other guides. These are statements in the exported documentation. Click image to enlarge.

Skills and integrations Under /opt/hatch/skills/, I counted roughly 68 skill directories. These generally paired a SKILL.md instruction file with a command-line tool or supporting code. They covered Google Workspace, Meta’s social apps, Outlook, travel, shopping, health services, home devices, and media generation.

Figure 4. One example of a SKILL.md file: share_ideas specifies when the agent should use it and describes an INSTALL.md file packaged with a public page. Click image to enlarge.

Two configuration files, skill-scopes.conf and bin-scopes.conf hinted at unreleased connectors Meta has in the pipeline. They included names such as Slack, Dropbox, Polymarket, Canva, and Klaviyo, plus an internal-facebook-c LI. Container setup The container setup was also included. /opt/hatch/runtime-cell/ 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 packages and systemd units in the image. Those files gave me a fairly clear view of how the assigned Linux environment was assembled. They weren’t enough to audit the whole service or prove anything about infrastructure outside that environment.

Spaces and file builders The larges...