Share and co-write a chat

Chats are personal by default. Sharing lets a permitted audience read a conversation or contribute to it, while keeping each participant’s private context and execution authority separate.

​

Before you begin

You need permission to manage the chat’s audience. Decide who needs to read the conversation and who needs to contribute. The intended audience must be allowed to receive its messages, attachments, tool results, and outputs.

​

Planned sharing procedure

The steps below describe the intended experience once collaboration is available and verified. They are not confirmation that every deployment currently supports these controls.

1. Open the chat you want to share and use its sharing controls to select a permitted audience.
2. Assign the applicable read or contribution permissions. Give contribution access to people who need to co-write messages.
3. Check any indication of excluded context. Sharing requires fresh access checks; access held by one participant is not sufficient for the whole audience.
4. Confirm the audience and permissions. Before joint work starts, have a collaborator check that they can read the intended conversation and, where permitted, use its composer.

Changing the audience rechecks retained context before it can be exposed to a new participant. Excluded private material must remain protected.

​

Co-write and submit a message

Contributors can draft together in the shared composer. Participant cursors show shared editing, and contributions retain attribution. If the interface reports a conflict, resolve it before submitting; concurrent edits must not silently replace another person’s changes. Agree who will submit the message, then review the draft and selected model, tools, and skills. Submission records the message and configuration for that turn. Later composer edits apply to a subsequent submission. The submitting user supplies the authority for model and tool operations. The turn uses that person’s current permissions, tool eligibility, and limits. Another participant’s permissions cannot supply missing authority, even when they helped write the message. For example, if a colleague can read a private file but the submitting user cannot, the colleague’s presence does not authorise the turn to retrieve it. Any context included in the shared response must also be permitted for the receiving audience.

​

What remains private

The interface identifies excluded context without revealing its contents. If needed context is missing, check its permissions and whether it can be shared with the audience before using it in the conversation. For project-specific examples, see Understand project sharing boundaries.

​

Change or remove access

When you change the audience, inspect the resulting access and any context exclusions again. Removing a participant blocks their subsequent protected reads and writes, including live updates. Revocation cannot recall material already delivered. Sharing and co-writing do not grant review or publication authority. They also do not enable autonomous agents or runtime tools in an ordinary chat.

​

Check the result

Confirm the intended collaborators have the appropriate read or contribution access. Check that the submitted message reflects the agreed draft and retains attribution. Inspect any tool refusal under the submitting user’s permissions. Use Choose a model, tool, or skill for a chat to prepare the turn. Use Find and verify earlier research when bringing prior work into the shared conversation.