My cofounder Hudson and I already had our Macs connected with Tailscale, but our Codex and Claude Code sessions were still isolated. If one of us was 40 turns deep, the other got a summary, a screen share, or a finished commit not the conversation itself.
We built mpai around a narrower bet: do not replace the terminal or the native agent. Let a trusted teammate enter an explicitly shared session, arrive with its real context, and add an attributed turn from their own Mac.
The public alpha works with Claude Code and managed-mode Codex. The host stays in control, and standalone Codex remains view-only by default.
Where should the trust boundary land for teams? Is an owner-controlled shared session meaningfully better than moving everyone into a hosted collaborative IDE, or does it still feel too close to remote access?
mpai
FetchSandbox
the decision to keep host execution authority is the right call, the second you let the guest drive, you've built a pair programming tool, not a session amplifier. curious how attribution surfaces when one person's turn kicks off a 20-step agent chain: does each sub-action stay attributed to the human who prompted it, or does the chain appear as agent output with a single human-turn anchor?
mpai
@rnagulapalle Exactly—the human prompt is the attribution anchor. Today mpai records that turn under the guest's identity in the native transcript and audit; the downstream 20-step chain remains provider/agent output anchored to that turn, not falsely relabeled as 20 human actions. Remote approvals stay denied, so the host still decides execution. Per-tool-call provenance is a useful next layer, but we don't claim it yet.
PRISM by Block Convey
mpai
Yes—if you mean mpai, it is MIT-licensed, so commercial use is allowed. For a client environment today, I’d run it only on a client-owned Mac and tailnet the client controls, have them explicitly invite you and share the exact session, and start with a non-sensitive pilot. The host keeps execution authority; mpai exposes no arbitrary shell and cannot bypass approvals. It is still a macOS public alpha, not an enterprise SLA product yet. If you test it, I’d love your install-to-first-room time and where the flow breaks.
mpai
@arun_prasad06 If you want to run the client-controlled pilot, the exact two-Mac checklist and privacy-safe feedback template are here: https://github.com/godfaddaai/multiplayer-ai/issues/7 lmk
mpai
Launch-day update: v0.4.13 is live. The host still installs once; the teammate now pastes one version-pinned npx line and lands in the exact shared room — no global install, no setup, and no background service. Both founder Macs are upgraded, and the clean Homebrew lifecycle passed on macOS and Linux. The metric that matters next is outside use: first 10 two-person teams, median invite-to-room under 5 minutes, then a later-week return. Test checklist: https://github.com/godfaddaai/multiplayer-ai/issues/7
Love the idea of collaborating inside the same AI coding session instead of constantly sharing context back and forth. Feels like a much more natural way to work as a team. Congrats on the launch!
mpai
Thank you — eliminating the context handoff is exactly the bet. We just shipped v0.4.11 so a host can create a private invite and ready room for one exact session in a single command. If you already have two Macs on Tailscale, would you be open to timing one real room? The five-minute checklist is here: https://github.com/godfaddaai/multiplayer-ai/issues/7
mpai
@devyatkin Thank you, Alex—that handoff pain is exactly what pushed us to build it. The key for us is that nobody has to abandon Codex or Claude Code: a teammate joins the session already in progress, and their turn is named. If you try the alpha with a teammate, I'd genuinely love to know where setup feels rough.
That's pretty cool, but what are the actual use cases? We use Claude Code, and on our team, up to 10 people can work on the same project simultaneously, but each person is responsible for their own part. Or is this mainly designed to work around usage limits?