Unreal Multi-User collaboration

Unreal Multi-User (Concert) lets separate editor participants share a session and display presence avatars. It is distinct from several MCP agents sharing one ClaudusBridge backend: those agents already use the same editor process and do not need Concert.

Separate project roots for separate editors

ClaudusBridge 2.0 permits one package-writing backend per physical project root. Do not start a second agent editor on the human editor's same project directory. LaunchAgentEditor refuses that conflict with E_WRITER_OWNED; changing a port does not remove the ownership conflict.

For distinct Concert participants, use separate compatible project copies/checkouts in different roots, with matching content and plugins. Open each editor against its own .uproject, then connect the participants to the same Concert session. Point each CLI/MCP connection at its own project path; native endpoints are discovered automatically.

The automatically launched ClaudusBridgeMcpServer commandlet is a tool backend, not a second interactive viewport with a presence camera. Use a full editor process for workflows that depend on rendered presence or viewport interaction.

Available tools

Discover ClaudusBridgeEditor.ClaudusBridgeMultiUserToolset for current parameters. Its tools use the Concert client created by Unreal's Multi-User plugin.

Tool	Purpose
GetConnectionStatus	Inspect connection, server, session and display name.
ListServers, ListSessions	Start or read asynchronous discovery.
CreateSession, JoinSession, LeaveSession	Initiate session lifecycle changes.
SetLocalIdentity	Set this participant's display name and color.
EnablePresence, ListParticipants	Control local presence and inspect participants.
LaunchAgentEditor	Launch the legacy helper editor only when project writer ownership permits it; it cannot create a second writer on an owned project root.
StopAgentEditor	Stop the helper launched by that tool.

Discovery and connection depend on game-thread ticks. A request being accepted is not proof that joining completed. Poll GetConnectionStatus or the relevant list until the requested state is observable, with a bounded timeout.

Typical setup

1. Prepare compatible project copies in separate directories and open a full editor for each participant.
2. Open the intended map and confirm the Concert server is available.
3. Create a session on one participant and join it from the other.
4. Set a distinct local identity and enable presence on each participant.
5. Verify ListParticipants and the visible result before editing shared content.

Multi-User startup settings include bMultiUserAutoConnectOnStartup, bMultiUserAutoLaunchServer, MultiUserServerName and MultiUserSessionName. Review them in project settings rather than assuming a second server/session should be created.

Saving is a separate step

Concert synchronization, in-memory edits and persistent asset saves are different operations. Session changes can live in a Concert workspace/sandbox. Use the appropriate persistence tools for the session, inspect their results and confirm the saved files in the intended project root. A second participant seeing an edit is not sufficient proof that the source asset was persisted.

For multiple assistants operating on one backend, use agent sessions and package locks instead.