Share threads with multiple people for team working sessions

[ahatzz11]

Before submitting

✅ I searched existing issues and did not find a duplicate. #17196 is related but covers a single-use link for one outside viewer; this is about several teammates working in the same session at once.

Why

We often pair or mob on a task: one person drives the agent while others watch, suggest prompts, review diffs, or take over. Today the only options are screen sharing, or handing out the environment's global access, which exposes every other thread and project on that machine. Neither is good for a team working session.

Scenario

A thread is running in a worktree on a shared dev environment. I want to invite three teammates for an hour so they can follow the agent live, leave comments or queue prompts, and take the keyboard when it is their turn. When the session is over, their access should end without affecting anything else on the environment.

Requested scope

Let the owner of a thread (or project) share it with multiple named people at once, with per-person roles, scoped only to what was shared.

Suggested UX

1. Share dialog: a "Share" action on a thread or project that invites several people, by T3 Connect account or email, or through a reusable invite link.
2. Roles: viewer (read-only, live updates), collaborator (can send or queue messages, approve tool calls, comment), and owner (manages access and environment settings).
3. Presence: show who is in the session, who is currently driving, and typing or queued-prompt indicators so people don't talk over each other.
4. Driver handoff: an optional "take control" / "pass control" flow so only one person sends to the agent at a time, with queued suggestions from others.
5. Scoping: guests only see the shared thread or project. No other threads, projects, environment settings, or secrets.
6. Lifecycle: set an expiry (for example "end of session" or "2 hours"), and remove a person or end the share instantly.
7. Attribution: each message and approval in the thread records who sent it.

Suggested acceptance criteria

• An owner can share one thread or project with multiple people in a single action.
• Each participant gets a role (viewer or collaborator), and the owner can change it.
• All participants see agent output, diffs, and tool calls live.
• Participants cannot see or reach anything on the environment outside the shared scope.
• Presence and the current driver are visible to everyone in the session.
• Messages and approvals are attributed to the person who made them.
• Access can expire automatically and can be revoked per person or for everyone at once.

[jackpolloway]

We needed this too, so I built a small version of it on top of the existing guest links. It doesn't add roles, accounts or presence.

The change: one guest link can be redeemed by up to 5 people instead of 1. Each browser that opens it joins under its own name with its own session cookie, and the 6th sees "This guest link is full." Every guest message records who sent it, so the owner's pending list, the guest page and the agent's attribution line (Message from guest <name>, sent by the owner) all show the right name. Guests see each other's pending messages labeled by sender, and their own as "You". The 3-message pending limit and the pending-file cap now apply per guest, so one person can't fill the queue for everyone.

The rest works as before. The owner still approves every message, links still expire after 24 h, Stop sharing ends it for everyone, and it still needs T3 Connect. Shares created before the change stay single-guest, and guestName still holds the first guest so older clients keep working.

It touches the contracts (ThreadGuest, an optional guests list on the share, an optional sender on each message), GuestShareDecider, GuestShareService, and a few labels in the web owner controls, guest page and mobile. Tests cover it at the decider and service level. I also ran it end to end through T3 Connect with 6 browsers: 5 got in, the 6th was refused, the per-guest limits held, and each guest page labeled messages correctly.

Would you take a PR for this? I can change the cap or hide other guests' pending messages if you'd rather it work that way.