Good questions deserve direct answers.

Those tools primarily share an editor, terminal, desktop, or live view. multAIplayer creates a persistent project room around a locally hosted Codex session.

The room brings together team chat, selected project files, diffs, terminals, browser context, Git workflows, Codex activity, approvals, and host handoff. Teammates can propose Codex turns and local actions without receiving unrestricted remote control of the host’s computer. The active host reviews requests and controls what may execute locally.

It is not a replacement for every Live Share, tmux, or screen-sharing workflow. It is specifically designed for a team collaborating with an AI coding agent while keeping one person’s machine and credentials behind an explicit authority boundary.

multAIplayer is for small, trusted teams that want to pair with Codex together.

That may be two developers working through a feature, a small product team reviewing an agent’s work, or collaborators who want one shared conversation around code, tools, and decisions. It assumes that room members are trusted participants, because admitted members can see shared project context and request actions involving the active host’s project, terminal, browser, Git, GitHub, and Codex session.

It is not designed as an anonymous public chat service, a large enterprise collaboration platform, or a way to let untrusted users operate someone else’s computer.

The current product has one active host, small rooms, host-controlled membership, and a relatively simple key lifecycle. Each room uses independently generated epoch keys, and the active host delivers each new key separately to eligible registered devices using authenticated device-specific wrapping.

MLS solves a broader problem involving decentralized membership, proposals, commits, tree synchronization, missed-update recovery, credential validation, and interoperability. Implementing only selected pieces of MLS would not provide MLS security guarantees. Matrix would also introduce a much broader federated messaging, identity, and server-state architecture than this product currently needs.

The smaller design is easier for this project to implement, test, document, and eventually replace. That is a scope decision, not a claim that custom cryptography is inherently better. The protocol has not been independently audited, does not provide MLS guarantees, and remains isolated behind a small crypto package so migration to a maintained group-messaging implementation remains possible. Read the cryptography architecture and threat model.

The relay can see the metadata it needs for authentication, membership, routing, limits, and operations. This includes:

• GitHub user identifiers and basic profile information used for sign-in
• Team and room identifiers and names, membership, roles, host status, and presence
• Device identifiers, registered public keys, and public-key fingerprints
• Project path labels, selected model identifiers, and certain room configuration values
• Invite identifiers, expiration data, and other invite metadata
• Encrypted event types, sender and device identifiers, timestamps, key epochs, and ciphertext sizes
• Encrypted attachment metadata and operational counters

The relay is designed not to receive or store plaintext room messages, attachment contents, project files, file diffs, terminal output, browser contents, Codex credentials, OpenAI credentials, room keys, or plaintext GitHub access tokens. GitHub access tokens remain relay-side and are encrypted before persistent storage when the relay has a strong session secret.

This is an intended and tested architecture boundary, not an independently audited guarantee. The detailed inventory is in the threat model.

An admitted room member can participate in encrypted chat and see the project context intentionally shared with the room. Depending on room state, that can include project structure, bounded file previews, diffs, Git status, Codex activity, terminal snapshots, browser decisions, and workflow events.

A member can propose a Codex turn, exact terminal command, file save, browser open, or Git and GitHub workflow action. These proposals do not provide direct remote-control access. Codex turns, non-host file saves, terminal commands, browser opens, and Git or GitHub mutations require active-host authorization before touching the host machine.

Native controls add filesystem containment, command review, secret-pattern redaction, and stronger confirmation for recognized credential access. Approval is still a meaningful security decision. Warnings and secret detection reduce accidental exposure but cannot identify every dangerous command or secret. See Using the app and the alpha limitations.

Treat a complete invite link as a private bearer secret. It is reasonable to send one through a private direct message or restricted channel whose participants you intend to invite. Do not paste it into public channels, issue trackers, logs, support tickets, or searchable documentation.

The link does not contain the room key. It contains a random, single-use capability and a public binding to the active host’s identity and device key. Someone with the complete link can submit a device-bound join request, but they do not receive the room key until the active host verifies and approves them.

On macOS, selecting the HTTPS link opens an installed signed multAIplayer app. Without the app, it opens a private installation page. That page removes the capability from the address bar immediately, keeps it only in memory, and never stores or submits it. After installation, use the page’s Open in multAIplayer action or select the original invitation again.

If a link leaks, do not approve an unexpected request. Invalidate the invite and generate a new one. A leaked capability does not reveal existing room content by itself, but it creates an unauthorized opportunity to request access.

No. The cryptographic protocol and implementation have not received an independent professional security audit.

The repository includes documented protocol boundaries, canonical encodings, public test vectors, an independent Python vector verifier, property tests, mutation tests, malformed-input tests, key-rotation tests, invite-binding tests, downgrade rejection, and a public threat-model changelog. Those controls improve reviewability and catch regressions. They do not replace an independent audit.

Cryptographers and protocol reviewers can start with the external review packet and report findings through private vulnerability reporting.

The current product is built around the local Codex app-server. Its thread, turn, goal, model, approval, authentication, app, and MCP APIs provide the structured lifecycle that multAIplayer exposes to a room.

This is deeper than sending prompts to a command-line process. The app tracks Codex threads, reconstructs bounded room context, handles bidirectional approvals, presents model and reasoning controls, records safe lifecycle events, and supports host handoff around that specific contract.

We are open to exploring Claude Code, Aider, and other agents. There is no committed integration or timeline. Supporting another agent responsibly would require a defined local protocol for turns, approvals, tools, cancellation, activity, authentication, and context handling, plus compatibility fixtures and security tests.

macOS is the sole supported release target for the public alpha.

The native app relies on platform-sensitive behavior including Tauri and WebView integration, Keychain storage, process containment, terminal handling, browser profiles, Developer ID signing, notarization, and Gatekeeper verification. Supporting a platform means validating those security and lifecycle boundaries, not only producing a binary that launches.

Linux is used as a development and CI compatibility target in parts of the project, but Linux desktop packages are not supported or published. Windows packages are also not configured or published. There is no committed Windows or Linux timeline.

multAIplayer depends on the Codex app-server protocol, which can change as Codex evolves. The project has generated schema fixtures and compatibility tests for versions 0.133.0, 0.143.0, and 0.144.0, with 0.133.0 through 0.144.0 treated as the supported range.

Older versions cannot host when required methods or contract shapes are missing. Newer versions are labelled unverified. Contract-sensitive or security-sensitive features fail closed when the app cannot establish compatibility.

A scheduled job checks the latest Codex CLI and real app-server handshake, but passing does not automatically expand the supported range. Read the Codex hosting guide.

GitHub currently serves two related purposes: room identity and the built-in GitHub workflow.

The relay uses GitHub device-code OAuth to identify users and scope team and room metadata. The same relay-side session supports draft pull request creation and GitHub Actions status without exposing the access token to desktop clients. Using one provider keeps the alpha’s identity, authorization, PR, and Actions surfaces small enough to review and operate.

GitHub-only sign-in is an alpha scope decision. Other identity providers and a GitHub App model are possible future directions, but neither is committed for the initial alpha. A private local or LAN relay can explicitly disable authentication, but that mode is not appropriate for an internet-facing relay.

The active host’s local capabilities stop being available. New Codex turns, terminal commands, file saves, browser opens, and Git mutations cannot execute on that machine. In-flight local work may fail or require the original host to reconnect and retry.

Members who already possess the room key can continue encrypted chat and read locally available history. The relay does not take over the host’s Codex session, project folder, terminal processes, browser state, or credentials.

Explicit host handoff lets a replacement host use their own machine, Codex access, credentials, and project checkout. There is no transparent machine failover, and an abrupt disconnect may not produce a complete handoff package. Normal Git commits, branches, backups, and clean handoffs remain the reliable continuity path.

Yes. The relay is open source and can be self-hosted. An internet-facing deployment should use HTTPS and WSS, exact allowed origins, GitHub authentication, persistent SQLite storage, durable session encryption, rate limits, quotas, backups, health checks, monitoring, and the included production-relay doctor.

Official desktop builds pin hosted relay endpoints and restrict network access through the Tauri application Content Security Policy. They do not permit arbitrary HTTPS or WebSocket destinations. This prevents a compromised setting, injected page, or casual configuration change from redirecting the trusted desktop shell to an unexpected server.

A custom relay therefore requires a self-built desktop whose allowed origins are included at build time. See the self-hosting guide.

Your project folder, Git repository, branches, commits, room keys, and encrypted local history are not owned by the relay. They remain on the relevant devices.

The relay holds routing and membership state, encrypted backlog, encrypted attachment blobs, invites, and sessions. Migration recreates teams, rooms, memberships, sessions, and invites. It does not automatically transfer hosted backlog or attachment blobs, and a destination relay cannot reconstruct device-local keys or history.

• Keep normal project and Git backups and push important branches
• Export important conversations to Markdown and save important attachments
• Keep every device that contains needed room keys and encrypted history
• Test self-hosting before an emergency

Planned hosted-relay shutdowns provide at least 30 days of public notice when safely possible. Read If this project goes unmaintained for the complete exit path.

Probably not yet, unless your team has reviewed the risks and decided the current alpha controls are appropriate for that repository.

The encryption is unaudited. Room membership grants access to meaningful project context. Approved Codex turns and terminal commands can affect the host’s files and accounts. Signed-in browser pages, terminal output, private paths, diffs, copied Markdown, and local tools can expose sensitive information.

Start with a disposable or public test repository with no production secrets. Use a separate branch, keep a clean remote backup, work with trusted people, use dummy credentials, keep browser sessions free of sensitive accounts, and review every approval. Test member removal, key rotation, host handoff, relay restart, and local export before introducing private code. Read the alpha limitations.

Alpha means the core product exists and is tested, but its compatibility, recovery, operations, and multi-device behavior are still being validated under real use.

Likely failure areas include Codex app-server compatibility, interrupted host-local work, incomplete handoffs, relay and OAuth configuration, local room-key and history recovery, native browser and terminal differences, local preview tunnels, long-lived relay scaling, manual update transitions, multi-device state races, and warnings that fail to recognize an unusual secret or dangerous command.

Treat the alpha as security-sensitive development software. Keep recoverable copies of important work, expect occasional manual recovery, and report reproducible problems using dummy data and the project’s bounded diagnostics tools.