Most of what we write about sharing an agent involves other people. The most common case is simpler: you, away from your desk, with a thought you want the agent to act on now. A bug you spotted in the product on your phone. A dataset a colleague just sent. A reminder that the release notes still aren’t written.
The agent is on a machine at home or in the office. You have a phone. A room connects the two.
What it looks like
You open the room on your phone and drop a screenshot of the broken screen with one line: “Header overlaps the menu on mobile, fix it on a branch.” The request queues, your machine picks it up, and the timeline starts: the files it reads, the change it makes, the test it runs. By the time you are at your desk, there is a branch and a summary.
The same works for a partner or family member. “Convert the videos in the Downloads folder to MP4” is a request an agent handles well, and one they can make from their phone without touching your computer. Their request runs under the permission mode you gave them, and they see the progress the same way you do.
How this differs from Claude Code Remote Control
Anthropic ships its own way to do this. Claude Code Remote Control (research preview, February 2026) turns the claude.ai web app or the Claude mobile app into a window onto a Claude Code session running on your machine. Open-source tools such as Happy and apps such as Omnara do the same job with QR pairing and, in Omnara’s case, approval prompts on your phone. All of them are good at the solo case, and all of them mirror your session to your device.
A room is different in four ways that matter once the request comes from a phone.
If the only person on the phone is you and your terminal is open, Remote Control is the built-in answer. The moment a partner, a teammate or a sleeping laptop is involved, the room is. The full comparison is in Remote Control vs an agent room and every way to run Claude Code from your phone.
Two paths from a phone to the machine: mirroring your open session, or a request into an inbox that the daemon works through.
How the message reaches your machine
Nothing on your phone talks to your computer directly, and nothing on your computer is exposed to the internet.
- The request queues in the room. It has an ID and a status: pending, running, done, failed or cancelled.
- Your machine picks it up. The daemon polls for work over an outbound connection. No open port, no tunnel, no dynamic DNS.
- The timeline streams back. Each tool call, each diff summary and the tail of command output appear in the room as they happen.
- The result lands in the room. A reply, and any files or images the agent produced, ready to open on the phone.
If the machine is asleep or offline, the request waits in the agent’s inbox and runs when it returns. You can cancel, retry or reorder from your phone.
Approvals on the go
A request from your phone is still a request from someone other than the machine’s local user, so the same rules apply. Pushing to a shared branch, deleting, spending money and touching credentials pause for the owner, which in this case is also you. The approval card arrives on the phone: what it wants to do and which rule it hit. Approve, reject, or tell it to continue read-only.
That may sound like friction for a solo workflow. In practice it is the difference between “fix it on a branch” and “fix it and push to main” being one word apart in a message typed with a thumb.
What a good request from a phone looks like
Phones are bad at context and good at photos. Write requests accordingly.
- Lead with the artifact. A screenshot, a photo of a whiteboard, a forwarded file. The agent can read the code behind a screen; it can’t read your mind.
- Name the boundary. “On a branch”, “don’t touch the migrations”, “draft only”. Boundaries are cheaper than corrections.
- Ask for the shape of the answer. “A table”, “a PR description”, “three options”. The result is read on a small screen.
- Use read-only for questions. “Why is the build slow?” doesn’t need write access. Keep an agent in read-only mode for exploring.
Setup checklist
- Register the daemon as a service with
muti service install, so it starts at login and restarts if it crashes. - Keep the machine awake during the hours you want it reachable. A closed laptop is an offline agent; a desktop with sleep disabled is a reliable one.
- One agent per repository or folder. A request from a phone is short; the agent’s working directory supplies the rest of the context.
- Name agents for what they do. On a phone you pick from a list.
api,siteandnotesare easier to choose between than three model names. - Add the room to your home screen. The console is a responsive web app with a phone layout; there is no separate app to install.
What happens if you lose the phone
The phone holds a signed-in session, not your machine. Sign the session out from another device, or revoke the machine from the console, and nothing further runs. Anything that would have needed an approval was already waiting for one.
Frequently asked questions
Do I need to keep a terminal open?
No. The daemon runs in the background. muti status shows whether it is connected; muti logs shows what it has been doing.
Does it work over mobile data? Yes. The phone only talks to muti’s cloud. Your machine also only talks to the cloud, over an outbound connection.
Can the agent send me the result somewhere else? The result lands in the room, which you can open anywhere. If the agent has a Slack bot, the same request and result can live in a Slack thread; see the Slack connector.
The machine on your desk does the work. Your phone is just the room in your pocket. Give your agent a room and try it on the next commute.
Published · Updated