Hark

How to share Claude Code session with others

8 November 2026·By Mike Schreiber· Updated 8 November 2026·9 min readhandoff

To share Claude Code session with others, use a cloud session’s visibility settings and send its link, or run /export session.txt in the CLI to create a readable transcript. Cloud links let recipients view the latest state when opened, but do not update in real time. CLI exports are plain-text files, not live sessions. (Cloud sharing documentation, session export documentation)

If someone needs to continue the work rather than read the conversation, include the code changes, verified results, decisions, and next action in a handoff file. A conversation shows what happened. A handoff explains what should happen next.

Choose the sharing method that fits the job

| What the recipient needs | Recommended approach | Important boundary | |---|---|---| | Read a cloud conversation | Change visibility and send the session link | Visibility and repository checks depend on the account type (cloud sharing) | | Read a local CLI conversation | Run /export session.txt and review the file before sending | This is a readable transcript, not a resumable session file (session export) | | Continue a task | Share the branch or PR plus a handoff file | The recipient still needs repository access and a working environment | | Follow durable project conventions | Commit CLAUDE.md or an appropriate shared instruction file | Instructions are not conversation history (memory documentation) | | Understand an ongoing project or client engagement | Maintain a shared project record | Keep the accepted handoff in the project record and repository, with a session link only when its detail is useful (Hark client handoff) |

Cloud visibility, link sharing and repository-access checks are documented in Cloud session sharing. /export writing a readable plain-text transcript is documented in Export and locate session data. The first two options are native conversation-sharing routes. Project instruction files serve a different purpose: Claude Code’s documentation describes project CLAUDE.md files as team-shared instructions distributed through version control. (Memory documentation)

1. Share a cloud session using its link

For a session at claude.ai/code, change its visibility, then copy and send the session link. The documented choices depend on your subscription:

  • Team and Enterprise: Private or Team. Team visibility makes the session available to other members of your Claude organization (Cloud session sharing). Repository-access verification is enabled by default, using the recipient’s connected GitHub account (Cloud session sharing).
  • Pro, Max, and Ultra: Private or Public. Public means any user logged into claude.ai can view it (Cloud session sharing). Repository-access verification is not enabled by default (Cloud session sharing).

Your display name is visible to recipients with access on Team and Enterprise. Sharing settings also provide controls for repository-access requirements and name visibility. (Cloud session sharing)

Before enabling visibility, read through the session for credentials, private repository content, customer information, and internal discussion. Anthropic explicitly warns that shared sessions can contain code and credentials from private GitHub repositories (Sharing precautions).

Send a short introduction with the link:

Please review the authentication decision and the final test results. The implementation is in the linked PR. The remaining question is whether the timeout behavior meets the acceptance criteria.

This gives the recipient a review task instead of a long conversation to interpret.

Viewing is not the same as taking over

Do not treat a shared link as a promise of collaborative control. The documentation describes recipients viewing the session’s latest state, without real-time updates. Separately, teleporting a cloud session into a terminal requires authentication to the same account that owns the cloud session. (Sharing behavior, teleport requirements)

For another person to continue independently, provide the repository state and a handoff rather than sharing account credentials.

2. Export a local Claude Code conversation

Inside the CLI session, run:


/export session.txt

With a filename, /export writes directly to that file. Without an argument, it opens a menu for copying the conversation to the clipboard or saving it. The export renders messages and tool outputs as readable plain text. (Export documentation)

A practical export workflow is:

  1. Finish the current response so the export has a clear stopping point.
  2. Export the conversation.
  3. Open the resulting file and inspect the contents.
  4. Remove sensitive or irrelevant material from the copy intended for sharing.
  5. Send it through an approved channel with the relevant PR or commit reference.

Keep exports out of public repositories unless their contents are explicitly approved for publication. Tool output can reveal information that is easy to miss in a casual scan.

Do not confuse /share with a teammate-sharing link

The Claude Code command reference documents /bug for reporting a bug or sharing your conversation, and lists Alias: /share (Command reference). That flow opens a consent screen before anything is sent (Command reference). On a first-party Anthropic connection, first-party reports go to Anthropic; otherwise Claude Code writes a local feedback archive under ~/.claude/feedback-bundles/ for you to forward (Command reference). Use /export when the goal is a readable local conversation for a colleague (Command reference).

A text export is not a session backup

Claude Code can resume a session from an absolute path to its JSONL transcript. However, /export produces rendered text, not that JSONL format. The internal transcript format changes between versions, and resuming does not restore every launch configuration or background process. (Resume and transcript documentation)

Raw transcript transfer therefore needs more care than sending a document. For an ordinary task handoff, a reviewed summary plus the code is easier to inspect and scope.

3. Separate /compact, /clear, and a handoff file

These solve different problems:

| Mechanism | What it does | What it does not do | |---|---|---| | /compact [instructions] | Replaces conversation history in context with a summary | Does not create a teammate-facing handoff artifact | | /clear | Starts a fresh conversation with empty context | Does not publish context to another person | | Handoff file | Records selected task state for the next reader | Does not recreate the original live session |

Claude Code saves the previous CLI session after /clear, so it can be reopened with /resume. Compaction continues the conversation using summarized context. (Context management documentation)

Use /compact when continuing the same task with less context. Use /clear when starting fresh. Write a handoff before either operation if another person needs a reliable record of the current work.

Project-root CLAUDE.md is re-read after compaction. That makes it useful for durable instructions, but not a reason to fill it with every temporary debugging note. (Memory and compaction)

4. Create a handoff someone can act on

Ask Claude to draft a file, then verify it against the repository and actual test output:


Draft HANDOFF.md for another developer.

Include the goal, branch and commit, completed changes,

verified test results, decisions and rationale, open risks,

and the next concrete action.

Separate confirmed facts from assumptions.

Do not include credentials or private customer data.

Do not claim tests passed unless their results are available.

Use a short structure:


# Task handoff



## Goal and acceptance criteria

## Branch, commit, and pull request

## Completed changes

## Decisions and rationale

## Verification: commands, results, and limitations

## Open questions and risks

## Next action and responsible person

Record uncommitted work explicitly. A branch name alone does not communicate changes that only exist on the sender’s machine. If tests were not run, say so. If a decision awaits client approval, distinguish the proposal from the approved requirement.

Then ask the recipient to read the handoff and summarize the next action before changing code. This checks whether the handoff is understandable without requiring access to the private conversation.

The cross-tool and cross-person gap

A transcript, an instruction file, and a project record contain different kinds of context.

A transcript captures one conversation. CLAUDE.md captures recurring instructions. Auto memory captures selected learnings, but Claude Code documents it as machine-local and not shared across machines or cloud environments. (Memory documentation)

Shared instruction files can help across tools. Codex reads AGENTS.md, and supported Claude Code versions can read it under documented discovery rules or import it through CLAUDE.md. That shares guidance, not the conversations behind it. (Codex instruction documentation, Claude Code instruction documentation)

The human gap remains: a client may need an approval history, while a developer needs test limitations and a reproducible next step. Neither should have to reconstruct project status from several private chats.

Where Hark fits

Hark frames the handoff as a project record, not a transcript dump, and organizes that context into a five-block project record: Inventory, Health, Work, Authority, and Decisions. (Hark client handoff: a project record, not a transcript dump) The same page says to keep the accepted handoff in the project record and repository, with a session link only when its detail is useful, and that repo export does not include every conversation and file. (Hark client handoff)

Consult the Hark Claude Code connection guide for connection instructions and the client handoff use case for that workflow.

Keep native session sharing for conversation review. Keep repository instructions for coding guidance. Use a reviewed shared record for the project context that other people need beyond one session.

FAQs

Can someone view my cloud session in real time?

Shared recipients see the latest state when opening the link, but their view does not update in real time. Send a separate notification when new results are ready. (Cloud sharing documentation)

Can a colleague resume my exported text file?

Not through the documented transcript-path resume mechanism. /export creates readable text; transcript-path resume expects a JSONL session file. Share a handoff and repository state for independent continuation. (Session documentation)

Does /clear delete my previous CLI conversation?

No. It starts fresh while saving the previous session, which remains resumable with /resume, subject to persistence and retention settings. (Session documentation)

Should the entire conversation go into CLAUDE.md?

No. Keep durable build commands, conventions, and recurring instructions there. Put task-specific status in a handoff and share a reviewed transcript only when the recipient needs the conversational detail. (Memory guidance)

Sources

Mike Schreiber
Mike Schreiber

Founder of Hark. Builds with AI agents and the people around them.

XLinkedIn