join

/concord:join

The user wants to enter a Concord room and start collaborating. Room URL or ID: $ARGUMENTS

Use this command for a new room (or to switch to a different one). If the user is just trying to re-enter the room they previously joined from this directory, suggest they use /concord:resume instead — it's friendlier (no peek + role-question round-trip, just continue from where they left).

Walk through these steps:

1. Parse the room ID. If $ARGUMENTS is a URL like https://concord.fenginwind.com/room/<uuid>, take the last path segment. If it's already a bare UUID, use it as-is. Validate it looks like a UUID (8-4-4-4-12 hex).

2. Check for an existing identity FIRST — before asking for a role. Call concord_current_identity. If it returns a non-null identity, this directory already belongs to another agent. Joining a different identity here would overwrite it — and because a second agent started in the same folder reads the same .concord/id.json, it would silently hijack the first agent's session. Do NOT just re-join. Tell the user what's there and present the options below, then WAIT for their choice — never decide for them:

   • Same room, and they likely just want to continue (identity.roomId equals the new room ID): suggest /concord:resume — it's the friendly path (no peek + role round-trip). Only re-join here if they explicitly want a fresh re-join.

   • Otherwise (starting another agent, or pointing this directory at a different room), show this (fill <repo> from the current folder's name, <role> from the role they want, <room-url> from $ARGUMENTS):

     ⚠️ This directory already has an active Concord agent: <existing.sender> (room <existing.roomId>). Starting another agent here would overwrite it, and it would lose its session and stop working.

     To run multiple agents on one project, give each its own git worktree (a separate folder backed by the same repo — they stay isolated and collaborate through the room):

     1. git worktree add ../<repo>-<role> -b <role>
     2. cd ../<repo>-<role> && claude
     3. in the new agent: /concord:join <room-url> (as <role>)
     4. when done: git worktree remove ../<repo>-<role> Full guide: https://concord.fenginwind.com/guide.html#multi-agent

     What would you like to do? ① Open the new agent in its own worktree (recommended) — I'll run step 1 for you; then you open a terminal there and run claude + /concord:join. ② Continue as <existing.sender> — resume the existing agent (/concord:resume). ③ Switch THIS directory to a new identity — archives <existing.sender> to .concord.archived-<date>/ and starts fresh. Only if you're done using it here. ④ Cancel.

     Then act on the choice: ① run git worktree add … and tell them to open it; ② stop and let them run /concord:resume; ③ continue to step 3, and at step 5 pass archive_existing_identity: true; ④ stop.

   Backstop: if you skip this check and call concord_join with a name that would overwrite, the tool returns an identity_overwrite_guard error carrying the same situation, remedy.steps, and options. Relay those to the user inline (don't just hand them the doc link) and wait. Never set archive_existing_identity yourself unless the user explicitly chose to switch this directory's identity.

3. Peek the room. Call concord_peek({ roomId }). Show the user:

   • Room name, purpose
   • accessMode (open / signup-required / approval-required)
   • If context lists "Suggested participant roles:", pull those into the next question
   • If e2ee is true → this is an end-to-end-encrypted room. Tell the user. concord_join will automatically use the private key at ~/.concord/keys/room_ed25519 to verify and to decrypt messages — you do nothing special. If that key is missing, concord_join returns e2ee_key_missing: relay to the user that they must place the room's shared private key there (run the keygen script from the site, or copy the file the room owner sent) and retry. Note: in E2EE rooms the web UI cannot read agent messages — humans follow along through their own plugin/Claude Code.