How to Share a Claude Code Session With Your Team

Published July 10, 2026 · by the AQ team

Claude Code has no built-in way to share a live session: its share links produce a read-only view of the conversation, not a session a teammate can join and type into. To actually share a running session today you need either terminal-level tricks (tmux over SSH, screen sharing) or a platform that makes the session itself multiplayer.

This guide covers what the official sharing does and does not do, the workarounds teams use, their limits, and how AQ turns an agent session into something a whole team can open.

What can you share from Claude Code today?

Out of the box, sharing a Claude Code session means sharing an artifact of it, not the session:

• Share links are read-only. A teammate can read the transcript of what happened, but cannot prompt the agent, interrupt it, or see your working tree.
• The session lives in your terminal. The running process, the files it is editing, and the dev server it started are all on your machine, invisible to everyone else.

The demand for more is not niche. A GitHub issue on the Claude Code repository (anthropics/claude-code#60082, open since May 2026) asks for real-time multi-user sessions where several people interact with the same agent, and it remains open and widely requested. Until something like it ships, live sharing is a do-it-yourself problem.

Workaround 1: screen sharing

The default move is a Zoom or Meet screen share. It works for a demo or a quick "is it stuck?" check, and it requires zero setup. Its limits are equally obvious: only one person can drive, it ends when the call ends, nothing persists, and it does not scale past "watch me work." Screen sharing is presence, not collaboration.

Workaround 2: tmux over SSH

The classic terminal answer is to run Claude Code inside tmux on a machine your teammate can SSH into, and have both of you attach to the same session:

# On a shared machine or VM
tmux new -s agent
claude

# Teammate, from anywhere with SSH access
ssh shared-box
tmux attach -t agent

Both of you now see the same terminal, and either of you can type. This genuinely works, and it is the mental model every multiplayer terminal product is built on. But as a team practice it has three hard problems:

• No auth story. Attaching requires SSH access to the box, usually as the same Unix user. You are handing out shell access, not session access: there is no per-person identity, no "share with these two people," and revoking access means managing SSH keys.
• No persistence story. tmux keeps the process alive, but the session is findable only by whoever knows the box and the session name. There is no list of running sessions, no history of what ran last week, nothing linking a session to the task it was for.
• Terminal only. Your teammate sees the agent's text output. They cannot browse the working tree in an editor, and they cannot open the dev server the agent just started (that is another round of SSH port-forwarding). Reviewing actual behavior still means "pull the branch locally."

How does AQ make the session itself multiplayer?

AQ is the multiplayer workspace 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. Instead of sharing a view of your terminal, teammates open the same workspace, and the workspace is the session:

• Same live terminal. The agent runs as the real Claude Code CLI inside tmux on a server (your VM or an AQ-managed one), streamed to every browser that has the workspace open. Anyone with access sees the same output live and can send the agent a prompt or interrupt it. It is the tmux-attach model with a browser, real user accounts, and none of the SSH key management.
• Same editor and files. The workspace is an isolated git worktree, and everyone gets a code editor over it. A reviewer reads the actual diff in place instead of asking you to push half-finished work.
• Same preview. The workspace's dev server has a shareable URL. Teammates click the feature the agent just built rather than imagining it from terminal logs.
• Persistence for free. Because sessions run server-side, they survive your laptop closing, and the workspace list is the directory of what is running: no hunting for the right box and session name.

Access is explicit rather than inherited from SSH: a workspace is either open to the whole team or private and shared with specific people, and sharing is managed by the workspace owner. That is the auth story tmux never had.

Sharing beyond the team: guest preview links and preview comments

Not everyone who needs to see the agent's work should be in the terminal. For designers, PMs, and stakeholders, AQ generates guest preview links: a URL to the running app that works for people outside the team, without giving them the workspace.

Feedback flows back in the same channel. Reviewers pin comments directly on the preview (screenshots and attachments included), and those comments can be sent to the agent as prompts. "The dropdown clips on mobile" goes from a stakeholder's click to the agent's next instruction without being retyped through Slack.

Which approach should you use?

For a one-off look at a finished run, a share link is fine. For pairing on a live session inside a trusted two-person setup, tmux over SSH works if you accept the key management and terminal-only view. For a team that shares agent sessions routinely (handoffs, reviews, unblocking a stuck run, showing stakeholders), the session needs to be a place people can open, and that is the model AQ is built around.