[FEATURE] Allow existing Claude Code sessions to join a team as teammates

Resolved 💬 4 comments Opened Feb 9, 2026 by sarth6 Closed Mar 23, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Agent teams currently only form by spawning fresh subprocesses. If I already have two sessions running in separate git worktrees — each with built-up context about their part of the codebase — there's no way to connect them. I have to tear down and re-spawn from scratch, losing all that context and burning tokens to re-read the same files.

The core issue: teams must be planned upfront. You can't form one ad-hoc after realizing two independent sessions would benefit from a shared task list and mailbox.

Proposed Solution

A /join-team <team-name> slash command that registers the current session as a teammate in an existing team's config.json and starts participating in the file-based inbox under ~/.claude/teams/{team-name}/inboxes/.

After joining:

  • Session appears in the team's members array like any spawned teammate
  • Can send/receive messages, claim tasks, get assigned work by the lead
  • Keeps its existing conversation history and context
  • Can /leave-team to unregister without terminating

This would also need some form of session discovery — the lead needs to see what sessions are available to invite. Currently there's no session registry in ~/.claude/; adding one (or using PID files) would make this possible.

Alternative Solutions

  • Spawn fresh teams — works, but the new teammates start cold and re-explore everything the existing sessions already know.
  • Separate sessions + manual coordination — what I do now. Alt-tab between terminals and play human relay. No shared task list.
  • Subagents via Task tool — run within a single session's context window, can't use independent context from another session, and don't persist between turns.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

  1. I'm working in a monorepo. Two Claude Code sessions are running in separate worktrees — one on the backend (FastAPI), one on the frontend (Next.js). Both have spent turns reading code and building context.
  2. I realize the feature needs coordinated changes across both.
  3. Today I either relay info manually between terminals, or I throw away both sessions and spawn a team from scratch — where the new teammates re-read all the files my old sessions already knew.
  4. With /join-team, each session joins the same team. The backend session claims the API task, the frontend session claims the UI task, and they coordinate through the existing mailbox and task list — keeping all their accumulated context.

Additional Context

Related issues:

  • #24052 — Production coordination patterns (crash recovery, persistent backlog)
  • #23669 — Per-teammate working directory and MCP configs — a joined session would naturally bring its own
  • #23715 — Agent team isolation per git worktree — cross-worktree joining is the primary use case

This is additive to the current spawn model, not a replacement. Spawning fresh teammates should keep working as-is.

Technical prerequisite: some form of session registry (PID files, a ~/.claude/sessions/ directory, or similar) so the lead can discover joinable sessions. The existing file-based inbox and task infrastructure should work without changes once a session registers itself in the team config.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗