[Feature]: Share thread

[OdeToOpenSource]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

I have a thread I went back and forth with for an idea, and want to either share it with one person or publicly for anyone to see.

Proposed solution

Similar to how ChatGPT and Grok has a 'share' option. The publicly sharing would need somewhere to host, although the share between two parties can work similar to https://github.com/schollz/croc.

Why this matters

For example: For this feature request, I went back and forth in a thread on different approaches. If this was available I could share publicly and attach to the ticket so you do not need to start with a vague idea.

Smallest useful scope

Implement croc like functionality for sharing a thread between two computers.

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.

[sittiponghaus]

Additional case from #17196

I'd like to add another use case to this request: sharing a single live thread with collaborators, in addition to the proposed read-only conversation sharing.

Use case: Sharing development sessions with non-technical stakeholders

We're currently running T3 Code as a PoC on a shared VM within a WireGuard network.

Our development environment consists of polyglot microservices (Go, TypeScript, Python) and roughly eight infrastructure dependencies, making it impractical for non-technical stakeholders to run the environment locally.

Occasionally, we want business users to review development progress, provide feedback, or interact with an AI agent within an existing thread.

Currently, we share the internal T3 Code URL along with the server's global passcode. While functional, this introduces several limitations:

• No thread isolation: Collaborators can see and interact with unrelated active threads.
• Overly broad access: The global passcode grants access to the entire instance rather than a specific conversation.
• Persistent credentials: Browser-stored passcodes remain valid beyond the intended collaboration period.
• Operational friction: In our current setup, retrieving the passcode requires restarting the web daemon.
• No granular revocation: We cannot revoke access for an individual collaborator without affecting others.

Suggested enhancement

Building on the original proposal, I think there could be value in supporting two levels of thread sharing:

1. Snapshot sharing: Export or transfer a read-only copy of a conversation, as originally suggested. A P2P approach like croc could work without requiring centralized hosting.
2. Live thread sharing: Generate a scoped link that allows another person to access an existing thread without exposing the rest of the T3 Code instance.

For live sharing, the ideal behavior would be:

• Thread-scoped links: Generate a unique link granting access exclusively to the selected thread.
• Granular permissions: Read-only by default, with optional permission to send prompts and interact with the agent.
• Strict isolation: Collaborators cannot discover other threads, access unrelated workspaces, or modify global settings.
• Revocable access: The thread owner can immediately revoke a shared link without restarting the server.
• Optional expiration: Links can expire automatically after a configurable period.
• No global passcode required: Collaborators authenticate through the scoped link rather than the server's administrative credentials.

Access restrictions should be enforced server-side, including API and WebSocket requests, rather than simply hiding unrelated threads in the UI.

Why this could be useful

The original snapshot-sharing proposal already solves an important problem: making it easier to share the context behind an idea or implementation.

Live sharing could take that a step further by allowing stakeholders to follow ongoing work and provide feedback without requiring access to the entire development environment.

For example, instead of manually summarizing an AI-assisted development session, we could share the relevant thread directly with a product owner, let them review the conversation, and optionally allow them to ask follow-up questions.

I realize interactive sharing introduces additional security considerations, particularly when agent actions can execute commands or modify files. Read-only live sharing would already be a useful first step, even without interactive collaboration.

This isn't intended to expand the initial scope unnecessarily. I just wanted to contribute a real-world scenario that might be worth considering when designing the thread-sharing mechanism.