Projects

A project gives a shared body of work durable instructions, files, memory, and access settings. Choose one when people or recurring work should use the same context.

This gives all work the same foundation: a stable place for instructions, files, memory, skills, connector activations, external API hosts, and access policy.

Create and save projects

Select Create project to name a project, add instructions, and make it visible in Projects. You can add files during setup or connect other sources later.

You can also start a chat, automation, or dashboard without choosing a named project. Use Save as project in a standalone chat when its context should become a named, listed resource. This keeps the existing conversation and files. Until you save it, Save as project suggests the chat's automatic name. Automations and dashboards do not currently offer that control. Manage an agent's context through its own settings.

What belongs in a project

• Instructions state the enduring goal, constraints, terminology, and working rules.
• Project files are reusable source material available across work in the project.
• Memory is durable project knowledge that the agent maintains. You can read each entry in the product. People with edit access to the project can also edit or delete an entry, or add up to 50 entries in one step.
• Skills provide reusable operating procedures pinned to a specific installed version.
• Connectors normally start with the workspace's active connections. Remove or add a connection for this project as needed. Agents created through conversation instead use only their reviewed connections and do not inherit later workspace connections.
• Network access may add exact external API hosts when the workspace policy delegates that choice to project editors. A host grant allows HTTPS API calls to that host. It does not add stored credentials to them. Approve only APIs you trust. Workspace-wide host rules are inherited automatically.

Conversation history, session uploads, and files received through an agent channel stay with the individual session. Use session scope for one-off material; use project scope only when future work should inherit it.

If your work shows Computer, work in the same project can use the same desktop files and browser sign-ins. Treat files saved there as project material, not as private to one chat. Chats, dashboards and automations without a named project keep their own context. Moving work to a different project does not automatically move an existing desktop.

For Computer, Internet access follows the workspace policy; project editors cannot override it. Connector access and project permissions still apply.

Workspace agents and unattended runs can also contribute a named, versioned memory entry directly to another project in the same workspace. The contribution is attributed to the source session. This is the durable handoff path for findings, plans, decisions, and review notes; messaging a teammate alone does not automatically copy its eventual result into a project.

Ask a named agent in a Project

Project messages use d5s by default. To ask a named workspace agent, type @ followed by part of its name, then choose a match from Agents. Up to six matching agents appear. Type more to narrow the list. The selected mention stays in your message. This works from the Project overview and an existing Project chat. Selecting a name does not send. Your other text and attached files stay in place. Remove the agent mention to return to d5s. Each new message starts with d5s unless you select an agent mention.

The selected agent answers in that Project chat, with its name beside the response. Its avatar appears beside the first matching mention in your request.

In the agent’s Home conversation, expand Worked in to read the original Project request, the agent’s tools and searches, and its reply. Each entry stays open until you close it. Select Open project chat to continue in the source conversation. The preview shows that request’s activity and response; open the Project chat for later replies or work resumed after an approval or interruption. Both actions require current access to that Project chat. If access is removed, the preview becomes unavailable. The activity list updates while Home is open.

Expand the activity group in a Project reply to see what the agent searched or read. A chat search shows its query and one row for each matching chat, with the number of matches. A chat read shows which messages the agent read, for example Read messages 81–83 of the chat. reached the end means that read got to the last message of the chat. Select a row to open that chat. If you cannot access a chat, its row shows Private chat. Ranges from separate reads can overlap. Older activity can lack these details. A reply without a history lookup does not imply that the agent searched the Project.

You can ask the same agent to recall a report from Home or work it did in another Project. It retrieves relevant conversations when you and the readers of the current chat can access them. Home and Project chats remain separate; ask for the earlier work when you need it.

An agent can inspect selected instructions, memory, files, and chat ranges from accessible Projects in the same workspace. Mentioning a Project does not load every conversation. Workspace access is the default; Restricted access and current permissions still apply.

A named agent working in a Project can ask another workspace agent for help and bring its answer back to the chat. The agent can include information it already received. Current permissions control who can send the request and read the receiving conversation. A handoff does not grant access to the original sources; new reads still require permission.

One starting model for Project chats

A workspace Owner or Admin can choose Workspace default or an enabled model in the Project composer. New ordinary chats in the Project start with that choice for every member. Other members can see the Project choice but cannot change it.

A chat keeps the model it started with. When the Project choice changes, only chats that start after the change use the new model. Inside a chat, anyone who can send messages there can pick another level or model for that chat; the Project and other chats do not change. A specific Codex model stays a workspace Owner or Admin choice. Named agents, automations, dashboards, and their runs keep their own model settings. Choose Workspace default to remove the Project override and inherit future workspace-default changes. A catalog model choice follows the newest available version of its family on later turns; work already running and history keep the version used.

Access follows the work

By default, a project inherits access from the workspace. A project can also be Restricted, with explicit Owner, Editor, or Viewer grants for people and groups. Chats, automations, dashboards, and an agent conversation inherit their base access through the project rather than maintaining unrelated sharing lists. Retained email correspondence follows access to the agent's project; Send copies to affects delivery, not in-product visibility. Other external chat turns can still be narrower because provider membership remains an additional boundary.

In a personal organization, a share manager who is not the organization owner can grant project access only to people who already have access to that workspace and cannot target organization groups. See Sharing and permissions for the full role and targeting rules.

Capability access is separate. A person may be allowed to edit a project while a connector action remains unavailable, denied, or approval-gated by its workspace policy. A host grant allows HTTPS API calls to that host. It does not add stored credentials to them.

Favoriting a project is personal to each user. A favorited project is pinned to the Projects section of your sidebar, where its arrow shows its three newest chats. Select Show more to add five more chats, up to two times, then View all opens the project. Select the page-and-pen icon to the right of its three-dot menu to start a new chat in that project. Archiving is workspace-wide and recoverable. Deleting removes the project and its owned work, and d5s refuses deletion while a run in that project is still active.