Sharing & collaborative chat
Chat sharing is named access — not a public link, not an organization-wide visibility setting. You invite a specific person by verified email, and only that account can accept.
Share a chat
In a saved chat, open the composer + menu and choose Share chat (or use Share from Chats). Enter the collaborator's verified email and review the access summary before creating the invitation.
The review covers:
- the complete retained chat history the collaborator will receive;
- linked documents, artifacts, citations, and tool results, which follow the chat automatically;
- each response's initiating agent, model, and effort metadata; and
- the fact that personal sandboxes, files, packages, environment variables, and credentials are never shared.
The invitation appears as a highlighted chat in the recipient's Chats, with Accept invitation in the row. No private link is required; the optional link is only a shortcut, and it still works only for the matching signed-in account.
If the optional link arrives before the recipient's invitation list refreshes, Chats still shows a generic invitation card with Accept invitation. The server rechecks the named recipient when it is clicked; the link does not reveal the chat or grant access by itself. A failed attempt stays visible with a safe retry message instead of silently ignoring the click. Project invitations use the same inbox, link fallback, named-recipient check, and retry behavior in Projects.
A safe retry does not reveal the one-time token again. Resend rotates it: the previous link stops working before the replacement is shown. An expired invitation is closed before the same person can be invited again.
What travels and what does not
This is the boundary worth understanding.
| Shared with the room | Stays private to each participant |
|---|---|
| Retained messages and visible Thinking | Sandbox workspace and files |
| Artifacts and their newest owned version | Installed packages and caches |
| Citations and linked resources | Environment values and credentials |
| Each response's agent, model, and effort | Connector grants and sessions |
| Membership changes | Confirmation, MFA, and approval state |
| Unrelated private Library items |
Every turn runs under its initiating participant — their agent, model, effort, grants, and credentials. Project or chat membership never intersects privileges across the room, and a turn can never borrow the owner's authority.
When you open an existing chat, the composer waits until Kaizen has loaded your current membership and posting rights. This brief loading gate prevents a message from taking the private-chat path before a shared room has been recognized.
The response footer keeps that turn's token counts, agent, model, and effort together. The same compact footer is used in private chats; execution metadata does not add a separate banner above Thinking.
Once a response, artifact, citation, or linked resource is committed, it is room content that every active participant can read.
Approved generative artifact progress also travels live to current room members, including a bounded latest snapshot for someone who joins mid-build. That progress is not an immutable journal version; only completion links the version into retained room content. Interactive artifacts relay bounded browser inputs through the room so current participants operate the same version. Recent inputs support reconnect, but they are not a durable application-state store.
Owner and collaborator controls
The owner can invite named members, resend or revoke pending invitations, remove collaborators, archive the chat, or delete it where policy permits.
A collaborator can read the retained shared history, participate, use the resources that belong to the chat, and leave. Collaborators cannot invite or remove members, or delete the owner's chat.
Pending invitations are shown separately from active participants. Leaving or being removed immediately ends future access — though content someone already saw cannot be clawed back. Unrelated, expired, invited-only, departed, and revoked members all receive the same not-found response as a missing chat, so membership is never leaked by the error.
One lane, in order
A collaborative chat has one durable first-in-first-out input queue and at most one active agent run. Sending a normal message while the agent is busy adds a turn to that queue; it never silently changes the active run.
Because the queue and its positions live in the conversation journal, two backend replicas cannot start competing turns for the same room.
Your browser is only an observer. Closing a tab, changing screens, or losing the network does not own or cancel execution.
Who is viewing
Open Participants to see which active members currently have the chat open. Presence is room-only and intentionally coarse: multiple tabs for one member still produce one Viewing this chat indicator. While someone types in the room composer, a short-lived Typing… indicator appears without retaining their draft.
Each person in the strip and in the roster behind it is shown as a circle. That circle carries the picture they uploaded, or the first letter of their name on the color they chose, under Settings → Your circle. You see each member's own choice, and your choice is what they see for you; nobody can change anyone else's circle. See Your preferences.
A normal final-tab close removes the indicator immediately; an interrupted connection expires within 30 seconds.
Presence never reports draft text, last-seen time, tab count, device, network address, or activity in another chat. It is disposable state — not conversation history, and not audit data.
Attribution and reconnects
Each shared human message shows the safe display name and room role recorded at acceptance, so the transcript never collapses several participants into one generic "you." Agent answers stay correlated to the exact initiating message and run.
Shared history is rebuilt from the durable journal. Your browser remembers the last applied position, ignores duplicates, and reconnects from there after a tab switch or network interruption. A temporary Reconnecting or Live updates are delayed notice does not mean a message or run was lost — committed messages, queue transitions, answers, and terminal outcomes catch up in order.
When you share an existing private chat, its completed turns stay completed. Opening that retained history as a collaborator does not reopen old questions as queued work or replace the normal composer with active-run controls.
If the cursor is no longer usable, Kaizen reloads an authorized snapshot before resuming live updates. If you leave or are removed, the connection stops and retained room state is cleared from your client; an old cursor cannot regain access.
Sharing inside a Project
A Project pointer never disables the owner's normal Share action. Direct chat membership and Project membership are independent, additive paths. The Chats library and the chat header show the current viewer's safe reason categories: Direct, Project, or Direct + Project.
Removing a direct grant leaves Project-derived access intact when the member still belongs to the Project. Unlinking the chat, leaving or being removed from the Project, or deleting the Project leaves an active direct grant intact.
When the removed path was someone's final path, new transcript, live, write, resource, search, and export access stops. A direct-only recipient can keep using the chat without ever learning it is organized in a Project.
Why sharing can be refused
Before an invitation is created or accepted, Kaizen rechecks inviter authority, the named recipient and workroom, participant limits, lifecycle, and journal integrity.
An unavailable agent prevents that member from invoking that agent — not from reading room content. Sharing fails closed for identity or workroom mismatch, expired or conflicting invitations, quarantine or integrity failures, and participant limits, using safe errors that reveal no unrelated private metadata.