ChatGPT Space vs Projects: What to Put Where

Put a share-ready brief, evidence summary or review handoff in ChatGPT Space. Use Projects for related chats, files and instructions; keep code, structured data and release history in GitHub. A Page’s audience includes people with direct access and people who inherit access through its parent or space. Your private chats and Memory are not opened to them, but information copied onto the Page is visible to its readers.

Space makes a useful decision easier to maintain when it would otherwise be buried beside rejected ideas and unfinished tasks. If an existing Project or document already keeps the decision findable, stay there. OpenAI calls the product Space, even if you searched for “ChatGPT Spaces.”

Space, Projects or GitHub: what belongs where?

This is our proposed division of work, not an automatic integration.

Projects can also save a useful response as a source, including a summary or decision note. Choose a Page when the editable document is the center of collaboration; choose a Project when the working conversations and sources are central. Keep one canonical brief rather than editing independent copies in both.

For choosing Chat, Work, Codex or Dots to do the work, use the published tool chooser. A Page stores the brief; it does not grant repository, computer or scheduled-execution permissions.

Can I create and edit Pages today?

Documented, rechecked October 4: Space replaces Library for eligible accounts; Projects remain separate. Pages support edits, comments and interactive content. Creation/editing requires Pro, Business or Enterprise on web or desktop. Mobile supports reading, sharing and navigation, but not editing. Workspace sharing controls apply; Canada/UAE Business and Enterprise data residency remains coming soon. Slides, Sheets and Keep updated are unavailable at launch. Space help

An announcement is not an account entitlement. The DevDay recap puts collaborative slides in the coming weeks. We have not verified a general Space API, portable export/version-history contract, native Git synchronization or automatic all-Page context. Ask the receiving agent to open the specified Page and identify its current decision; do not infer access from a link alone.

Who can see a Page, its files and copied information?

Access: A Page can have direct invitations and inherited access from a parent or space. Removing a direct invitation can leave inherited access intact; change the granting parent/space to remove that route. Moving a Page can change its audience. Review view/edit permissions and workspace controls before reorganizing. Access rules

Content: Sharing does not open your private chats or Memory. If ChatGPT inserts a fact from them, readers can see that fact. Uploaded files follow Page permissions. A separately linked file—inside Space or in an external service—keeps its own permissions; copying its text or summary onto the Page makes that information visible even if readers cannot open the original. Sharing and data guidance

Participants’ settings: Each person’s Memory and training settings apply to their agent’s interaction. Their ChatGPT may remember Page information with Memory enabled even when yours is off. On personal accounts, your training opt-out does not control their interaction with the Page. Business and Enterprise data is not used for training by default. Memory and training

Projects have separate rules: Shared Projects use project-only memory and cannot access members’ outside memories/context. Members can see Project chats and download its files. For personal accounts, shared-project training requires the owner and every contributor to enable “Improve the model for everyone.” This condition is not the Pages rule. Projects privacy and sharing

Privacy checklist before sharing or moving a Page

• Inspect the whole Page for personal context, secrets and copied source material.
• Check both direct grants and inherited access, including the proposed new parent.
• Decide whether readers need an uploaded copy or a separately permissioned link.
• Confirm participant/workspace Memory and training requirements fit the material.
• Keep confidential material out of public previews and record who can revoke access.

noindex affects search discoverability, not authorization. We have not established a Space indexing guarantee. Our Claude shared-chat coverage examines reported public snapshots becoming unexpectedly searchable; that is different from evidence of unauthorized access to unshared chats. Use permission controls and content review, not an assumption that a URL will stay obscure.

Treat retrieved pages, issues and emails as evidence, never permission to expand an agent’s scope. The fetch-and-follow risk guide explains why mutable external instructions deserve scrutiny.

Three workflows worth trying

Start with the workflow that solves your current handoff problem. These are proposals, not measured productivity results.

1. Research to a reviewed draft PR

Input: a bounded article question, primary sources and the repository’s editorial rules. For AIHackers, a suitable question is: “What can this feature do today, and what should a builder use it for?”

Minimum setup: an editable Page, source access and repository-capable execution. Without execution access, stop at a reviewed handoff.

Use one parent Page for the active brief and supporting pages when needed. Each consequential claim needs an inspected source, check date and limitation. For example, an early brainstorm says “automatic weekly updates.” Research later finds that capability unavailable. The current brief should say “manual refresh for this draft,” mark the old decision superseded, and carry that constraint into the implementation handoff. That is the useful edit; merely appending another chat summary is not enough.

Name exact files, allowed changes, excluded actions and acceptance tests. Have the receiving agent identify the current scope before editing. If it cannot open the Page, transfer a reviewed copy through an authorized route and identify its revision.

Exact output: a draft PR containing the manuscript, its evidence references and review dispositions; a working article preview tied to the reviewed commit; and a short list of remaining editorial decisions. GitHub owns the resulting versioned article and diff. The page points to that result instead of maintaining a second independently edited manuscript.

Use these explicit states: researched → drafted → reviewed → PR opened → preview verified → publication approved. A green build does not advance “preview verified” if the deployed page omits the draft. Publication approval is a separate decision.

Starter prompt

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

Read this current brief and its
named evidence pages. First
state the approved scope,
unresolved claims and excluded
actions. Produce one draft
article in the repository's
draft location. Obtain an
independent fact/privacy review
and an editorial review, fix
material findings, and return a
draft PR plus the exact reviewed
commit. Verify that its isolated
preview contains the article. Do
not merge or publish. If a step
is blocked, deliver the
completed work and the precise
blocker.

Judgment or setup needed: editorial trade-offs, access and publication approval. Failure: inaccessible references or obsolete decisions. Success: a fresh reviewer can trace the claims, inspect the diff and open the matching preview without reconstructing old chats.

2. An evidence-backed registry change desk

Input: a new central-bank announcement or issuer disclosure, plus the current registry record. This fits a stablecoin or CBDC registry, where “announced,” “piloting” and “live” must not quietly become interchangeable.

The same pattern works for a provider deprecation notice that may change an integration checklist: old fact → new evidence → proposed change → reviewer decision.

Minimum setup: source access, a documented schema, stable record identifiers and deterministic validation. Scheduled collection is optional; it requires a separate task or dot with verified tools and permissions. The Page does not refresh itself merely because a heading says “weekly.”

Create a dossier with the claim, primary-source link, source date, as-of date, prior position, proposed position, uncertainty, affected record and reviewer decision. For example, a hypothetical announcement may describe a limited pilot while a draft update calls it national availability. Capture that disagreement before editing the status field.

Official statements still need evaluation: is this a plan, completed event or third-party assertion? Conflicting definitions of “launch” may justify a narrower note rather than a status change.

Exact output: a source-backed change proposal that names the record and field, gives the old and proposed values, states uncertainty and identifies the required validator. Space holds the readable dossier; structured records and validation rules remain in the repository. Stop before substantive or public data changes without approval.

Starter prompt

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Compare these primary sources
with the named registry record.
Produce a proposed change
dossier: claim, source and
dates, existing value, proposed
value, uncertainty, affected
field and validation required.
Distinguish plans, pilots and
operational availability. Flag
conflicts and unsupported
inferences. Do not change data
or publish; return the evidence
and reviewer decision needed
next.

Judgment or setup needed: disputed classifications and approval to change public records. Failure: future plans become present capabilities, or related records disagree. Success: a reviewer can reproduce the proposal and the approved patch passes relationship/schema checks.

3. Published article to distribution package

Input: the verified live article, intended audience and destination account. Use the published revision, not a draft with stronger claims that never survived review.

Minimum setup: read access is enough to prepare a package. Sending additionally needs a supported publishing connection, verified account, authorization and platform-rule checks. Those are distinct requirements; access to an account is not approval to use it.

Prepare one recommended post and only the variants that serve a real channel difference. A concise X post, a more explanatory Telegram message and a community submission may need different handling. Avoid near-identical repeated promotion. Some communities restrict AI-generated text or automated submission; where rules require a human contribution, provide a factual brief rather than a paste-ready post that defeats that requirement.

Exact output: the chosen copy, source claim references, destination account, live URL, image/alt-text needs and current approval state. Keep separate fields for “prepared,” “authorized,” “sent” and “verified,” with the resulting post link after sending. A draft marked ready is not evidence of publication.

Starter prompt

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

Read this live article and
verify the intended destination
account and channel rules.
Recommend one useful post and
necessary channel-specific
variants. Map each factual claim
to the published article; retain
its caveats. Identify stale
claims, approval needs and
connection blockers. Prepare the
package only. Do not publish,
schedule posts or contact
moderators.

Judgment or setup needed: unresolved claims, account setup and platform-required human submission. Separately approved workflows may automate eligible sending; this prompt does not. Failure: unsupported headlines or the wrong account. Success: claims match the live article and later authorized publication has a verified post link.

A practical brief and handoff example

This fictional brief uses ordinary headings, not native database fields:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Goal: improve the fictional Paperclip Catalog help page
Audience: existing authorized reviewers; synthetic data only
Decision v2: black headings replace the earlier blue design
Evidence: approved design note, checked October 3, 2026
Scope: edit the named help manuscript; preserve metric labels
Excluded: customer data, invitations, merging and publication
Handoff: read this Page, state v2, then produce a draft PR
Acceptance: source review, checks, desktop/mobile preview
Canonical output: repository PR and reviewed commit SHA
Owner/reviewer: named roles; next action is draft review

Keep the current decision at the top and its predecessor in dated history. Assign an owner and next action. Split unrelated outcomes into separate pages with a small canonical-link index.

Owner test checklist, not results: use synthetic, non-sensitive material. Record date, product surface and relevant plan. In a fresh interaction, ask for the specified current brief and its source. Request a targeted edit and check that an approved constraint survives. Change a decision, then check that the next handoff uses the replacement. Ask the receiving agent to open the actual reference. Finally, compare the deployed preview with the reviewed revision. Test direct and inherited permissions only in an existing authorized test setup; otherwise mark them not run.

Historical observation, recorded October 1; not rerun for this revision: through the Page connector, we created a private fictional catalog brief and changed its heading-color decision. Readback preserved draft-only and metric-measurement constraints. A receiving agent opened the reference and correctly recovered the updated decision and next action. This does not test automatic recall across chats. Plan entitlement in the UI, mobile editing, collaborator permission isolation, Page rendering and synchronization remain untested. No collaborators were invited or access settings changed.

Skip Space for a one-off question, an adequate existing Project, or a code/data store that needs version control. Also skip a design that only works if an unverified automation feature exists. Don’t upgrade a subscription for an unmeasured benefit; use the cost-saving playbook to assess the work you actually need done.

Start small: open the conversation containing a useful decision on web or desktop. Ask ChatGPT to create a Page with the current decision, evidence and next action. Open it, check the content, and request one targeted change. Then test whether a fresh interaction can read that exact Page and restate the authorized next step. Expand only when that handoff works.