chatgpt-shared-projects
ITIAN ChatGPT Academy
Technology Simplified — Solutions That Work
Share Projects and Collaborate Safely
Prepare a Project for other people, assign the least access they need, understand what members can see and maintain a clear collaboration boundary.
Learning Objectives
By the end of this lesson, you will know what sharing exposes, which access level to choose and how to prepare, operate and close a shared Project safely.
Explain
Describe shared Project visibility.
Assign
Choose owner, Edit or Chat access.
Prepare
Screen chats, files and instructions.
Govern
Review members, changes and exits.
Sharing changes the context boundary
When a Project is shared, its memory changes to project-only. It cannot later be reverted to default memory. The shared Project does not use members’ personal context, Custom Instructions or memories from outside the Project—but members can see and use the content placed inside it.
Prepare the Project before selecting Share. Removing a member later does not undo what they may already have viewed, downloaded or copied.
What Members Can See
Visible inside the shared Project
- Project chats, including new, moved and branched chats
- Uploaded files and saved Project sources
- Current Project instructions
- Other Project members and invited groups
- The author associated with each chat
Not automatically exposed
- A member’s unrelated ordinary chats
- Chats in other Projects
- Personal memories outside the shared Project
- Global Custom Instructions outside the Project
- Other Project files not added or moved here
Context can travel through responses
If someone adds a file or information to the shared Project, ChatGPT may use it in responses visible to other members. Treat every added chat, file and saved response as shared material.
Access Levels
Apply least privilege: give each person only the access required for their role.
| Capability | Owner | Edit access | Chat access |
|---|---|---|---|
| View and interact with chats, files and instructions | Yes | Yes | Yes |
| Create chats and use Project context | Yes | Yes | Yes |
| Update Project instructions | Yes | Yes | No |
| Upload or remove files | Yes | Yes | No |
| Invite other people | Yes | Yes | No |
| Remove existing members | Yes | No | No |
| Change member permissions | Yes | No | No |
| Rename or delete the Project | Yes | No | No |
Plan and workspace controls can impose additional restrictions. Confirm the current sharing pane before inviting anyone.
Invite-Only or Anyone With the Link?
Only those invited — recommended starting point
- You identify each intended member.
- The owner can review and change individual access.
- It reduces unintended joining if a link is forwarded.
- Use named invitations for client, internal or sensitive work.
Anyone with the link — wider joining risk
- Any signed-in ChatGPT user with the link may be able to join when this option is available.
- The owner’s plan determines collaboration limits.
- A forwarded link can extend access beyond the original audience.
- The owner should return to invite-only when broad joining is no longer required.
A link is not a permission strategy
Do not post a joining link publicly or send it through an uncontrolled channel merely because the Project is convenient. Confirm recipient identity, purpose, access level, expiry/review date and the organisation’s approved sharing method.
Prepare the Project in Six Steps
Confirm authority
Verify that you are allowed to share the Project and every included source with the intended people.
Inventory the content
Review chats, files, saved responses, instructions, connected-source references and member-visible names.
Remove or redact
Move unrelated chats out, remove credentials and minimise personal or confidential information.
Assign least access
Default to Chat access unless the person genuinely needs to change files, instructions or invitations.
Set working rules
Document purpose, source authority, naming, approvals, escalation, review rhythm and exit procedure.
Test and invite
Use a non-sensitive pilot, verify what the invited person can see, then add the remaining approved members.
Collaboration Is Not Live Co-Editing
Use branching for alternate directions
Members can branch a chat to explore another draft or approach while preserving the original. The branch appears alongside the original and is visible to Project members.
Coordinate ownership
Shared Project chats are not synchronously co-edited like a live document. Assign a chat or deliverable owner, use branches deliberately and record which result was approved.
Recommended hand-off note
Owner · Task · Source set · Current status · Decision needed · Deadline · Next action. This prevents two people from unknowingly making conflicting changes.
Shared Project Versus Shared Chat
| Question | Share the Project | Share one chat |
|---|---|---|
| What can recipients see? | Shared Project chats, files, instructions and member list | Only that chat up to the shared point |
| Can they use the Project workspace? | Yes, according to assigned access | No; they do not gain access to the originating Project |
| Best use | Ongoing collaboration with shared context | Reviewing or showing one conversation |
| Memory change | Project becomes project-only | Does not make the viewer a Project member |
| Main risk | Broad visibility across the Project | The shared chat itself may still contain sensitive information |
Interactive Sharing Readiness Planner
Create a review brief before inviting anyone. Do not enter names, emails or confidential information into this training tool.
During and After Collaboration
Operate safely
- Review the member list and access levels regularly.
- Identify each chat owner and approved source.
- Record decisions and changes to instructions.
- Challenge unexpected files or links before use.
- Remove access promptly when the role ends.
Understand exits
- A member can leave through the Project menu.
- They may be offered a copy of their chats before leaving.
- Removed chats stop being visible to other members.
- Removing all collaborators does not restore default memory.
- Deleting the Project removes access for everyone and cannot be undone.
Recommended: 16:9, captioned, showing content review, access selection, invite-only sharing, member audit and removal.
Future screenshot plan
- Share button and sharing pane
- Chat and Edit access choices
- Invite-only and link visibility
- Member list and author markers
- Branching a chat
- Changing or removing access
Refresh screenshots whenever plan availability or interface labels change.
Practical Activity: Run a Safe Sharing Audit
You do not need to invite a real person. Complete the audit using a practice or fictional collaboration scenario.
Quick Knowledge Check
Answer all five questions before continuing to the Module 4 capstone.
Lesson Summary
Seven ideas to remember
- Sharing exposes the Project’s chats, files, instructions and member list to members.
- Shared Projects use project-only memory permanently.
- Use least privilege and default to Chat access unless Edit access is required.
- Invite-only sharing is the safer starting point.
- Review every chat and file before sharing because removal cannot undo prior viewing.
- Use branching and clear ownership rather than assuming live co-editing.
- Review members regularly and plan exits before collaboration begins.
Official OpenAI references
- Projects in ChatGPT — current sharing availability, access levels, visibility, memory boundary, collaboration and exits.
- Role-Based Access Controls — additional shared-Project controls for supported managed workspaces.
- Delete and Archive Chats — retention and recovery implications for member-visible conversations.
Sharing availability, collaboration limits and workspace controls can change. Verify current official guidance and your organisation’s policy before publishing plan-specific instructions.