How to Build a Model-Switch-Safe ChatGPT-to-Codex Task Packet: Preserve Sources, Constraints, and Tests When GPT-5.5 Falls Back or Retires

Define the continuity problem before choosing a destination

A model-switch-safe task packet is a versioned, human-reviewed record of what another ChatGPT surface must know and may do. It carries the task’s authoritative sources, objective, constraints, working scope, required output, acceptance checks and recovery procedure. Its purpose is to preserve task intent when the model or product surface changes; it does not make different models equivalent, reproduce a previous response exactly or guarantee correctness.

The distinction matters because a conversation contains more than its latest instruction. Requirements may be scattered across corrections, attached files, quoted sources and decisions made several turns earlier. A person reading the whole conversation may infer which statements supersede others, but a new task in another surface should not be expected to reconstruct that history. The packet converts those implicit dependencies into an explicit control document.

This tutorial is not an API migration guide. It addresses a manual handoff from an important ChatGPT conversation to ChatGPT Work or Codex. The practical decision rule is:

• Continue conversational exploration in Chat while the question is still being framed and no repository action or finished multi-step deliverable is required.
• Prepare a packet for Work when the objective is a longer, multi-step deliverable assembled from supplied evidence.
• Prepare a packet for Codex when the task concerns software development, repository files, commands, tests or a reviewable code or documentation diff.
• Split the packet when research and implementation have materially different permissions or acceptance criteria. Work can produce or refine the evidence-led brief; Codex can receive only the approved implementation portion.

OpenAI’s “ChatGPT Work and Codex” help article, as accessed on 1 October 2026, makes the relevant product distinction: Chat is intended for fast conversational and everyday assistance, Work for longer multi-step work and finished deliverables, and Codex for software development and technical work. The same article says Chat and Work conversations can appear together in the “Recents” list, whereas Codex is a separate view and its history remains separate from ChatGPT history.

That documented separation is the operational reason for a manual packet. It does not establish automatic transfer of a Chat conversation, its attachments, source citations, selected model, permissions or unresolved assumptions into Codex. Even where Chat and Work conversations are visible together, visibility is not proof that every dependency is active in a new task. Treat the destination as having no task-specific context until the packet supplies it.

Before handing a source-dependent task to Codex after a model change, establish which retirement has altered the operating context. The o3 and GPT-4.5 retirement timeline sets out the deprecation and migration background for those models, which helps separate a change in available models from the sources, constraints and checks that the packet must retain.

A dated status note, not a model-equivalence claim

Two dated OpenAI notices provide the immediate motivation. First, OpenAI’s ChatGPT release notes dated 6 July 2026 said GPT-5.5 Instant Mini was rolling out in ChatGPT. It replaced GPT-5.3 Instant Mini as the fallback reached after GPT-5.5 Instant or Auto rate limits. OpenAI also said the fallback would not appear in the model picker and that this update did not affect the API or Codex.

This is a narrow ChatGPT fallback statement. “Rolling out” does not mean that every account received it at the same time, and the notice provides no basis for claiming equivalence with GPT-5.5 Instant or Auto. It does not document the fallback’s context capacity, tool access, speed, output quality, safety behaviour, price, API identifier or availability in Codex. A user therefore cannot make an important task portable merely by recording “use the same model”. The fallback may not be selectable, and the underlying requirements still need to be preserved independently.

Second, OpenAI’s Codex model documentation, as accessed on 1 October 2026, scheduled GPT-5.5 to retire from ChatGPT, ChatGPT Work and Codex on 14 October 2026. At the research date, this was a future scheduled retirement, not a completed one. The same documentation explicitly said that this retirement did not apply to the OpenAI API. If this tutorial is read on or after 14 October 2026, the current official documentation and the reader’s product notices must be checked rather than treating the schedule as confirmation of what ultimately occurred.

Do not turn either notice into a recommendation for a replacement model. OpenAI’s documentation says model visibility can depend on plan, client, rollout, workspace settings, role and administrator controls. A model named in documentation or written into a Codex configuration does not thereby become available to an account. The correct procedure is to record the visible or selected model, if the product shows one, as environmental metadata rather than as the task’s source of truth.

A useful distinction is:

Decision rule: if a task would become ambiguous when the originating conversation disappears, the selected model changes or an attachment is unavailable, stop and create the packet before requesting further work. A low-stakes brainstorming exchange may not justify this overhead. A change that will be published, merged, sent to a customer or used in a consequential decision usually does.

Write a packet charter before copying content

The packet charter is a short control block at the beginning of the handoff. It identifies who owns the task, what state the packet is in, which destination may act on it and who must accept the result. This is different from the detailed task brief: the charter controls the handoff, while the brief describes the work.

Start in a plain, reviewable format such as a repository Markdown file or an approved internal document. Assign a stable packet identifier and a revision number. Avoid naming the file only after a model, because the task may outlive that model. A descriptive name such as docs-auth-timeout-packet-v1.md is more durable than gpt55-task.md.

Use the following minimum charter fields:

Packet ID:
Packet revision:
Prepared on:
Task owner:
Human approver:
Origin surface:
Destination surface:
Model shown, if any:
Status:
Purpose:
Authorised materials:
Permitted actions:
Prohibited actions:
Acceptance authority:

The task owner resolves ambiguity and decides whether the objective changes. The human approver decides whether the resulting deliverable is acceptable. They may be the same person for a small documentation edit, but naming both roles prevents a generated completion from being mistaken for approval.

The origin surface and destination surface provide provenance. For example, write “Origin: Chat; destination: Codex” rather than “moved from GPT-5.5”. A model label alone does not state which tools, history or permissions were available. If a model is visible, record it with a date and qualify it as observed metadata: “Model shown by destination on 2026-10-01: [label]”. Do not instruct the recipient to fabricate a missing label.

The status should use unambiguous lifecycle terms, for example draft, approved for planning, approved for editing, awaiting human review, accepted or rolled back. “Done” is too vague because it can mean that text was generated, files were modified, checks ran or a human accepted the work.

Decision rule: no destination may edit files merely because it received a packet. The charter must expressly say whether the current revision is approved for planning only or approved for bounded edits. For an uncertain repository task, start with planning only, inspect the proposed scope and then issue an approved revision for editing.

Build the packet schema

The complete packet has nine linked parts: source register, claim state, version record, ownership, permitted actions, exclusions, working scope, output contract, and success and rollback controls. Keeping them separate makes omissions visible. Combining everything into a long narrative prompt makes it harder to determine whether a requirement is authoritative, optional or merely contextual.

Once the packet records the sources, repository scope, constraints and acceptance checks, the next question is how that context reaches the editor. A tutorial on Codex IDE context sharing and task handoff in VS Code covers the extension, inline edits and work hand-offs, so it gives useful background on the environment that will receive a carefully prepared packet.

1. Source register with stable IDs

Give every source a short identifier such as SRC-01. Then refer to that identifier from requirements and checks. The register should say what the source is, which version or retrieval date applies, where the authorised copy resides and what it is allowed to support.

Source ID:
Title:
Publisher or owner:
Version, publication date or retrieval date:
Authorised location:
Relevant section:
Supports:
Does not support:
Access classification:

“Authorised location” may be a repository path, an approved attachment name or an official public address. Never paste passwords, access tokens, private keys, session data or unapproved personal or proprietary information into the packet or prompt. If a source requires restricted access, state that an authorised human must supply an approved extract. Do not ask the model to bypass access controls or infer missing content.

The supports and does not support fields constrain interpretation. For example, a style guide may support the spelling of interface terms but not a claim about current product availability. This prevents a broadly relevant source from being treated as authority for every sentence.

Use dates carefully. If a source has a formal version, record it. If it is a changeable web page without a displayed publication date, record the access date and, where policy permits, retain an approved snapshot or quoted extract. Never silently replace a source while keeping its old ID. Create a new source version, such as SRC-02 v2, and record which requirements changed.

Decision rule: a factual requirement that cannot be traced to a registered source, an explicit owner decision or a clearly labelled assumption is unresolved. It must not be presented as established fact.

2. Claim and uncertainty ledger

The source register identifies evidence; the claim ledger identifies what the packet believes that evidence means. Use one of three labels:

• Sourced: directly supported by a registered source.
• Owner decision: chosen by the task owner, such as the desired heading or scope limit.
• Unresolved: missing, conflicting or awaiting human confirmation.

A practical row contains a claim ID, statement, status, source or decision reference, and effect on the task. For example, “CLM-03: the guide must use British spelling — owner decision DEC-02 — affects all changed prose.” If two sources conflict, do not invite the destination to choose whichever seems plausible. Record the conflict and either block the affected change or ask the owner to issue a decision.

Trade-off: a detailed ledger takes longer to prepare, but it is appropriate when factual errors would be costly to unwind. For a two-line typographical correction, one source reference in the packet may suffice. The test is not document length; it is the number and consequence of assumptions.

3. Version and decision record

A packet revision should be immutable once work begins. If requirements change, increment the revision and summarise the delta. This prevents a reviewer from comparing output against a different brief from the one used to produce it.

Revision: 1.1
Supersedes: 1.0
Changed by: task owner
Change:
Reason:
Affected source IDs:
Affected checks:
Work from earlier revision to discard or re-review:

Record decisions separately from source facts. A source might say several approaches are valid; the owner’s selection among them is a decision, not a sourced inevitability. Include the decision maker, date and rationale, particularly when the choice narrows repository scope or declines an otherwise plausible edit.

Decision rule: if a change alters the objective, authorised files, factual basis or acceptance checks, issue a new packet revision. A spelling correction within an already approved draft need not force a revision unless local policy requires it.

4. Task owner and escalation route

Name a person or accountable team, not “the user”. State which questions the destination may resolve and which must be escalated. A documentation maintainer might authorise wording choices but require a security engineer to approve authentication guidance. A developer might approve implementation details but not privacy policy claims.

Human review is mandatory for security, privacy, money, employment, government and other consequential decisions. The packet may organise evidence or produce a draft, but an authorised person must inspect the relevant sources, changes and checks before action or publication. Do not allow the model to make final access-control, hiring, financial, eligibility, disciplinary, legal-status or public-service determinations.

Add a stop condition: “If an unresolved issue affects factual accuracy or authorised scope, stop without editing and report it to the task owner.” This is more useful than “ask questions if needed”, because it defines when uncertainty blocks action.

5. Permitted actions

List positive permissions narrowly. Suitable examples include:

• read the packet and named repository files;
• inspect existing terminology in one documentation directory;
• propose a plan before editing;
• modify two named Markdown files;
• run specified local documentation checks;
• return a unified diff and a check log for human review.

Do not write “make any necessary changes”. That delegates scope definition to the destination. If discovery may reveal related issues, permit reporting them without fixing them. This preserves useful observations while keeping the authorised change small.

OpenAI’s Codex prompting guidance, as accessed on 1 October 2026, recommends specifying the goal, context, output and boundaries, and for software tasks naming the desired behaviour, relevant code or reproduction, constraints and verification. It also describes a plan-first option for multi-step work. Treat that as prompting guidance, not evidence that a plan or implementation will be correct.

Decision rule: grant the least action needed to produce review evidence. If a draft or diff is sufficient, do not authorise publication, merge, deployment, external messaging or account changes.

6. Explicit exclusions

Exclusions state what must remain untouched even when it appears related. Include files, directories, behaviours, dependencies, formatting, generated artefacts and external actions. Examples are “do not change application code”, “do not update dependency versions”, “do not edit generated reference pages” and “do not open a pull request”.

Also exclude unsupported factual invention: “Do not add claims not supported by SRC-01 or SRC-02; list missing evidence as an unresolved issue.” This is particularly important when the originating chat contained speculative suggestions that were never approved.

Trade-off: tight exclusions reduce accidental expansion but may prevent a convenient clean-up. Prefer the narrow packet for the immediate task. Record adjacent improvements as follow-up candidates, then authorise them separately if they merit review.

7. Working files and repository scope

For Codex, identify the repository, branch or worktree context supplied by the human, the allowed paths, the read-only context paths and the files forbidden from change. Do not assume that a file mentioned in the old chat is present or current. Ask the destination to confirm that the named paths exist before editing.

Repository:
Baseline revision supplied by owner:
Writable paths:
Read-only context paths:
Out-of-scope paths:
Expected new files:
Generated files:
Setup assumptions:

If the repository uses AGENTS.md, record which instructions are expected to apply. OpenAI’s Codex documentation says Codex reads AGENTS.md before doing work and describes layered instructions from broader to more specific locations. That file can carry durable repository conventions, but it is not a security boundary and does not replace the packet, tests or review. The human should inspect the applicable instruction files and resolve conflicts before approval.

Decision rule: if the destination reports an unexpected instruction file, missing dependency, changed baseline or path outside the approved scope, pause. Do not widen the packet implicitly.

8. Output contract

The output contract describes the evidence the destination must return, not merely the artefact it should create. For a documentation change, require:

1. a concise plan or confirmation of the approved plan;
2. a list of changed files;
3. the proposed diff or patch;
4. a mapping from each change to its source or owner decision;
5. commands requested and whether each was actually run;
6. unaltered command output or a clearly identified summary;
7. unresolved questions and out-of-scope findings;
8. a statement that human acceptance is still required.

Never allow “tests pass” to stand without identifying the tests. Conversely, do not require the destination to claim execution when it could not run a command. The permitted response should be “not run”, followed by the reason and the exact command a human can execute.

Decision rule: reject an output that cannot distinguish generated proposal, observed repository state, executed check and human decision.

9. Success checks and rollback

Success checks must be observable. Separate automated checks from human acceptance:

• Automated or mechanical checks: named commands, link validation, formatting checks, tests or searches.
• Source checks: every factual change maps to an approved source or owner decision.
• Scope checks: only authorised files changed; generated files remain untouched unless expressly allowed.
• Human checks: wording is accurate, useful, proportionate and suitable for publication.

Rollback is not simply “use version control”. Define the pre-change reference, what should be restored, which generated artefacts need regeneration or removal, who may authorise rollback and what evidence must be retained. For a draft-only task, rollback may mean discarding the unaccepted patch. For an already merged change, the packet should defer to the repository’s approved recovery procedure rather than inventing commands.

Decision rule: if rollback cannot be described safely, restrict the packet to a non-writing plan or draft. Do not authorise an irreversible action merely because the desired end state is clear.

Complete hypothetical packet: a small documentation correction

The following example is entirely hypothetical. It demonstrates packet structure; it is not a report of a real repository, product interface, command run or test result.

Packet ID: DOCS-AUTH-017
Packet revision: 1.0
Prepared on: 2026-10-01
Task owner: Documentation maintainer
Human approver: Authentication feature owner
Origin surface: ChatGPT Chat
Destination surface: Codex
Model shown, if any: Record at execution time; do not require a named model
Status: Approved for planning only

Purpose:
Correct one authentication timeout statement in a small documentation guide
and align one nearby term with the approved style guide.

Authorised materials:
SRC-01, SRC-02 and the repository paths listed below.

Permitted actions:
Read authorised files; inspect applicable AGENTS.md instructions; propose a
minimal edit plan; identify verification commands. Do not edit until the
owner changes status to "approved for editing".

Prohibited actions:
No application-code changes, dependency changes, generated-reference edits,
external publication, pull request, merge or deployment.

Acceptance authority:
Only the named human approver may accept factual accuracy. Repository
maintainer approval remains required for merge.

SRC-01
Title: Authentication service behaviour specification
Owner: Hypothetical product team
Version: 3.2, approved 2026-09-28
Authorised location: packet attachment "auth-behaviour-v3.2.pdf"
Relevant section: 4.1 Session renewal
Supports: inactive sessions require sign-in again after 30 minutes
Does not support: browser-specific behaviour or security recommendations
Access classification: approved internal extract only

SRC-02
Title: Documentation style guide
Owner: Hypothetical documentation team
Version: 2.4, approved 2026-08-10
Authorised location: docs/style-guide.md
Relevant section: Terminology
Supports: use "sign in" as a verb; avoid "log-in" as a verb
Does not support: authentication product behaviour
Access classification: repository internal

CLM-01 — SOURCED — SRC-01
The guide's statement that an inactive session lasts 60 minutes conflicts
with the approved 30-minute specification.

CLM-02 — SOURCED — SRC-02
The phrase "log-in again" should be changed to "sign in again".

DEC-01 — OWNER DECISION
Change only the inaccurate sentence and the terminology in that sentence.
Do not rewrite the surrounding authentication guidance.

UNK-01 — UNRESOLVED
Whether translated copies repeat the same statement has not been checked.
Translations are outside this packet and must only be reported as follow-up.

Repository: hypothetical product documentation repository
Baseline: exact revision to be supplied and recorded by the owner

Writable after editing approval:
docs/account/session-timeouts.md

Read-only context:
docs/style-guide.md
AGENTS.md
docs/AGENTS.md, if present

Out of scope:
src/**
api-reference/**
generated/**
locales/**
package manifests and lockfiles

Expected new files:
None

Goal:
Prepare a minimal correction to the inactive-session sentence in
docs/account/session-timeouts.md.

Required meaning:
The sentence must say that an inactive session requires the user to sign in
again after 30 minutes.

Constraints:
- Use only SRC-01 for timeout behaviour.
- Apply SRC-02 terminology.
- Preserve the surrounding heading structure and examples.
- Do not add security advice or claims about browser behaviour.
- Do not change translations, generated files or application code.
- If the current file no longer contains the 60-minute statement, stop and
  report the mismatch rather than inserting a new sentence.

Planning response:
1. Confirm whether the target path exists.
2. Identify applicable AGENTS.md instructions.
3. Quote the current target sentence.
4. Propose the smallest textual change.
5. List the exact checks that would be run after approval.
6. Report conflicts or missing sources.
7. Make no file changes.

Editing response, only after a revised approval:
1. List changed files.
2. Return the diff.
3. Map the timeout change to SRC-01 and terminology change to SRC-02.
4. Record each requested check as run, failed, or not run.
5. Report out-of-scope occurrences without editing them.
6. Mark the result "awaiting human review".

CHK-01 Scope:
The diff contains only docs/account/session-timeouts.md.

CHK-02 Required text:
The obsolete "60 minutes" statement is absent from the writable file, and
the corrected sentence states "30 minutes".

CHK-03 Terminology:
The corrected sentence uses "sign in" as a verb.

CHK-04 Preservation:
No heading, code example, link target or unrelated paragraph changes.

CHK-05 Repository checks:
Use only documentation validation commands confirmed by the repository's
authorised instructions. Record exact commands and status; never claim a
command ran if it did not.

CHK-06 Human factual review:
The authentication feature owner compares the changed sentence with SRC-01.

CHK-07 Human editorial review:
The documentation maintainer reviews clarity, grammar and scope.

Acceptance:
All mechanical checks must be accounted for, and both named human reviews
must approve. A generated patch alone is not acceptance.

Before merge:
Discard the proposed patch if either human reviewer rejects it.

After merge:
Use the repository's approved revert procedure against the recorded accepted
revision. Do not invent or execute a rollback command from this packet.

Retain:
Packet revision, reviewed diff, check record, reviewer decisions and reason
for rollback.

Stop conditions:
- SRC-01 is unavailable or differs from the registered version.
- The repository baseline is not the owner-supplied revision.
- Applicable repository instructions conflict with this packet.
- The correction requires a code, generated-file or translation change.

How the example moves from plan to edit

First, the owner supplies the packet and authorised materials without secrets or unnecessary personal data. The destination is asked only to inspect the named context and return the planning response. If it discovers that the current page already says 30 minutes, the correct outcome is a stop report, not an unnecessary rewrite.

Second, the owner compares the proposed plan with the packet. If the plan names additional files, the owner either rejects that expansion or creates revision 1.1 with a reason and new checks. Approval should never be inferred from silence.

Third, once the plan is satisfactory, the owner changes the status to approved for editing, records the approved plan and resubmits the complete packet revision. Supplying only “go ahead” risks losing the controlling context in a new session or surface.

Fourth, the destination returns the diff and check record. A command that could not run remains not run; it is not converted into an assumed pass. A human then inspects the diff and source mapping. The feature owner confirms the timeout fact, while the documentation maintainer confirms style and scope.

Finally, acceptance is recorded against the packet revision and repository baseline. If the patch is rejected, the reason becomes part of the continuity record. This helps a later handoff distinguish a technically incomplete attempt from a deliberate editorial decision.

Use the packet as the authority, not the preceding conversation

When handing off, introduce the packet with a concise instruction: the packet is the controlling brief; earlier conversation is background only; conflicts must be reported; unresolved facts must not be invented; and action is limited to the charter’s current status. This avoids copying an entire transcript whose abandoned ideas and corrections may obscure the final requirements.

Retain only relevant provenance. Record the origin surface, date, packet revision, authorised sources and visible model label if one is shown. Do not claim that the label caused a particular result, and do not require the destination to reproduce the original wording. The acceptance target is the packet’s observable contract.

A packet is ready for handoff only when a reviewer can answer all of these questions without reopening the original chat:

• What outcome is required, and who owns it?
• Which sources are authoritative, and which versions apply?
• Which statements are sourced, decided or unresolved?
• What may the destination read, change, run and return?
• What is expressly excluded?
• Which files or materials define the working scope?
• What evidence must accompany the result?
• Which checks are mechanical, and which require human judgement?
• Who can accept the result?
• What stops the task, and how can an unaccepted change be discarded or reverted?

If any answer depends on “the model should remember”, the handoff is not ready. Resolve the omission in the packet, or mark it as an uncertainty that blocks action. That rule remains useful whether the change is caused by a hidden ChatGPT fallback, a scheduled model retirement, an account entitlement change or an ordinary move from conversation to repository work.

Collect and sanitise the material before handing it over

A task packet should contain the minimum approved material needed to complete and review the task. It should not be an unfiltered transcript. A transcript mixes instructions, tentative ideas, model-generated claims, copied source text and superseded decisions without reliably distinguishing them. Instead, collect each input deliberately, assign it a status and remove anything the destination does not need.

This manual step matters because product surfaces do not imply context transfer. According to OpenAI’s ChatGPT Work and Codex documentation, accessed on 1 October 2026, Chat and Work chats can appear together in Recents, while Codex has a separate view and separate history. That documentation does not establish automatic transfer of a Chat conversation, attachments, permissions or source context into Codex. Treat the destination as if it knows nothing except the packet, the files explicitly supplied to it and any applicable repository instructions.

The decision rule is simple: if omitting an item would prevent the worker from understanding the goal, respecting a boundary or verifying the result, include a reviewed version of it. If an item is merely conversational history, duplicated background or an unsupported suggestion, leave it out or record it as an unresolved note.

Use a controlled intake folder

Create a temporary, access-controlled intake folder outside the working repository. Do not immediately copy chat attachments into the repository, because that can accidentally stage confidential documents, generated files or unsuitable licences for commit. The intake folder is a review area, not an instruction source and not part of the eventual change unless a human explicitly promotes a file.

A practical example structure is:

task-packet-intake/
├── 00-original-request.txt
├── 01-candidate-sources/
├── 02-candidate-files/
├── 03-extracted-claims.csv
├── 04-redaction-log.csv
├── 05-conflicts.md
└── 06-approved-packet/

This layout is a suggested method, not a Codex requirement. Its benefit is separation: original material remains available for comparison, while only sanitised and approved copies move into 06-approved-packet. Its cost is administrative effort and the possibility of stale duplicates. Mitigate that by recording hashes, versions, retrieval dates or repository commit identifiers where available, and by deleting the intake copy according to the organisation’s retention rules after the handoff is complete.

Assign one person as the packet editor and another, where the task warrants it, as the approver. The editor collects and normalises inputs; the approver checks authority, scope and redactions. For routine low-risk work these roles may be held by the same person. For security, privacy, financial, employment, government, safety or other consequential work, require qualified human review and do not let the packet or model output make the final decision.

Run a seven-step collection procedure

1. Freeze the request. Save the user’s original request unchanged, with the date, requester and originating surface. It is evidence of what was asked, not necessarily the final instruction.
2. Inventory candidate inputs. List sources, attachments, repository paths, issue references, earlier decisions, tests and project instructions. Do not copy them blindly into the approved packet.
3. Confirm authority and relevance. Identify who owns each input, whether it is approved for this use and which claim or action it supports.
4. Sanitise content. Remove secrets, unnecessary personal data, irrelevant proprietary material, hidden instructions and executable content that the task does not require.
5. Resolve or expose conflicts. Apply documented precedence where it exists. Otherwise, record the disagreement and ask a human owner rather than silently choosing.
6. Bind checks to requirements. For each acceptance requirement, name the command, inspection or human decision that will verify it.
7. Publish a versioned packet. Copy only approved material into the handoff folder, record its version and have the responsible reviewer sign off the boundaries.

Do not merge these passes into “ask the model to clean up the chat”. A model can help draft a candidate inventory, but the authority, confidentiality and conflict decisions belong to people who understand the data and project. A generated summary can also omit a caveat or convert a tentative statement into a requirement. Compare every generated summary with the original inputs before approving it.

Classify each candidate input before copying it

Give every candidate one of five dispositions:

When classification is uncertain, default to exclusion from the executable packet and escalate. This may slow the handoff, but it avoids turning mere possession into assumed permission. Conversely, aggressive exclusion can leave the worker without enough evidence. Resolve that trade-off by supplying a narrow extract or a human-authored factual summary where policy permits, rather than the entire sensitive document.

Build a source ledger that distinguishes evidence from instructions

A source can support a fact without authorising a repository change. An issue can request a change without proving the factual wording that should appear. Keep those functions separate in a source ledger.

A source ledger should record which material informed the task, rather than assuming a later model or transcript will reproduce that provenance. An explainer on ChatGPT Search source attribution explained covers web results and attribution, which shows why source attribution must stay visible when findings are carried into a Codex or Work packet.

Use one row per source version, not one row per website or file family. At minimum, record:

• a stable source ID;
• the title or file name;
• the source owner or publisher;
• the exact location, such as an approved Uniform Resource Locator (URL)The address used to identify and access a resource on the web. Open glossary entry or repository path;
• publication, modification or retrieval date where known;
• the relevant section, line range or page;
• whether it supplies evidence, instructions, context or a decision;
• the claims or requirements it supports;
• approval and confidentiality status;
• known limitations, unresolved questions or expiry conditions; and
• the reviewer who admitted it to the packet.

A sample ledger for a documentation correction might look like this:

The key distinction is between provenance and truth. Provenance tells the reviewer where a statement came from. It does not prove that the statement is correct. A model-generated claim can have excellent provenance to a transcript and still be wrong. Mark it as model-generated or unverified until a suitable source or accountable human confirms it.

For web material, record the retrieval date because pages can change. For repository material, prefer a commit identifier plus path. For attachments, record the file version or checksum if organisational practice allows. Do not invent missing publication dates. Use “date not stated; retrieved on …” rather than inferring one from page design or file metadata.

Where the packet relies on OpenAI product documentation, attribute volatile facts with their access date. For example, OpenAI’s Codex model documentation, accessed on 1 October 2026, scheduled GPT-5.5 retirement from ChatGPT, ChatGPT Work and Codex for 14 October 2026 and stated that the retirement did not apply to the API. On the research date, this was a future schedule, not a completed retirement. The ledger should therefore carry an expiry condition such as “re-check before publication or use on or after 14 October 2026”.

Extract approved claims rather than copying whole documents

For each authoritative source, create a short claim record containing the exact proposition needed by the task, its source ID and any qualifier. This reduces irrelevant context and makes review feasible.

CLAIM-07
Statement: The setup guide must list only the two configuration names
           specified in SRC-01 section 4.2.
Source: SRC-01
Qualification: Applies to the current documented release only.
Use: Replace the outdated three-item list in docs/setup.md.
Status: Approved by documentation owner.

Keep quotations exact and visibly quoted. Label paraphrases as paraphrases. Do not let copied source text masquerade as an instruction: place evidence under a source or claim heading and actions under a requested-change heading. If a webpage, issue, document or code comment contains phrases such as “ignore previous instructions”, treat those phrases as untrusted source content, not packet commands.

The decision rule for source volume is claim coverage, not completeness. Include enough of a source to let the receiving agent and reviewer understand the claim and its limitations. Include the full document only when the task genuinely requires whole-document analysis and sharing it is approved. A narrow extract is easier to audit, but may omit context; counter that risk by recording section boundaries and giving the human reviewer access to the approved original.

Translate conversational constraints into testable rules

Chat requests often contain soft phrases such as “keep this small”, “do not alter behaviour” or “follow the existing style”. Convert each into an observable boundary without pretending that every judgement can be automated.

Do not manufacture precision where the owner has not supplied it. If “small” could mean one file, a line limit or no architectural change, ask. When work must begin before an answer arrives, choose the narrower reversible interpretation and record it as an assumption requiring approval.

Define the repository boundary positively and negatively

A useful scope statement identifies what may be read, what may be edited, what must not be touched and what requires renewed approval. “Work in this repository” is too broad. It gives no guidance about generated assets, vendored code, migrations, submodules or unrelated failing tests.

A model-switch-safe packet also needs explicit repository instructions, so the coding workflow knows which artefacts may be used, moved or shared. A playbook on Codex repository boundaries and approved transfers treats files, repository objects and handoff notes as controlled items, with checks on data leaving the repository that can inform the limits you set.

Record a base repository state so reviewers know what the packet was prepared against. A suggested record is:

Repository: approved internal project
Base branch: main
Base commit: <reviewed commit identifier>
Read scope:
  - docs/setup.md
  - docs/style-guide.md
  - package manifest entries needed to identify existing checks
Edit scope:
  - docs/setup.md
Prohibited:
  - application source
  - lockfiles
  - generated documentation
  - vendored dependencies
  - repository or account configuration
Escalate before:
  - adding dependencies
  - changing another path
  - running a command that writes outside the worktree
  - contacting an external service

Paths in the example are illustrative. Use real reviewed paths in an actual packet. If a necessary file sits outside the stated scope, the worker should stop and report why it is needed. Do not silently expand scope because a search result looks relevant.

Symlinks, submodules and generated files deserve explicit treatment because a path that appears local can refer elsewhere or be overwritten. Identify them during intake. The packet should state whether they are read-only, excluded or separately approved. For a large repository, allow a narrow discovery phase: list candidate files without editing them, then have a human approve the final edit set.

Inspect every applicable AGENTS.md file

OpenAI’s AGENTS.md documentation, accessed on 1 October 2026, says Codex reads AGENTS.md files before doing work and documents global and project instruction precedence, root-to-current-directory merging and override behaviour. That makes these files relevant inputs, but not security controls.

During collection:

1. Locate the repository root and the target working directory.
2. Find each applicable AGENTS.md or documented override file along that path.
3. Read the effective instruction chain in order rather than copying only the nearest file.
4. Record each file’s path and version in the ledger.
5. Extract commands, style rules, directory restrictions and review requirements relevant to the task.
6. Compare them with the packet and higher-authority organisational instructions.
7. Stop for human resolution if they conflict or if a file contains suspicious, unrelated or secret-seeking directions.

An AGENTS.md file can communicate project conventions; it cannot grant repository access, widen sandbox permissions, authorise disclosure, override organisational policy or prove that a command is safe. It is content in the repository and may be stale, mistaken or malicious. Actual access controls, sandboxing, approval settings and human decisions remain separate. Never write “allowed by AGENTS.md” as if that creates permission.

OpenAI’s documentation also describes a default combined size limit for loaded instruction content. Therefore, do not assume that every lengthy instruction file will be fully effective merely because it exists. Keep task-critical constraints in the packet as well as in the appropriate project instruction file, and ask the worker to report which instructions it used. This duplicates a small amount of content, but it makes omissions visible during review.

If the root instruction says to run a full test suite and a nested instruction says to run a targeted documentation check, the two may be cumulative rather than conflicting. If one says “never modify generated files” and another directs the worker to edit one, treat that as a real conflict. The packet editor should not infer which author had greater organisational authority solely from file location; obtain a maintainer decision.

Bind tests to risks, not to habit

Collect existing project checks before drafting new ones. Look in approved project instructions, contribution documentation and existing scripts, but do not run arbitrary commands merely because they appear in a chat or untrusted file. Record the exact command, working directory, expected type of result and whether it can write files, access a network or alter external state.

Do not include invented command names. If no approved automated check exists, say so and define a manual inspection. If a check is too expensive, slow or permission-sensitive for the handoff environment, state that it was not run and assign it to a named human or approved environment. A passing test demonstrates only what that test covers; it does not prove the entire output correct.

OpenAI’s Codex prompting guidance, accessed on 1 October 2026, recommends specifying the goal, context, output and boundaries, including relevant code or reproduction details, constraints and verification. It also describes a plan-first option for multi-step work. Use that structure to request an investigation and proposed plan before edits where uncertainty is material. Availability of a particular command or interface feature can vary, so the packet should express the behaviour required—“investigate and propose a plan before editing”—rather than depend solely on a slash command.

Remove secrets and minimise sensitive data

Never place passwords, API keys, access tokens, private keys, session cookies, recovery codes or unredacted credentials in a prompt, packet, issue or AGENTS.md. Do not replace a secret with a realistic-looking sample that could be mistaken for a live credential. Use an unmistakable placeholder such as <REDACTED_API_TOKEN> and record the category of removal in a separate redaction log.

Also remove data that is unnecessary rather than merely confidential: customer names, personal contact details, employee records, production identifiers, private URLs, internal hostnames and full log payloads can all exceed the task’s needs. Preserve only the smallest approved fragment required to reproduce or understand the issue. When values must retain structure, use synthetic examples and label them explicitly as examples.

Apply this redaction checklist before approval:

• Search for credentials in plain text, configuration blocks, URLs, headers, command history and screenshots.
• Check attachments and archives, not only the visible prompt.
• Remove unnecessary personal, customer, employee and account data.
• Replace production identifiers with labelled synthetic values where structure matters.
• Strip document comments, tracked changes and metadata if they are not required and policy permits.
• Remove unrelated proprietary source code and internal documents.
• Check copied terminal output for home paths, usernames, hostnames and tokens.
• Review images for visible secrets and embedded metadata.
• Confirm that redaction has not removed a condition needed to interpret the evidence.
• Have an authorised human perform a final inspection before upload or submission.

Keep the redaction log non-sensitive. It might state “one bearer token removed from request header” without retaining the token. If a secret has already been exposed to a chat or unapproved location, removing it from the packet is not remediation. Follow the organisation’s credential-revocation and incident process, with qualified human oversight.

Record permission limits as actions, not assurances

Write permission boundaries in operational language:

May:
- read the approved paths;
- propose a patch;
- run the listed read-only or local validation commands.

Must ask before:
- writing outside the edit scope;
- installing software or dependencies;
- using network access;
- changing configuration;
- executing migrations;
- creating commits, branches or pull requests;
- contacting external systems.

Must not:
- request, reveal or store credentials;
- access production data;
- change account, workspace or security settings;
- make consequential decisions on a person's behalf.

These statements communicate intent but do not enforce it. Enforcement depends on the actual environment, account controls and human approvals. Verify those controls separately. A model default in configuration also does not create entitlement or override workspace policy; OpenAI’s documentation says visibility can depend on plan, client, rollout, workspace settings, role and administrator controls.

Maintain a conflict register

Conflicts are expected when a task comes from a long conversation. Record them rather than blending them into a plausible compromise.

Use explicit precedence only where authority is documented. Legal and organisational policy outrank a task request; approved project instructions govern repository conventions within their legitimate scope; the current task packet governs this handoff; source documents support facts but do not automatically issue commands. Where two inputs at the same level disagree, stop and escalate. Never ask the model to choose which human authority “sounds more reasonable”.

Worked example: turn a mixed chat into an approved packet

Assume a Chat conversation contains this request: “Update the setup page to show the supported connection modes. The issue says there are three. Keep the change small, run the usual checks, and use this diagnostic log.” The conversation also includes a pasted log with a bearer token, a model-generated assertion that all three modes are supported and an attachment containing an approved specification that lists only two.

Step 1: preserve the original. The editor stores the request unchanged in the intake folder and records its date, requester and originating Chat conversation. The original is not sent onward because it contains a secret and ambiguous instructions.

Step 2: inventory the inputs. The editor identifies the issue, specification, current setup page, applicable repository instructions, diagnostic log, model assertion and existing validation documentation. Each receives a candidate ID.

Step 3: classify authority. The specification is the factual authority for supported modes. The issue authorises investigation but conflicts with that specification. The current page describes repository state. The model assertion is unverified context. The log may help diagnose the discrepancy but does not establish supported product behaviour.

Step 4: sanitise. The bearer token and unrelated account identifiers are removed. Only the two relevant diagnostic lines are retained if the owner approves their use. The redaction log says what categories were removed but stores no secret values. The exposed token is reported through the organisation’s human-led security process.

Step 5: inspect repository instructions. The editor finds a root AGENTS.md requiring British English and a nested documentation instruction prohibiting direct edits to generated reference pages. The target setup page is confirmed as hand-maintained. These instructions are recorded as conventions, not permissions.

Step 6: resolve the contradiction. Because the issue says three modes and the approved specification says two, the editor asks the product owner. Suppose the owner confirms that the issue is stale and approves the two-mode wording. This is a hypothetical decision for the example, not a reported product result. The editor records the owner, date and rationale rather than silently deleting the conflict.

Step 7: define narrow scope and checks. Only docs/setup.md may be edited. The worker may read the style guide and relevant test configuration. It may not change code, generated pages or dependencies. It must run the existing approved documentation check, inspect the changed-path list and return a source-to-claim comparison for human review.

The resulting execution packet could contain:

Packet: DOC-418
Version: 1.0
Base state: reviewed repository commit <identifier>

Goal
Correct the supported connection-mode list in docs/setup.md.

Authoritative evidence
SRC-01, approved specification revision 8, section 4.2:
lists Mode Alpha and Mode Beta only.

Decision
DEC-01: Product owner confirmed that issue 418's reference to a
third mode is stale. Use SRC-01. Recorded on <date>.

Context
The original Chat discussion and diagnostic extract are contextual,
not factual authorities.

Edit boundary
May edit: docs/setup.md
May read: docs/style-guide.md and files needed to identify the
approved documentation check
Must not edit: source code, generated files, dependencies,
configuration or unrelated documentation

Instructions
Preserve the surrounding heading structure, British spelling and
inline-code style. Investigate and present a short plan before editing.
Report related problems; do not fix them without approval.

Checks
1. Run the existing named documentation check from the documented
   working directory.
2. Capture the command, exit status and relevant output.
3. Show the complete diff and changed-path list.
4. Map each changed factual statement to SRC-01.
5. Obtain documentation-owner acceptance before merge.

Permissions
No network access, dependency installation, external service calls,
credential use, commits or pull requests without separate approval.

Unknowns
None currently blocking. Stop if another file must change or if the
approved check requires an unapproved action.

Output
Plan, proposed patch, command record, diff summary, unresolved
findings and human-review checklist.

The following items are deliberately not transferred: the full chat, the live credential, the unsupported three-mode claim, irrelevant logs and an assumption that “usual checks” had a shared meaning. The packet replaces each with a reviewed source, explicit boundary or named verification step.

Perform a final admission review

Before submitting the packet to Work or Codex, a human reviewer should answer all of the following:

• Can every factual requirement be traced to an approved source or accountable decision?
• Are source dates, versions and limitations visible?
• Are unverified model statements labelled or removed?
• Does the packet distinguish evidence, instructions, context and unresolved questions?
• Are read, edit and prohibited repository paths explicit?
• Have applicable AGENTS.md files been inspected without treating them as security boundaries?
• Are commands named, scoped and assessed for side effects?
• Are secrets and unnecessary sensitive data absent from prompts and attachments?
• Are permission limits consistent with the actual environment and account controls?
• Have conflicts been resolved by an authorised person or left visibly blocking?
• Does each acceptance requirement have automated evidence, human inspection or both?
• Is qualified human review mandatory for any security, privacy, financial, employment, government or otherwise consequential decision?

If any answer is “unknown”, do not disguise that uncertainty with confident wording. Add it to the packet’s unresolved list, assign an owner and decide whether work can safely continue. Proceed only when the unknown is non-blocking and the packet states the conservative behaviour to follow. The completed packet is a controlled handoff record, not a guarantee that a different model, surface or run will produce an equivalent or correct result.

Start Codex from an explicit handoff, not an assumed transfer

OpenAI’s ChatGPT Work and Codex documentation, accessed 1 October 2026, distinguishes Chat as conversational assistance, Work as longer multi-step work, and Codex as software-development and technical work. It also states that Codex has a separate view and separate history from ChatGPT history. Treat that separation as an operational boundary: manually provide everything Codex needs to understand, inspect and verify the task.

Do not assume that opening Codex transfers the originating chat, attachments, cited sources, chosen ChatGPT model, tool state, account permissions or earlier decisions. The official documentation does not establish such an automatic transfer. Model visibility may also depend on plan, client, rollout, workspace settings, role and administrator controls. A default model named in configuration does not grant access to it.

The decision rule is simple: if an input would change the implementation or its acceptance, it must appear in the packet or in an explicitly referenced repository file. If it is absent, Codex should treat it as unavailable rather than reconstructing it from presumed history.

Create a clean Codex intake bundle

Place the approved packet in a stable repository location such as handoff/tasks/docs-link-fix/, or paste it into the task when repository policy does not permit handoff files. A practical bundle can contain:

• task.md: goal, context, required output and boundaries;
• sources.md: source IDs, approved locations, retrieval dates and permitted claims;
• decisions.md: settled choices and unresolved questions;
• acceptance.md: named checks and human acceptance criteria;
• inputs/: only authorised, sanitised source extracts that genuinely need to be local;
• evidence/: proposed diffs, command output and reviewer notes produced during the task.

This layout is a suggested method, not a Codex requirement or a guarantee of correctness. Use the repository’s existing conventions where they are clearer. Avoid duplicating authoritative project instructions: if build commands belong in AGENTS.md or a contributor guide, reference that file and record its revision rather than maintaining a conflicting copy.

Before submission, assign a packet version and immutable baseline. For example:

Packet: docs-link-fix
Packet version: 1.2
Repository baseline: <reviewed commit identifier>
Task root: docs/
Permitted writes:
  - docs/setup.md
  - tests/links/fixtures/setup-links.txt
Read-only context:
  - AGENTS.md
  - docs/AGENTS.md
  - scripts/check-links.sh
Excluded:
  - application source
  - deployment configuration
  - dependency files
  - generated site output

The commit identifier must be copied from the actual repository; the placeholder above is not evidence. If no stable baseline is available, stop and ask the owner whether to create one or to record the current working-tree state. Do not silently proceed against an unknown mixture of changes.

Re-state the separate history in the first instruction

The opening instruction should make the context boundary explicit. This avoids a misleading exchange in which phrases such as “continue the change we discussed” appear to supply context but do not identify any transferable material.

This is a manual handoff from a separate ChatGPT conversation.
Do not assume access to that conversation, its attachments, its model,
its tools, its permissions or any decision not reproduced below.

Treat packet version 1.2 and the repository instructions in scope as
the task authority. If they conflict, identify the conflict and stop
before editing. Do not infer missing source facts.

That wording does not claim Codex lacks every possible integration in every account. It records the conservative operating assumption required by the documented separation of Codex history. Current account behaviour can vary by plan, rollout, client and administrator settings, so inspect the actual product surface before beginning.

Use a fresh task when the old Codex history contains materially different constraints or an obsolete packet. Continue an existing Codex task only when its recorded baseline, packet version and permitted files still match. The trade-off is continuity versus contamination: an old thread may preserve useful implementation discussion, but it may also preserve superseded assumptions. When in doubt, start clean and link the reviewed records explicitly.

After preserving sources and limits, the packet must state the intended result clearly enough for the receiving workflow to act on it. For shaping that request, the outcome-first GPT-5.5 prompting method for GPT-5.5 and GPT-5.5 Mini offers a reasoning-effort guide and a checklist, which can help word the task more precisely.

Request investigation and a plan before any edit

OpenAI’s Codex prompting guidance, accessed 1 October 2026, recommends stating the goal, context, expected output and boundaries. It also describes the /plan slash command for multi-step work so Codex can investigate and propose an approach before editing. Slash-command availability can depend on the current surface, so the portable requirement is “plan before edit”, not dependence on one interface command.

Submit the packet in two phases. In phase one, permit inspection but no writes. Ask Codex to report its understanding in a fixed structure:

1. the requested outcome in one sentence;
2. the packet version and repository baseline it found;
3. the applicable instruction files, including each relevant AGENTS.md;
4. the files it proposes to read and why;
5. the exact files it proposes to modify;
6. the source ID supporting each factual change;
7. the named checks it proposes to run;
8. conflicts, missing inputs and unresolved questions;
9. actions that would require approval or exceed the packet.

OpenAI documents that Codex reads AGENTS.md files before doing work and applies project instructions according to location and precedence. Nevertheless, require the plan to name the instruction files it used. This gives the reviewer a visible basis for detecting an unexpected nested override or an instruction file outside the intended task root. An AGENTS.md file is guidance, not a security boundary; file scope and review controls remain necessary.

A suitable plan-only request could be:

PHASE: investigation and plan only; make no edits.

Goal:
Correct the obsolete documentation link identified in approved claim C-04.

Authority:
- handoff/tasks/docs-link-fix/task.md, packet version 1.2
- handoff/tasks/docs-link-fix/sources.md
- repository instructions applicable to docs/setup.md

Boundaries:
- Read only the packet, applicable instruction files, docs/setup.md,
  tests/links/fixtures/setup-links.txt and scripts/check-links.sh.
- Propose writes only to the two paths listed as permitted writes.
- Do not browse for substitute sources.
- Do not install packages, alter configuration, use credentials,
  publish, deploy, commit or push.
- Treat absent source text as missing; do not invent it.

Return:
1. Restated goal and baseline
2. Applicable instructions
3. Proposed file-level changes
4. Source-to-change mapping
5. Verification commands
6. Missing data, conflicts and approval requests

Wait for human approval before editing.

This is an example instruction, not evidence that the product was run or that the proposed change succeeds. Adapt commands and paths to the actual repository. The decision rule is to reject the plan if it names an unapproved write path, cannot map a factual edit to an approved source, or substitutes a generic check for a named repository check without explaining why.

Review the plan as an acceptance gate

Do not approve a plan merely because it sounds plausible. Compare it mechanically with the packet:

Review item	Accept when	Reject or clarify when
Baseline	The reported revision and working-tree state match the approved handoff.	The revision differs, is omitted or includes unexplained local changes.
Instruction chain	Applicable root and nested instructions are identified without unresolved conflict.	An instruction is missing, contradictory or outside the owner’s reviewed set.
Write set	Every proposed write is explicitly permitted and necessary.	A generated file, lockfile, configuration file or unrelated source file appears.
Evidence	Each factual change maps to a source ID or is clearly labelled editorial wording.	The plan proposes web knowledge, memory or an uncited inference as authority.
Verification	Commands are present in the repository or supplied by an authorised owner.	A command is guessed, would install or mutate unexpectedly, or lacks relevance.
Permissions	Proposed actions fit the allowed read, write and execution boundaries.	The plan requires network access, credentials, publication or broader privileges.

If one row fails, return a targeted correction rather than approving “with reservations”. For example: Revise the plan to exclude package-lock.json; no dependency change is authorised. Use source S-02 for the destination URL, or mark the URL unavailable. Approval applies only to the revised plan and named baseline.

Constrain repository access at file and action level

A broad instruction such as “only change what is necessary” is subjective. Express scope as an allow-list of files and actions, backed by an exclusion list. Separate reading from writing: Codex may need to read a script to learn a validation command without being allowed to edit that script.

Use four categories:

1. Required reads: packet files, target files and applicable repository instructions.
2. Optional reads: narrowly identified files that may resolve implementation questions.
3. Permitted writes: an exact path list or a tightly bounded directory and file pattern.
4. Forbidden actions: package installation, dependency upgrades, credential access, network retrieval, commits, pushes, deployment or deletion unless separately approved.

For example, allowing writes to docs/** is convenient but permits a larger change than two named documentation files. Named paths produce stronger reviewability but require another approval if a test fixture legitimately needs adjustment. Choose the directory pattern only when the task genuinely spans an unpredictable set of files and the reviewer can inspect the wider diff.

Do not place secrets, access tokens, private keys, personal data or unnecessary proprietary material in the prompt or packet. If the task requires protected information, use an approved access mechanism and minimise exposure; do not paste the secret itself. If Codex reports that a credential is required, stop and escalate rather than supplying it conversationally.

Local execution controls and approvals can limit actions, but they do not turn task instructions into an enforceable security policy or eliminate human review. For security, privacy, financial, employment, government and other consequential decisions, a qualified human must review the inputs, proposed actions, evidence and final result before use. Codex should produce review material, not make the final consequential decision.

Freeze unrelated working-tree changes

Before editing, inspect the working tree with the repository’s normal status command. If unrelated changes exist, choose one of three paths:

• use a clean branch or worktree prepared by the owner;
• record the pre-existing paths and prohibit touching them;
• pause until the owner resolves them.

Do not ask Codex to discard, reset, stash or overwrite work unless the owner explicitly authorises that operation and understands its effect. The decision rule is that ambiguous ownership blocks destructive cleanup. Preserving someone else’s work is more important than obtaining a tidy diff.

If the packet baseline is clean but the current checkout is not, the plan must identify the discrepancy. An acceptable note might say: Baseline mismatch: docs/setup.md already differs from the packet’s recorded revision; no edit proposed until the owner confirms which version governs. That is useful output even though no implementation occurred.

Issue a bounded edit authorisation

After approving the plan, provide a second instruction that references the approved version rather than restating it loosely. This preserves the review trail:

Authorise implementation of plan revision P2 against the confirmed
repository baseline.

Permitted writes:
- docs/setup.md
- tests/links/fixtures/setup-links.txt

Do not alter any other path. If another file appears necessary, stop
and request a scope amendment before writing it.

Use only packet sources S-01 and S-02 for factual content. Preserve
the surrounding meaning and make the smallest change that satisfies
acceptance rules A-01 to A-04.

After editing:
- show the proposed diff;
- run only the approved named checks;
- report each command exactly, with exit status and relevant output;
- list checks not run and why;
- do not commit, push, publish or deploy;
- wait for human review.

“Smallest change” means the least scope that meets the acceptance criteria, not the fewest characters. A one-line substitution that breaks surrounding instructions is not preferable to a slightly larger coherent edit. Conversely, opportunistic rewriting, formatting or dependency updates should be excluded unless the packet requests them.

If the task evolves during implementation, version the amendment. For example, add Scope amendment 1.3: permit one write to tests/links/fixtures/setup-links.txt because A-03 requires fixture alignment. Record who approved it and when. Do not let an informal message such as “sure, fix that too” become an untraceable expansion.

Inspect the diff before treating command output as evidence

Tests answer only the questions they are designed to check. Review the proposed diff first, because an irrelevant or harmful change can still leave a narrow command passing. Ask for a path-limited diff and a concise explanation of every changed hunk.

The reviewer should verify:

• only permitted files changed;
• no approved source was silently rewritten or reinterpreted;
• new factual wording maps to a source ID;
• unknowns remain labelled rather than being filled by inference;
• formatting churn does not obscure the substantive edit;
• generated files were not hand-edited unless the repository requires it;
• no credential, personal information or private source text appears in the diff;
• the change remains reversible without destroying unrelated work.

For the hypothetical documentation correction, a proposed diff may replace one obsolete destination and update its fixture. That is an example of intended scope, not a report of an actual run. If the diff also rewrites the whole page, reject it and request a narrower patch even if the prose seems improved.

Require machine-readable and human-readable reports

A compact evidence table makes omissions visible:

Check ID	Command or review	Status	Evidence location	Limit
A-01	Human comparison with source S-02	Pending	evidence/review.md	Requires authorised reviewer
A-02	./scripts/check-links.sh docs/setup.md	Not yet run	evidence/check-links.txt	Run only if the script exists and instructions approve it
A-03	Path-scope diff review	Pending	evidence/diff.patch	Does not establish factual accuracy

These statuses are illustrative placeholders, not results. Never pre-fill passed in a reusable template. Record the exact command, execution location, exit status and relevant output after execution. A summary such as “all tests pass” is insufficient because it hides what ran.

Run named checks only when their provenance is known

Use checks named by repository instructions, package scripts, maintained documentation or the approved packet. Confirm the command exists before running it. Do not invent a plausible command and later present its output as the project’s accepted validation.

Apply this sequence:

1. Locate the named command in an approved repository file.
2. Read enough of the script or configuration to identify side effects and prerequisites.
3. Confirm that execution is within the packet’s permission boundary.
4. Run the narrowest relevant check first.
5. Capture the exact invocation, working directory, exit status and relevant standard output or error output.
6. Run broader checks only when required or separately approved.
7. Report skipped, blocked and unavailable checks distinctly.

The distinction between failed, blocked and not available matters. A failed check ran and reported a problem. A blocked check could not run because an approved prerequisite or permission was absent. A check is unavailable when the named command or test does not exist at the reviewed baseline. None of those states should be rewritten as success.

If a script attempts package installation, network access, writing outside the allowed paths or another unapproved action, stop it where safely possible and report the behaviour. Do not broaden permissions just to complete the checklist. The trade-off is evidence completeness versus boundary integrity; an honestly blocked check is preferable to an unauthorised run.

Do not confuse exit status with acceptance

An exit status of zero is evidence about that command’s own conditions, not proof that the task is correct. For the example link correction, a link checker may establish that a destination responds or matches a fixture, but it may not establish that the destination is the authoritative source intended by S-02. Human source comparison remains necessary.

Conversely, a non-zero result may reveal a pre-existing failure unrelated to the patch. Compare against the recorded baseline only if the owner authorises a baseline run and the environment is comparable. Do not claim that a failure is pre-existing merely because it appears unrelated; record the observation and ask the owner to classify it.

A handoff stays reviewable only when the packet defines how a person will judge whether the finished work meets the request. A set of agent workflow acceptance-test prompts for designing and evaluating Agents API workflows, including recovery, may help you frame those criteria before work moves from ChatGPT to Codex.

Handle missing source data without filling the gap

A source-dependent task must fail visibly when its authority is absent. Codex should not browse for a replacement, rely on model memory or convert an inference into a fact unless the packet explicitly authorises source discovery and defines how a human will approve additions. For this workflow, the safer default is to stop the affected change.

Use a missing-data report with five fields:

Missing item: S-02 approved destination
Needed for: C-04 factual link replacement
Observed state: source register names S-02, but no URL or authorised extract is present
Impact: cannot determine the replacement destination
Safe partial work: inspect formatting and identify the exact target line; no edit
Required owner action: supply or approve S-02 and issue a packet revision

This sample is an example output, not a product guarantee. It demonstrates the distinction between useful investigation and unauthorised completion. Codex may identify where a missing fact belongs while leaving the fact unchanged.

If the source exists but cannot be accessed, record whether the cause is a missing attachment, unsupported format, permission denial, broken reference or redaction. Do not ask for credentials in the prompt. The owner should either provide an authorised extract, grant access through an approved mechanism, replace the source with an approved equivalent, or narrow the task.

Resolve source conflicts through escalation

When two supplied sources disagree, apply the packet’s precedence rule rather than choosing whichever appears newer or more convenient. If no precedence rule exists, report:

• the conflicting source IDs;
• the exact propositions that conflict;
• the files and acceptance rules affected;
• whether a non-factual partial change remains possible;
• the decision required from the named owner.

A retrieval date alone does not establish authority. A newer secondary note may be less authoritative than an older normative specification. The human owner must decide according to the project’s source policy and record the resolution in a new packet version.

Produce a review bundle, not a completion assertion

At the end of the authorised work, ask Codex for a structured review bundle:

1. packet version, repository baseline and plan revision;
2. changed paths and one-sentence purpose for each;
3. source-to-diff mapping;
4. the complete proposed diff or its approved evidence-file location;
5. commands run, working directories, exit statuses and relevant output;
6. checks not run, with reasons;
7. new or unresolved risks and unknowns;
8. confirmation that no commit, push, publication or deployment occurred, if those actions were prohibited;
9. specific questions requiring human acceptance.

Do not accept done, fixed or verified without the corresponding evidence. Equally, do not require Codex to claim certainty it cannot establish. Prefer precise language such as the approved command returned exit status zero and factual alignment with S-02 remains pending human review.

Apply the final human gate

The reviewer should independently inspect the diff, source mappings and command evidence, then record one of four decisions:

• Accept: all mandatory checks and source reviews are complete.
• Accept with recorded limitation: only when the packet expressly allows that limitation and the owner understands its effect.
• Return for revision: the task remains in scope but the patch or evidence is deficient.
• Reject or re-scope: required authority, permissions or repository conditions are unavailable.

Acceptance should identify the reviewed packet and baseline. If either changes after review, the acceptance no longer automatically applies. Re-run only the checks affected by a change when the repository’s policy supports selective verification; otherwise run the complete required set. The trade-off is review effort against confidence, and that decision belongs to the responsible human, not to the model.

For security, privacy, money, employment, government services, health, legal matters and other consequential uses, require appropriately qualified human review before any decision or external action. The packet and Codex output can organise evidence, but they do not transfer accountability or establish that the result is safe, lawful or correct.

Worked execution example: stop safely when the authority is incomplete

Consider the earlier hypothetical documentation task. The packet permits edits to docs/setup.md and one link-test fixture. It identifies source S-02 as the authority for the replacement destination and names ./scripts/check-links.sh docs/setup.md as a candidate check, subject to repository confirmation.

During plan-only inspection, Codex finds the target line and the named script, but the supplied sources.md contains only the label S-02: current installation guide; it contains neither an approved location nor an authorised extract. A compliant proposed response would be:

Plan status: blocked before edit

Confirmed:
- Target text is in docs/setup.md.
- Applicable instructions are AGENTS.md and docs/AGENTS.md.
- The named link-check script exists; execution has not been authorised yet.
- No write has been made.

Missing authority:
- S-02 does not contain an approved destination or source extract.
- Therefore C-04 cannot be implemented without inferring a factual URL.

Proposed safe next step:
- Owner supplies S-02 in packet version 1.3.
- Re-check the revised source register.
- Submit a revised file-level plan before editing.

This is a hypothetical sample, not a report that Codex was tested or produced this response. Its value lies in the decision logic: absent source authority blocks the factual edit, while bounded inspection can still identify the dependency.

Suppose the owner then adds an approved destination to S-02 and issues packet version 1.3. The next plan must cite 1.3; permission granted for 1.2 does not silently cover it. If the target file also changed in the meantime, recalculate the baseline and review the context before authorising a patch.

After an edit, the reviewer would expect a two-file maximum diff, the exact named check output if it was approved and run, and a human comparison against S-02. No result should be invented in the tutorial: the example ends with the evidence that would be required, not a claim that the command passed or the link was correct.

Close the Codex phase with a continuity record

Preserve the handoff state so another surface, model or reviewer can resume without relying on chat memory. Record:

• date and product surface;
• packet version and repository baseline;
• visible or selected model only if the interface actually showed it;
• approved plan revision and scope amendments;
• changed and untouched paths;
• source IDs used;
• checks run and their recorded outcomes;
• human acceptance status;
• unresolved questions and the next authorised action.

Model information is provenance, not proof of equivalent behaviour. OpenAI’s documentation accessed 1 October 2026 scheduled GPT-5.5 retirement from ChatGPT, ChatGPT Work and Codex for 14 October 2026, while stating that this retirement did not apply to the API. Availability in Work or Codex can depend on plan, client, rollout, workspace settings, role and administrator controls. Check the current interface and official notices rather than naming a presumed replacement.

The 6 July release note about GPT-5.5 Instant Mini is narrower: OpenAI described it as a rolling ChatGPT fallback after GPT-5.5 Instant or Auto rate limits, said it would not appear in the model picker, and said the update did not affect the API or Codex. It supplies a reason to preserve task intent explicitly, but it does not establish output equivalence or any automatic route from ChatGPT into Codex.

The closing decision rule is therefore evidence-based: mark the Codex phase complete only when the authorised diff, named check evidence and required human acceptance are attached to the same packet version and baseline. Otherwise record the exact pending state. A reviewable stop is a valid outcome; an unsupported completion claim is not.

Troubleshoot the handoff without guessing what transferred

A model-switch-safe packet can make a handoff inspectable, but it cannot make different models or product surfaces equivalent. The diagnostic question is therefore not “Which model probably handled this?” It is “Does the receiving surface have every authorised input, boundary and acceptance check required to perform and review the task?” If the answer is uncertain, stop execution and repair the packet rather than asking the system to reconstruct missing context.

Two dated product facts explain why this distinction matters. OpenAI’s 6 July 2026 ChatGPT release note said GPT-5.5 Instant Mini was rolling out as the fallback reached after GPT-5.5 Instant or Auto rate limits. OpenAI also said that this fallback would not appear in the model picker and that the update did not affect the API or Codex. A rollout does not establish universal availability, output equivalence, an API model identifier or a Codex selection.

Separately, OpenAI’s Codex model documentation, accessed on 1 October 2026, scheduled GPT-5.5’s retirement from ChatGPT, ChatGPT Work and Codex for 14 October 2026. The page expressly said that this scheduled retirement did not apply to the OpenAI API. Because 14 October was still in the future on the research date, treat that statement as a schedule, not proof that retirement had already occurred. If using this tutorial after that date, check the current official documentation and the relevant account before describing the status.

1. The apparent model changed or a hidden fallback may have occurred

Distinction: a hidden fallback is a product-routing event, whereas a task packet is user-controlled evidence. The absence of a model-picker change does not prove that the same model handled every turn. Conversely, a changed answer does not prove that a fallback occurred. Do not infer model identity from tone, speed, length or apparent quality.

1. Pause further edits or consequential actions.
2. Record the date, product surface and any model label that was actually visible. Write “not shown” when no label was visible; do not infer one.
3. Save the latest approved packet, source register, repository revision and working-tree state.
4. Compare the new output with the packet’s acceptance checks, not with a previous answer’s style.
5. Re-submit only the necessary packet and files to the intended surface. State that prior chat context must not be assumed.
6. Request a plan or analysis before authorising changes. Verify that the plan cites the supplied sources, respects the file boundary and names the required checks.
7. If the plan depends on absent context, reject it and add the missing authorised material explicitly.

Decision rule: continue when the proposed work can be justified entirely from the current packet and inspected files. Stop when success depends on identifying an invisible fallback, remembering an earlier conversation or assuming equivalent behaviour across models.

Example: suppose an earlier chat proposed changing a parser and named three edge cases. The next response omits one case after a rate-limit event. Do not conclude that the fallback is less capable. Add all three cases to the packet as acceptance requirements, attach the relevant test fixture, and ask for a fresh plan. The packet repairs the missing requirement without making an unsupported claim about the model.

2. A stored model name is outdated or no longer selectable

Distinction: a model name in a continuity record describes observed configuration at a point in time; it is not a permanent execution requirement or an entitlement. OpenAI’s documentation indicates that model visibility can depend on plan, client, rollout, workspace settings, role and administrator controls. A Codex configuration default does not grant access to an unavailable model.

1. Check the current model list in the actual account and client being used.
2. Check workspace notices and applicable administrator policy.
3. Retain the old model name in the historical record, with its observation date.
4. Remove model-specific wording from the operative requirements unless a documented feature is genuinely essential.
5. Translate the dependency into observable requirements: permitted tools, required file access, output format, validation commands and review gates.
6. Select only a model visibly available to the authorised user. Record the new visible selection separately.
7. Run the packet’s acceptance procedure again; never inherit a previous acceptance result.

Decision rule: proceed with an available model when the task is defined by inspectable inputs and outputs rather than an undocumented behavioural assumption. Escalate or redesign the task when it requires a feature that the available surface does not expose.

Example: an old packet says “Use GPT-5.5 because it understands the repository.” Replace that instruction with “Read the root and package-level AGENTS.md files, inspect the named parser files, propose a minimal diff, run the listed parser tests and report unresolved ambiguity.” Preserve “GPT-5.5 was visible when the packet was created” only as provenance. Repository understanding must be demonstrated through the plan and diff, not assumed from the name.

3. ChatGPT Work or Codex is unavailable

Distinction: product suitability and account access are separate questions. OpenAI describes Chat as conversational assistance, Work as longer multi-step work and finished deliverables, and Codex as software-development and technical work. That classification does not promise that every account, client or managed workspace exposes every surface or model.

1. Confirm that the user is signed into the intended account and workspace.
2. Check the current client, product navigation and official account documentation.
3. Ask the workspace administrator whether the surface or relevant capability is enabled. Do not ask for a policy bypass.
4. If access remains unavailable, preserve the packet as a versioned bundle rather than pasting fragments into an improvised channel.
5. Separate analysis from execution. A permitted chat may help refine wording, but it must not be told that it has repository access when it does not.
6. Perform code changes manually or through an approved development process, using the packet’s file scope and checks.
7. Record the blocked surface and the alternative process in the continuity record.

Decision rule: use an alternative only if it can honour the same data permissions, source boundary, repository scope and human approval gates. Otherwise wait for authorised access or reduce the task. Convenience is not grounds for copying restricted material to a personal account or unapproved tool.

Example: if Codex is not available in a managed workspace, retain the code task as a local review checklist. A developer can inspect the named files, make the minimal change, run the approved commands and attach the diff and logs. Do not move proprietary files to another account merely to reproduce the Codex workflow.

4. A required file, attachment or repository path is missing

Distinction: an absent file is an input failure, not permission to recreate its contents. ChatGPT and Work conversations can appear together in Recents, but OpenAI documents Codex as a separate view with separate history. That does not establish automatic transfer of chats, attachments, permissions or repository state.

1. Name the missing item precisely: path, document title, expected revision and why it is required.
2. Check whether the packet points to a path outside the authorised repository root or current worktree.
3. Verify case, branch, revision and generated-file status.
4. Ask the packet owner to supply or authorise the item. Do not search unrelated directories.
5. If an authoritative source is unavailable, mark the affected claim or acceptance check as blocked.
6. Continue only with independent work whose validity does not depend on the missing item.
7. List every omission in the outcome report.

Decision rule: stop an edit when the missing material could change the intended behaviour, legal wording, data handling, interface contract or test expectation. Continue with clearly separable investigation only when it cannot modify or prejudge the blocked decision.

Example: the packet requests an authentication error-message change but the referenced policy document is absent. Inspection may identify where messages are defined, but no wording should be committed. The correct partial result is a path map, a proposed edit location and a blocking request for the approved text.

5. Inputs contradict one another

Distinction: authority resolves conflicts; fluency does not. A user instruction, repository instruction, official source, test fixture and historical chat may each have a different role. The newest item is not automatically authoritative, and a test can encode obsolete behaviour.

1. Quote or summarise each conflicting requirement narrowly.
2. Identify its source, date, owner and declared authority.
3. Classify the conflict: factual, behavioural, scope, security, output or timing.
4. Apply any precedence already approved in the packet or applicable AGENTS.md instructions.
5. If no precedence resolves it, present alternatives and their consequences to the responsible human.
6. Record the decision and approver before editing.
7. Add or revise a test so the chosen interpretation becomes inspectable.

Decision rule: never silently combine incompatible requirements. Proceed only when an authorised decision identifies which requirement governs or explicitly narrows the task to an uncontested portion.

Example: a ticket asks for an empty field to be rejected, while an existing fixture expects it to be accepted. The packet owner must decide whether the ticket changes the contract or the fixture documents current required behaviour. A useful response shows both interpretations, affected files and candidate tests; it does not select the more convenient one.

6. A named test fails

Distinction: test execution evidence and task acceptance are not the same. A failure can expose a defect in the proposed change, an existing repository failure, an environment problem or an obsolete expectation. A passing command likewise does not prove that source claims, scope and human requirements were satisfied.

1. Capture the exact approved command, working directory and exit status.
2. Preserve the relevant failure output without exposing secrets or personal data.
3. Check whether the failure occurs in a clean baseline at the recorded revision, if the owner authorises that comparison.
4. Map the failure to changed files and the acceptance requirement it protects.
5. Do not weaken, skip or rewrite the check solely to obtain a pass.
6. Propose the smallest repair or explain why the failure is unrelated.
7. Re-run only the necessary approved checks after a repair, then submit both the diff and evidence for review.

Decision rule: do not call the task complete while a required check fails. A human owner may explicitly accept a documented pre-existing failure, but that exception must identify the evidence, risk, approver and follow-up. The system must not grant itself that exception.

Example: a documentation-link check fails on an unchanged archived page. Record that the failing path is outside the edit, provide baseline evidence if authorised, and ask whether the owner accepts the pre-existing failure. Do not delete the archived page, exclude it from validation or report “all checks passed”.

7. The requested tests cannot run

Distinction: “not run” differs from “failed” and “passed”. Missing dependencies, unavailable services, restricted network access and absent credentials are execution conditions, not test results.

1. Record the command and the reason execution could not begin or complete.
2. Identify whether the blocker is part of the approved environment setup.
3. Do not place credentials, access tokens, private keys or sensitive connection strings in the prompt or report.
4. Ask an authorised operator to provide the environment or run the command independently.
5. Use static inspection or a narrower local check only as supplementary evidence.
6. Label every unexecuted check explicitly.

Decision rule: accept substitute evidence only when the human owner says it satisfies the relevant risk. A syntax check cannot silently replace an integration test, and inspection cannot be labelled execution.

8. The result is only partially complete

Distinction: partial completion can be useful when its boundary is explicit. It becomes misleading when completed investigation, proposed edits and verified implementation are collapsed into one “done” label.

Divide the result into five states:

• Completed and verified: implemented within scope, with named evidence.
• Completed but unverified: an edit exists, but required checks were not run or reviewed.
• Investigated: findings or a plan exist, but no edit was authorised.
• Blocked: a named dependency, decision or permission is absent.
• Not attempted: deliberately excluded by scope or time.

1. Map every requested deliverable to one state.
2. List modified files separately from proposed files.
3. Associate each completed item with source and test evidence.
4. State residual risks and unresolved questions without predicting their severity.
5. Ask the human reviewer to accept, reject or return individual items.
6. Create a new packet version for follow-up work rather than overwriting the original record.

Decision rule: close the packet only when every item is either accepted or explicitly deferred by its owner. “Most work completed” is not a substitute for an itemised disposition.

Example: a three-file change updates two implementation files, but the missing approved copy blocks the third. Report the two files as completed but awaiting their named checks, the copy file as blocked, and the overall request as partially complete. Do not manufacture temporary wording unless the owner authorises it.

Reusable HyperText Markup Language (HTML)The standard markup language used to structure content on web pages. Open glossary entry task-packet template

The following is an example of a complete, reusable structure rather than a product-generated guarantee. It deliberately contains concrete safe defaults instead of angle-bracket placeholders or filler text. Copy it into a version-controlled file, replace the example values with reviewed task facts, and delete sections that are genuinely inapplicable rather than leaving ambiguous blanks.

<article class="task-packet">
  <header>
    <h2>Correct command-line help text for the export command</h2>
    <p><strong>Packet version:</strong> 1.0</p>
    <p><strong>Prepared on:</strong> 2026-10-01</p>
    <p><strong>Execution surface:</strong> Codex, if authorised and available</p>
    <p><strong>Model dependency:</strong> None; acceptance depends on the sources, diff and checks below</p>
    <p><strong>Prior conversation:</strong> Not authoritative and must not be assumed available</p>
  </header>

  <section>
    <h3>Goal</h3>
    <p>Make the export command's help text match the approved command reference without changing runtime behaviour.</p>
  </section>

  <section>
    <h3>Authoritative inputs</h3>
    <ol>
      <li>docs/commands/export.md at the packet's recorded repository revision: approved wording source.</li>
      <li>src/cli/export_help.ts: implementation location to inspect.</li>
      <li>tests/cli/export_help.test.ts: existing behavioural check to inspect and update only if required by the approved wording.</li>
      <li>Applicable AGENTS.md files from the repository root to the working directory: repository instructions.</li>
    </ol>
    <p>No chat transcript, remembered answer or external source overrides these inputs.</p>
  </section>

  <section>
    <h3>Known facts and unresolved matters</h3>
    <ul>
      <li>Approved fact: the documentation file supplies the required user-facing wording.</li>
      <li>Approved constraint: runtime parsing and option names must not change.</li>
      <li>Unresolved matter: whether a generated snapshot also contains the text; inspect and report before editing it.</li>
    </ul>
  </section>

  <section>
    <h3>Repository scope</h3>
    <p>Read scope: repository instructions, the documentation source, the implementation file, the named test and directly referenced generated metadata.</p>
    <p>Write scope: src/cli/export_help.ts and tests/cli/export_help.test.ts only.</p>
    <p>Excluded: parser logic, dependencies, build configuration, unrelated formatting and network operations.</p>
  </section>

  <section>
    <h3>Procedure</h3>
    <ol>
      <li>Read applicable repository instructions and report any conflict.</li>
      <li>Inspect the named files and propose a minimal plan before editing.</li>
      <li>Wait for human approval of the plan.</li>
      <li>Make only the authorised change.</li>
      <li>Show the diff and run the approved checks.</li>
      <li>Return an itemised outcome; do not commit, publish or open a pull request.</li>
    </ol>
  </section>

  <section>
    <h3>Acceptance checks</h3>
    <ul>
      <li>The displayed help text matches docs/commands/export.md.</li>
      <li>Option names and parser behaviour are unchanged.</li>
      <li>The focused export-help test passes when run in the approved environment.</li>
      <li>The diff contains no files outside the authorised write scope.</li>
      <li>A human reviewer approves the wording and diff.</li>
    </ul>
  </section>

  <section>
    <h3>Evidence report</h3>
    <ul>
      <li>Modified files: report exact paths, or state that no files were modified.</li>
      <li>Commands: report exact approved commands and working directories.</li>
      <li>Results: classify each check as passed, failed or not run.</li>
      <li>Exceptions: report missing files, conflicting instructions and unavailable permissions.</li>
      <li>Residual work: distinguish blocked, deferred and not attempted items.</li>
    </ul>
  </section>

  <section>
    <h3>Human gate</h3>
    <p>No implementation is accepted until an authorised reviewer inspects the source mapping, diff and check evidence.</p>
  </section>
</article>

How to adapt it: first replace the title and goal; then replace every source and path with an item the recipient can actually access. Rewrite read and write scope independently. Add commands only after a repository owner confirms them. Finally, turn each material risk into an acceptance check. If a field cannot be completed, identify it as an unresolved dependency in prose rather than inserting an unfinished label, dummy paths or invented commands.

Trade-off: a larger packet preserves more context but increases review burden and the chance of admitting unnecessary sensitive material. Prefer the smallest packet that contains all authoritative sources, decisions, permitted files and risk-based checks. Link or copy only material the recipient is authorised to use; keep untrusted data, passwords, tokens, private keys, personal data and unrelated proprietary content out of prompts.

Questions and answers

Does the packet guarantee the same result after a model switch?

No. It preserves explicit task intent and review evidence; it does not make models, snapshots, tools, context handling or outputs equivalent. The decision rule is to re-run the acceptance process after any new execution rather than approving an answer because the packet is unchanged.

Can Codex recover the missing ChatGPT conversation automatically?

Do not assume so. OpenAI’s documentation accessed on 1 October 2026 says Codex history remains separate from ChatGPT history. Supply the necessary authorised sources and constraints manually. If the task cannot be understood without the old transcript, extract and review the relevant facts before proceeding.

Should the packet insist on GPT-5.5 Instant Mini after a ChatGPT fallback?

No. OpenAI described it on 6 July 2026 as a ChatGPT fallback that does not appear in the picker and does not affect the API or Codex. Do not invent a selector, API identifier or Codex configuration for it. Specify observable requirements instead.

What if a configuration file names a model that the user cannot access?

Treat the setting as an ineffective default, not an entitlement. Check the current picker, client, plan and workspace policy; then select an available option and re-validate the task. Never advise bypassing administrator controls.

May a failed test be omitted if the diff looks correct?

No. Report the failure and investigate its relationship to the change. A human owner may accept a documented exception, but the packet must preserve the failing command, relevant evidence, risk and approval. Visual confidence is not test evidence.

Who must review consequential outputs?

A suitably authorised human must review security, privacy, financial, employment, government, legal or similarly consequential decisions and actions. The packet and model output may organise evidence or propose changes, but they must not serve as the sole approval mechanism. Require specialist review where the organisation’s policy or the subject requires it.

Does this tutorial provide prices or benchmark results?

No. It provides no API prices, subscription-capacity estimate, timing result, quality score or benchmark. API pricing must not be used to infer ChatGPT Work or Codex subscription usage, and the cited fallback notice supplies no equivalence measurement. No hands-on product, cost or performance test is claimed here.

When should the task be abandoned rather than repaired?

Stop when the authoritative source cannot be obtained, permissions are insufficient, contradictory requirements lack an owner, required verification is impossible and no reviewer accepts a bounded alternative, or the requested action would exceed repository or data-access limits. Preserve the packet and blocker report so a later owner can resume without reconstructing events from memory.

Useful Links

• OpenAI: ChatGPT release notes
• OpenAI: Codex models
• OpenAI: ChatGPT Work and Codex
• OpenAI: Codex prompting guidance
• OpenAI: Custom instructions with AGENTS.md
• OpenAI: GPT-5.5 API model documentation