PlayerTwoSuppose you are halfway through a migration when Claude Code reaches a failure that does not match the docs. A teammate knows this part of the stack. What should you send them: a transcript, a remote-session link, or access to the terminal itself?
Those options solve different problems. A transcript preserves what happened. Remote access lets you continue your own session from another device. A shared terminal lets a second person watch the live work and, when appropriate, type into it. Choosing the category first prevents a disappointing handoff—and avoids giving more access than the task requires.
Start with the job, not the tool
| What you need | Best-fit approach | What the other person can do |
|---|---|---|
| Review the conversation later | Exported transcript | Read a fixed record |
| Continue from your own phone or browser | Claude Code Remote Control | Operate your session through your account |
| Show a teammate what is happening | Screen share or read-only terminal | Watch the current session |
| Let a trusted teammate intervene | Writable shared terminal | See and type in the live terminal |
| Transfer durable engineering work | Branch or pull request, plus useful context | Review and continue from versioned code |
This guide compares documented workflows, not benchmark results. The tools mentioned below were not installed or tested for this guide.
1. Share a transcript when the work can be asynchronous
Claude Code’s /export command opens a menu to copy the current conversation or save it as readable plain text. Passing a filename writes the export directly to that file.
That is usually enough for “show me how you got here” or a later review. It is a snapshot, though. Your teammate cannot interrupt the current turn, enter the next prompt, or see new terminal output as it arrives. A transcript also does not replace the repository state. If the teammate needs to inspect or continue the implementation, include the relevant branch, diff, test result, and a short note about the unresolved decision.
Before sharing any terminal record, read it. Conversations and tool output can contain file contents, command output, internal URLs, or other material that was appropriate inside the session but not for a wider audience.
2. Use Remote Control when the other device is yours
Anthropic’s Remote Control documentation describes a local Claude Code session that you can drive from claude.ai/code or the Claude mobile app. Execution and filesystem access remain on your machine while the conversation stays in sync across connected devices.
That makes Remote Control a good answer to “How do I keep working from my phone?” It is not the same as inviting a colleague. Anthropic’s documentation says automatically connected sessions use your own claude.ai account and grant no one else access. For inviting a colleague, look for an explicit guest-sharing workflow rather than treating your Remote Control link as an invitation.
3. Share the live terminal when a teammate must participate
The live option matters in the migration example. Your teammate needs to see the current error, ask why a decision was made, and perhaps enter one carefully chosen prompt while the existing process and project environment remain in place.
There are several ways to provide that access:
- A video call or screen share is appropriate when the teammate only needs to observe and talk. In a May 2026 Claude Code feature request, one user describes screen sharing as a workaround where one person types.
- VS Code Live Share lets a host expose a terminal as read-only or read/write. Microsoft warns that writable access lets guests run commands with the host’s terminal access.
- tmux supports multiple clients attached to one session. For sharing over SSH, decide who can access the machine and session, how they authenticate, and how you will revoke access.
- Some terminal-sharing tools also support browser guests. For example, manycode documents browser joining, optional approval and read-only modes. Its README also notes limits on approval over a self-hosted relay.
Whichever route you choose, treat writable terminal access as meaningful access to the host environment. Start read-only when observation is enough. Decide who drives before anyone types, and keep the code changes reviewable outside the terminal.
A documented PlayerTwo workflow
PlayerTwo shares a terminal coding-agent session with teammates in their browsers. For this workflow, plan to start the agent through PlayerTwo before the shared work begins.
- Start the agent through PlayerTwo. The documented host command is
npx pltwo claude. The host needs Node.js 24 or later. A new host is asked for a license key. This guide does not document attaching to an already-running Claude Code process. - Keep execution local. Claude Code runs on the host’s machine using the host’s existing agent subscription. PlayerTwo does not supply that subscription.
- Send the invite. The teammate opens the link in a browser, enters a name, and waits for admission. A guest does not need an installation or a host license.
- Admit before sharing access. The host sees who is waiting and chooses whether to let that guest in.
- Watch first, then hand over deliberately. The guest can watch the terminal and request the keyboard. The host grants control. Each terminal has one keyboard owner at a time; typing in that terminal on the host takes control back.
- End sharing and review the changes. Ending sharing invalidates the invite link. Then inspect the diff, run the project’s checks, and record the decision somewhere durable.
The documented limit is up to four simultaneous guests, and a session can contain up to four terminals. Different people can control different terminals, but two people do not type into the same terminal simultaneously.
Five questions to ask before sharing
- Does the teammate need the past or the present? Export the past; share the terminal for the live moment.
- Do they need to type? If not, choose a transcript, screen share, or read-only mode.
- Whose machine and credentials are in scope? A local shared terminal acts with the host’s environment. Admission should be limited to people you trust with that access.
- Must the work survive the host going offline? A local-session workflow depends on the host machine and process remaining available. If persistence without the host matters, evaluate a server-hosted workspace instead.
- What becomes the durable handoff? A productive live session should still end with versioned code, reviewable changes, and a concise record of decisions.