How to Manage Claude Code Sessions Across a Team

Published August 6, 2026 · by the AQ team

Managing Claude Code sessions across a team comes down to five practices, because Claude Code itself manages sessions per machine and per user, not per team. As of August 2026 there is no built-in way for one engineer to open, resume, or even see a session running in a teammate's terminal. Teams that run many sessions well do it with conventions and infrastructure: name every session after its task, give every session its own git worktree, run long sessions somewhere that stays awake, decide who can see what, and treat handoff as a branch-plus-context ritual rather than a button. This guide covers each practice, 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. (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 August 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), 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 August 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 (a research preview for Pro, Max, Team, and Enterprise users as of August 2026) persist on Anthropic's infrastructure and can be pulled into a terminal with the teleport command, though only one-way and only within your own account: 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 August 2026: local sessions can be exported as text transcripts with /export, and hosted cloud sessions on Team and Enterprise accounts can be shared with Team visibility, which gives teammates a read-only link showing the latest state (not a live view, and not something they can type into). Remote Control continues your own local session from a phone or another browser, but it is same-account, not sharing. 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 model usage), 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 the full product on a VM you bring (you pay only your cloud provider); the Team plan is $100 per user per month (promotional; standard $200, billed monthly) with 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.