ChatGPT Project Context and File Surfaces

ChatGPT Projects can keep chats, files, instructions, and related context together. Treat those product surfaces as distinct unless official documentation explicitly states that they share identity or lifecycle semantics.

Documented Product Model

Safe Operating Rules

  1. Keep one clearly named canonical instruction source when a Project also uses instruction files as reference material. Remove stale duplicates through the product surface that owns them.
  2. Remove source files that belong to another repository/project or that carry a conflicting operating model. An unrelated AGENTS.md, bootstrap file, or project instruction file can silently contaminate future answers even when it was added only as a temporary reference.
  3. When two Project source files contain the same instruction text, keep the clearly named/current one and remove the duplicate rather than relying on filename order or upload date to imply precedence.
  4. Do not infer overwrite, replacement, or object identity from display-name equality alone.
  5. When freshness matters, explicitly request the current instruction/source file rather than assuming every Project file has already been read in the current chat.

  6. Keep volatile repository state in repository truth, not in reusable Project instructions:

    Project instructions
  -> shared Project-wide behavior

repo/AGENTS.md
  -> durable repository rules

repo/CONTEXT.md
  -> current-only restart state

Issue / PR / Git
  -> active task, evidence, and durable history
  7. Prefer Project instructions for behavior that should apply throughout one Project. Prefer a Skill when the behavior is a reusable workflow that benefits from explicit packaging and reuse across chats or surfaces.
  8. Keep repository-specific authority in the repository even when Project instructions or Skills provide higher-level workflow guidance.
  9. Do not turn Project source files into mandatory rereads for every agent handoff. When repository/objective context is already usable, continue from the owning PR/comment. Reload broader context only when it changed, became stale/ambiguous, or a new authority/safety domain requires it. See Context Loading Economy for Agent Handoffs.

Keep the Project Sources list small enough that every source has an obvious job. A useful review asks of each source:

Prefer one canonical Project-instructions source plus a small number of durable reference files. Active Issue/PR state should normally remain in GitHub instead of being copied into Project Sources.

Empirical Observations, Not Product Guarantees

The following observations motivated this playbook but are not established by the cited product documentation and should remain dated observations until OpenAI publishes stronger guarantees:

Operational consequence: do not use a runtime filename or local working copy as lifecycle authority for a Project Source or Library object. Manage the product object through the product surface that owns it unless a documented tool/API says otherwise.

Validation Checklist

Before relying on a Project/file behavior:

For source-list hygiene, also verify:

Citations