Reader question: What should follow a shared AI project, what must stay in its own file or permission system, and which setup fits a small team?
The word “project” sounds like one container. It is not. Current ChatGPT documentation distinguishes projects that group chats, uploaded files, connected sources, and instructions from local projects that attach computer folders. A shared project adds people and roles. ChatGPT Learn’s projects guide
Teams now use the same word for a context hub, file workspace, and system of record. The safe question is not “Can the AI see this?” It is “Which context follows the project, and which permission must still be granted elsewhere?”
What follows a ChatGPT project
Project instructions apply across its chats. Uploaded files, connected sources, and conversation history give ChatGPT context for later work. A moved chat inherits the project’s instructions and file context. OpenAI’s Projects documentation
Use a project for recurring work: an approved brief, terminology sheet, public reference pack, and decisions about how to use them. It is cumulative, so a later question can be shaped by earlier chats and files.
Sharing changes the boundary. OpenAI says shared projects use project-only memory automatically and do not use a member’s personal context, custom instructions, or memories outside the project. Members see others’ contributions, and added files or context may appear in responses to other members. OpenAI’s shared-project guidance
That is a useful privacy boundary, not a confidentiality promise. A shared project is a shared room. Put material there only when every member may encounter it in a response.
What does not magically follow
First, a ChatGPT project is not a direct window into a computer folder. Upload or connect sources for a ChatGPT project. A local project’s attached folders are a separate access boundary; ChatGPT can read and change them, while secondary folders do not automatically provide project instructions or configuration. ChatGPT Learn on local projects
OpenAI separately says local files and outputs remain on the computer unless moved or shared. Its guidance for sharing eligible cloud-based scheduled tasks from Work adds a narrower rule: that sharing does not transfer chat history, local files, folders, device access, credentials, memories, custom instructions, or workspace permissions. Recipients of those scheduled tasks need their own Work, model, and connected-app access. This is not a universal rule for every shared chat or project. ChatGPT Work and Codex
Inside a shared project, the file boundary is broad: all members can view and download added files. Chat access permits interaction with chats, files, and instructions. Edit access also permits changing instructions, uploading or removing files, and inviting others. The owner can change access and remove members. Shared-project access controls
So a project link is not a fine-grained file-permission system. It shares working context at the role level. A Drive, SharePoint, repository, or client portal may remain the right home for the authoritative file and its membership rules.
Pick the smallest useful setup
For a three- to six-person team, use this decision rule:
| If the work needs… | Use… | Keep separate… |
|---|---|---|
| Repeated questions from the same approved material | One shared ChatGPT project | Contracts, personal data, credentials, and the authoritative file archive |
| Different client or personnel permissions | Private projects plus the existing controlled file system | Any source a project member is not already cleared to see |
| AI to read or edit code, design files, or local exports | A local project with explicitly attached folders | ChatGPT project membership, cloud-drive groups, and repository rights |
The sensible default is one shared project as a context layer, not the company filing cabinet. Add the current brief, public background, glossary, and approved examples. Keep contracts, raw customer exports, unreleased creative, and credentials in the system that manages their access. Add a restricted fact only as an approved excerpt or pointer after checking every recipient’s rights.
Use chat access for most contributors and edit access for one steward plus a backup. Keep the membership list named. “Anyone with a link” is a different risk posture from specific invitations; owners can switch back to invite-only. Project sharing options
Give the project an owner and a handoff
The owner maintains the context boundary: project instructions, membership, stale uploads, and a source index with file, owner, status, and review date. They also name where a final answer becomes authoritative. A project response can inform a decision without being the decision record.
The handoff to a new teammate includes the project link, purpose, source index, and an orientation chat explaining what is safe to ask. Do not hand over credentials or assume the link grants local-folder or connected-app access. Grant restricted-source access in the source system.
Keep private exploration out of the shared room. Members can move a chat outside a shared project; then other members, including the owner, can no longer see it. A branch remains visible unless its creator moves it out. Collaboration and chat behavior
Plan for ownership change. Deleting a project permanently deletes its files, chats, and instructions, so members lose access unless they copied what they needed. Point to a durable source of truth rather than keeping the only deliverable copy in the project. Project deletion and retention
Stop when the boundary cannot be answered
Before adding a file or inviting a person, stop if the team cannot answer five questions:
- Who can view and download this material?
- Who can edit the project instructions or invite someone else?
- Which system grants access to the underlying source?
- Where does the approved output live after the chat?
- What happens if the project owner leaves, the file changes, or the project is deleted?
If any answer is “we are not sure,” keep the material in its controlled system and use a less sensitive project summary. That pause prevents a context shortcut from becoming an accidental permission grant.
A shared AI project is valuable when it gives a team a common starting point and visible contributions. Treat context and permission as separate decisions: let the project carry approved working context, and let the file system, repository, and workspace controls carry authority.
Sources and limitations
- ChatGPT Learn, “Projects and chats” — checked September 2, 2026; supports project chats, files, instructions, connected sources, ChatGPT versus local projects, attached-folder behavior, and the choice between a project and a standalone chat. Limitation: product guidance can change, and local-folder behavior depends on the selected app, workspace, and permissions.
- OpenAI Help, “Projects in ChatGPT” — checked September 2, 2026; supports shared-project memory boundaries, member visibility, chat/edit roles, file download access, link sharing, chat removal, owner controls, deletion, and retention-policy inheritance. Limitation: plan, workspace, feature, and administrator settings affect availability; this product documentation is not an organization’s records or confidentiality policy.
- OpenAI Help, “ChatGPT Work and Codex” — checked September 2, 2026; supports local-file boundaries separately from the recipient-eligibility and no-transfer rules for eligible cloud-based scheduled tasks shared from Work. Limitation: those scheduled-task rules must not be generalized to all task, chat, or project sharing; check each product's controls.