Muse 2.2 ships an assistant mailbox screen behind a flag that defaults to false

A flag that defaults to false in a shipped production build is the ordinary way to put a screen in front of users before the service behind it exists. In Muse 2.2 the Mail route is controlled by a remotely set flag named hatch_web:muse_mail, and the packaged client defaults it to false ^[4]. With the flag off, the route is removed from navigation and returns a not-found state if opened directly ^[5]. A static read of that build tells you the API shape the client expects. Whether a server answers it is untested. RuntimeWire said the installer does not reveal the flag's live value and that it did not test an authenticated account or a live server ^[6][7]. It published the installer's SHA-256 so the artefact can be matched ^[3].

The client expects a mail service of its own. The code defines requests to create and retrieve a mailbox, list messages and download attachments ^[11]. Message handling separates incoming from outgoing mail and carries fields for sender and recipient, delivery status, sender-authentication results and warnings ^[12]. That inventory settles an earlier ambiguity. TestingCatalog reported on September 18th that an unreleased Mail tab had appeared in Muse's web interface, and at the time it could have been a mailbox of its own or a place to display messages from connected personal accounts ^[14]. RuntimeWire said the address-creation flow in the Mac client resolves the question about the intended interface, and that availability remains open ^[15].

The setup screen shows the product choices. It tells the user the assistant does not yet have an email address and asks them to choose a handle, and the address ends in @muse.ai ^[8]. Handles run three to 32 characters and accept lowercase letters, numbers or hyphens; the client already carries a message for a server response saying the requested handle is taken ^[9]. An error path for a taken handle implies one namespace shared across users. With 37 permitted characters, there are 50,653 possible three-character handles ^[22]. That is a shallow supply for a consumer domain. The client also proposes a sender name in the form Muse Personal Assistant (user name) and tells the user that recipients will see that name on mail the assistant sends ^[10].

Inbound is the part the inspection could not reach. The interface offers Received and Sent filters, attachment downloads, and warnings for unverified senders or likely spam ^[13]. Those warnings sit in the interface, on mail the client has already fetched. RuntimeWire said live availability and the controls on incoming mail remain untested ^[25]. Meta's September 8th launch announcement, as RuntimeWire describes it, covered connecting existing email accounts and letting users choose whether Muse can read or send through them ^[16]. Meta said the assistant asks for approval before sensitive actions such as sending an email ^[17]. Approval on the way out is a different problem from an address a stranger can write to. Muse's stated design is an agent that keeps working after the user closes the app and follows up when a task needs attention ^[18].

Anyone who filters mail for a living should note the display name: a machine account at a consumer domain, signing with its owner's name ^[10]. Whether any of it becomes a product depends on one server-side value ^[4][6]. RuntimeWire published ahead of Meta Connect 2026, which it said would begin later the same day, and said its inspection did not establish that Meta plans to announce the feature there ^[19][20]. It did not contact Meta before publication ^[21].