Meta Muse Agent 导出运行时文件，含内部文档与 SSH 密钥

The export

I asked 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.

/

• ▸ home/hatch/
• · SOUL.md
• · IDENTITY.md
• · USER.md
• · MEMORY.md
• · AGENTS.md
• · TOOLS.md
• ▸ agents/
• ▸ docs/
• · devices/home_link.md
• ▸ memory/
• ▸ bank/
• ▸ dreams/
• ▸ workspace/self_improvement/
• ▸ opt/hatch/
• ▸ skills/
• ▸ runtime-cell/
• ▸ opt/hatch-image/
• · bin/codex
• · bin/codex-resources/bwrap

/home/hatch

The agent’s home directory contained SOUL.md, IDENTITY.md, USER.md, MEMORY.md, AGENTS.md, and TOOLS.md.

Read section →

/home/hatch/SOUL.md

The agent’s home directory contained SOUL.md, IDENTITY.md, USER.md, MEMORY.md, AGENTS.md, and TOOLS.md.

Read section →

/home/hatch/IDENTITY.md

The agent’s home directory contained SOUL.md, IDENTITY.md, USER.md, MEMORY.md, AGENTS.md, and TOOLS.md.

Read section →

/home/hatch/USER.md

The agent’s home directory contained SOUL.md, IDENTITY.md, USER.md, MEMORY.md, AGENTS.md, and TOOLS.md.

Read section →

~/MEMORY.md

~/MEMORY.md is a short sheet of facts, preferences, and commitments.

Read section →

/home/hatch/AGENTS.md

The agent’s home directory contained SOUL.md, IDENTITY.md, USER.md, MEMORY.md, AGENTS.md, and TOOLS.md.

Read section →

/home/hatch/TOOLS.md

The agent’s home directory contained SOUL.md, IDENTITY.md, USER.md, MEMORY.md, AGENTS.md, and TOOLS.md.

Read section →

agents/

An agents/ directory contained 113 subagent records with JSONL traces.

Read section →

docs/

About 20 Markdown files described browser use, connectors, payments, credentials, data handling, generated files, voice, goals, and scheduling.

Read section → Figure 3

docs/devices/home_link.md

docs/devices/home_link.md described an experimental integration called Meta Home Link, using an ESP32-C5 with Wi-Fi and Bluetooth LE.

Read section → Figure 8

~/memory/

Dated files under ~/memory/ keep the day-to-day detail. The agent can write to these during a conversation.

Read section →

memory/bank/

Files under memory/bank/ organize that material into circumstances, experiences, and preferences, with citations back to the source lines.

Read section →

~/dreams/

A nightly “dream” reviews recent conversations and writes guidance for future sessions.

Read section → Figure 7

workspace/self_improvement/

These runs leave receipts under workspace/self_improvement/, while their actual changes go into the relevant memory and workspace files.

Read section →

/opt/hatch

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.

Read section →

/opt/hatch/skills/

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.

Read section → Figure 4

/opt/hatch/runtime-cell/

/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.

Read section →

/opt/hatch-image

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.

Read section →

/opt/hatch-image/bin/codex

Codex CLI was installed at /opt/hatch-image/bin/codex, reporting version 0.149.0. I found no evidence that Muse uses it as a coding agent.

Read section →

/opt/hatch-image/bin/codex-resources/bwrap

The binary lives under codex-resources/bwrap and identifies itself as bubblewrap built for Codex.

Read section →

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 WhatsApp, 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-cLI.

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 largest code project I found was the Spaces framework, which Muse uses to build and serve apps. Its TypeScript starter included a React client, server actions, a Drizzle SQLite schema, SQL migrations, and Bun configuration. There was a smaller static template and runtime code in directories named worker, sdk, cloudflare, and cvm.

Figure 5. The Spaces directory contains templates and a TypeScript runtime, including worker, sdk, cloudflare, and cvm folders. The directory listing shows structure, not the full implementation. Click image to enlarge.