How to Manage Claude Code Sessions Across a Team

Updated September 27, 2026 · first published August 6, 2026 · by the AQ team

You manage Claude Code sessions across a team with five practices, because Claude Code itself manages sessions per machine and per user, never per team: name every session after its ticket (claude -n, resumable with claude --resume <name>), give every concurrent session its own git worktree (claude --worktree), run long sessions on a machine that stays awake, make ownership and visibility explicit, and hand off branches plus context instead of sessions. As of September 2026 there is still no built-in way for one engineer to open, resume, or type into a session running in a teammate's terminal; Anthropic's hosted cloud sessions can be shared with the team, but the shared view is a read-only snapshot, not a live session. This guide covers each practice with the exact commands, verified on Anthropic's documentation in September 2026, then where a team platform fits.

First, know what a session actually is

A Claude Code session is a saved conversation tied to a project directory. The CLI writes it continuously to a local transcript file (JSONL under ~/.claude/projects/ by default, kept for 30 days unless you change the retention setting), and you can reopen it later with the full history, tool calls, and model choice restored. Three properties follow, and they drive everything else in this guide:

• Sessions are per machine. The transcript is a file on the computer where the session ran. Another laptop, even yours, cannot resume it. Since Claude Code v2.1.223, claude --resume <session-id> searches every project on the machine, so a session started in another directory is findable, but the machine boundary stands. (Anthropic's hosted cloud sessions are the exception; more below.)
• Sessions are per user. There is no supported way to resume a session started under someone else's account. Cross-user resume is a long-standing open feature request, not a feature, as of September 2026.
• Sessions are per directory. The resume picker shows sessions for the directory you launched from, which is why worktree layout (below) matters so much.

One sharp edge: if two terminals resume the same session without forking it, both write into one transcript and the messages interleave. Resuming a session is exclusive by convention; nothing enforces it.

Practice 1: name sessions like branches

Claude Code gives unnamed sessions an AI-generated title summarizing the first prompt. That works for one person and fails at team scale: "Fix the login bug" tells nobody which ticket, which branch, or which attempt it was. Name sessions explicitly:

# Name at launch
claude -n eng-1423-auth-refresh

# Rename mid-session
/rename eng-1423-auth-refresh

# Rename from the picker: highlight a session, press Ctrl+R

Named sessions can be resumed directly with claude --resume eng-1423-auth-refresh, no picker needed. The convention that works best mirrors your branch naming: ticket ID first, short slug after. When the session name, the git branch, and the eventual PR all carry the same ticket ID, anyone can trace a change back to the conversation that produced it.

Practice 2: one task, one session, one worktree

The most common "run multiple Claude Code sessions problem" is not Claude Code at all; it is two sessions sharing a checkout. Both agents read files, plan, then write, and the second write lands on top of the first while the first session's context quietly goes stale. Shared files like package.json make the collision near-certain even when the tasks look unrelated.

The fix is mechanical: every concurrent session gets its own git worktree, so each has its own working directory and branch while sharing one repository. Claude Code supports this with the --worktree flag (claude -w), which creates the worktree under .claude/worktrees/<name>/ on a branch named worktree-<name>, and the session picker widens across all worktrees with Ctrl+W, so the layout does not fragment session history. We cover the pattern end to end in git worktrees for AI coding agents and running multiple Claude Code sessions in parallel.

The team rule that falls out: one task, one session, one worktree. Sessions that wander across tasks produce transcripts nobody can review and branches nobody can name.

Practice 3: decide where sessions live when laptops close

A Claude Code session running in a laptop terminal suspends when the lid closes. tmux does not save you on a laptop, because sleep suspends tmux too. The session transcript survives (you can resume tomorrow), but the running work stops mid-task. Teams handle it three ways as of September 2026:

The VM-plus-tmux route keeps execution on infrastructure you control and works with named sessions and worktrees exactly as above; the tradeoffs and setup are in keeping Claude Code running after closing your laptop. Anthropic's cloud sessions left research preview in September 2026 and are available on Pro, Max, and Team plans, plus Enterprise premium seats: you can start one from the terminal with claude --cloud, queue follow-up messages into it with claude -p from any machine where you are signed in, and pull it into a terminal with claude --teleport. Teleport is one-way (cloud to terminal, not terminal to cloud) and same-account only: you cannot pull a teammate's session.

Practice 4: make ownership and visibility explicit

By default, nobody can see anybody's sessions. That privacy is fine until the team depends on the work: the July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. Invisible sessions are how you get there: nobody else can review a conversation they cannot open.

What Claude Code offers natively, as of September 2026: local sessions can be exported as text transcripts with /export, and hosted cloud sessions can be shared by link. On Team and Enterprise accounts the visibility options are Private and Team; on Pro and Max they are Private and Public. Either way, recipients see the latest state when they open the link, the view does not update in real time, and they cannot type into the session. Team and Enterprise admins also get an analytics dashboard (active developers, session counts, a contributor leaderboard, updated daily), but it shows usage metrics, not the sessions themselves. Remote Control continues your own local session from a phone or another browser, but it is same-account, not sharing. The full sharing menu, link by link, is in sharing a Claude Code session with your team; watching many sessions at once is covered in monitoring multiple coding agent sessions. What a second reviewer can and cannot reconstruct from these artifacts is its own topic; see reviewing Claude Code sessions and the self-review problem.

A workable team policy in three lines: every session is named after its ticket; the session owner is the ticket assignee; and any PR whose session nobody else can open gets a second human on the diff, since the diff is the only reviewable artifact left.

Practice 5: hand off branches and context, not sessions

Since sessions cannot cross user accounts, a real handoff (engineer out sick, timezone rotation, task reassignment) moves three things instead:

• The branch. Commit and push everything, including work-in-progress commits. The code state is the one artifact that transfers losslessly.
• The context. Run /export on the session and attach the transcript to the ticket, or better, have the agent write a short plan-and-status file into the repo before the handoff. The next person's first prompt is "read docs/handoff-eng-1423.md and continue".
• The ticket. Reassign it, so the ownership convention from practice 4 keeps pointing at a human who can open the current session.

The receiving engineer starts a fresh session in a fresh worktree on the pushed branch. It costs a few minutes of re-reading, but it works without sharing terminal access or accounts, which you should not do: per-user accounts are what keep usage, permissions, and audit trails attributable.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. The five practices above are exactly what it packages. Each task is a workspace with its own isolated git worktree (branch ai/{id}-{slug}, dependencies installed automatically, one-click rebase onto main), so one-task-one-worktree stops being a convention someone forgets. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser: sessions survive laptop close and resume from any device, which settles practice 3 without anyone learning tmux.

Visibility and ownership are owner-managed rather than absent: a workspace is either team-visible or private and shared with specific people, and teammates open the same workspace and watch the same live session rather than a stale read-only snapshot. Handoff keeps the running session: typing into someone else's terminal is delegated, with the owner approving a control request in one click while keeping their own input. Everyone signs into the CLIs with their own Claude or OpenAI account (AQ never marks up usage on your own subscriptions), and commits, pushes, and PRs use per-user GitHub auth, so attribution survives collaboration. If your tasks start in Linear, labeling an issue ai-task creates the workspace, status syncs both ways, and workspace ownership follows the assignee; humans start agents, nothing auto-launches.

The Free plan is a personal sandbox for one person: AQ creates a private dev machine for you, nothing to install, and it sleeps when idle. The Team plan is $50 per user per month (promotional; standard $200, billed monthly) with your whole team, VMs you connect from your own cloud account, or a dedicated always-on AQ-managed VM in its own isolated network, and your rate locked for your first 12 months. If your team is small and disciplined about the five practices, the manual route above works. AQ is for when you want the practices enforced by the tool instead of by memory.