The coding agent on your machine is probably the most capable colleague you have, and the only person who can ask it anything is you. The runtime, the subscription, the repositories and the credentials all live on one computer. So does the permission to use them.
This guide covers the ways people work around that, what each one gives away, and how to set up a room where other people can send work to your agent without ever touching your laptop.
The workarounds, and what they cost
Each of these trades safety for reach. The room approach trades neither: the other person gets the ability to ask, you keep the ability to decide, and the machine stays yours.
Where this sits next to Remote Control
If the person who needs remote access is you, Anthropic’s Claude Code Remote Control is the built-in answer: your phone becomes a window onto your own session. A room solves the other problem: someone else needs to use the agent, and you want to decide what they may run. The two compose; see Remote Control vs an agent room.
Set up a room in five steps
Connect, approve the machine, create an agent, invite, approve the first request. The four dangerous actions keep pausing afterwards.
1. Connect the machine. On the computer where your agents live, run the connect command from the console. The daemon detects the runtimes installed locally, currently Claude Code and Codex, and reports the machine’s local and public addresses so you can tell your computers apart.
2. Approve the machine. Nothing runs until you confirm in the web app that this computer is yours. After that the daemon detaches and keeps running in the background. Registering it as a service with muti service install makes it start at login and restart if it crashes.
3. Create an agent. An agent is one runtime pinned to one working directory, with its own name and permission mode. Make one per job: api for the backend repo, site for the marketing site, ops for the folder with the exports. Narrow directories make approvals rare and mistakes small.
4. Invite a person. Create a room, add the agent, and send an invite link. The other person signs in, lands in the room, and sees the agent online. They install nothing.
5. Approve the first request. When they mention the agent, you see the request. Approve it once, or mark the person as “always allow” for that agent. Either way, the four dangerous action types still pause for you.
What the other person sees
Everything that happens in the room, and nothing else.
- The agent’s reply, streamed as it is written.
- Each tool call as it happens: which command ran, which files changed and by how many lines.
- The tail of command output, so a failing test is visible without opening your terminal.
- Any file or image the agent produced, posted to the room’s outputs.
They never see your files, your environment variables, your keys or your other rooms. The daemon uploads timeline events; it does not upload the working tree.
What happens on a dangerous call
Suppose your co-founder asks the agent to “fix the flaky test and push”. The agent edits the test, runs it, and then reaches for git push to main. That call stops.
You get a card: who asked, which agent, what it wants to do, which rule it hit. You can approve, reject, or tell the agent to continue read-only. You can add a note, and the note carries the same weight as the original request. Approve from the console, from your phone, or later from a chat platform; deciding in one place applies everywhere. Unanswered approvals expire.
Taking it back
Sharing is instant to undo, in any of four ways.
- Remove the member from the room.
- Revoke their “always allow” for the agent.
- Revoke the machine.
- Run
muti stopon the machine.
Anything queued for that person is cancelled. Anything already running finishes and stays in the history, so the audit trail is complete.
Practical advice
- Start read-only. Let someone explore a codebase and ask questions before you let them change it.
- One agent per working directory. A person who only needs the docs repo shouldn’t be mentioning the agent that can see production configuration.
- Name agents for the job, not the model.
deploy-checkstells a teammate what to ask.claude-2doesn’t. - Keep the machine awake. Requests wait in the inbox while it sleeps, but a laptop lid that stays closed all weekend makes for a slow colleague.
Frequently asked questions
Does the other person need Claude Code or Codex installed? No. They need a browser and the invite link. The agent runs on your machine with your subscription.
Can they see my other rooms or projects? No. Rooms share nothing with each other. They see the room they were invited to.
Does the agent remember the conversation? By default each room keeps its own persistent session, so the agent remembers that room’s context. You can switch a room to a fresh session per request.
What if my machine is offline? Messages queue in the agent’s inbox and run when the daemon returns, in order. You can remove or reorder items in the inbox before they run.
The short version: give your agent a room, invite one person, keep the approvals, and stop lending laptops.
Published · Updated