ChatGPT memory and context: what carries into the next task

I want a reusable preference to survive the conversation, and I want an old campaign assumption to stop following the team around. Those are two different maintenance jobs. Calling both “memory” makes the second one surprisingly easy to forget.

The distinction I use is a desk and a notebook. Context is what is on the desk for this task. Memory is a notebook that may help with the next one. Required instructions deserve a clearly labeled manual.

Understand the working desk

Context includes the request, relevant conversation, instructions and material made available through files or tools. The model reasons over what is supplied to it for the task. It cannot make an inaccessible account note current simply because the company was discussed last week.

For a meeting brief, the important context might be the latest call note, a current CRM export and the desired audience. A long transcript of unrelated campaign brainstorming can add bulk without improving the decision. The useful question is what information changes the answer.

I would create a short task packet rather than attach the entire archive. Include source dates and call out contradictions. Context quality is partly selection: enough material to support the answer, with enough structure to keep yesterday's assumption from outranking today's evidence.

Use memory for stable continuity

Memory can reduce repetition of durable preferences, recurring work patterns and useful background. It is a convenience layer. I would use it for preferences such as concise answers, source-linked claims or a preferred review format, subject to the controls available in the account.

Changing business facts deserve a different treatment. A lead's budget, the current ICP or a launch deadline can become stale quickly. Put those in current sources and specify their dates. If a remembered fact conflicts with the source packet, require the conflict to be surfaced instead of silently resolved.

This avoids a subtle failure: the answer becomes more personalized while becoming less accurate. A familiar tone can make old information feel trustworthy. The more comfortable the interaction becomes, the more valuable an explicit source check is for facts that change.

Separate ChatGPT memory from local Codex memory

Official documentation distinguishes the memory settings in ChatGPT from the local memory store used by Codex hosts. ChatGPT Work on the web uses the memory settings available to the account and workspace. It does not read a local Codex memory directory merely because the same person signed in.

Local Codex memories are off by default and can be enabled where supported. Codex can derive useful context from eligible earlier chats and store generated memory files under its home directory. The update happens in the background and may not occur immediately after a task ends.

For an operator moving between products, this explains why continuity can differ. A preference available in one environment may not be present in another. Confirm the relevant control rather than treating a missing detail as proof that the whole product is broken. The host and account boundary matters.

Keep required guidance explicit

A required rule should be inspectable by the people maintaining the workflow. For a content repository, that might be “use www canonicals,” “edit the source JSON” or “run the page generator after content changes.” Those belong in project instructions or an AGENTS.md file, not only in a remembered conversation.

Memory is generated and selective. A mandatory check needs a stronger home. The practical consequence is that another teammate should be able to inspect the requirement before running the task, even if their personal history with the agent is empty.

I would keep the rules short, specific and tied to the work. If a rule has an exception, write the exception beside it. A hundred undocumented preferences spread across old chats become a process nobody can review. Explicit guidance makes disagreement and maintenance possible.

Treat context windows as a working limit

Models have finite context capacity, usually described in tokens. A token is a unit of text or other encoded input used by the model, not a guaranteed word count. Product behavior, retrieval and context management determine what material is available during a long task.

Avoid the filing-cabinet assumption: uploading a large amount of material does not prove every detail is considered equally in every answer. Ask for the decisive sources and their relevant passages. For a pipeline analysis, the definition of stage and the export date may matter more than thousands of historical notes.

When a long task loses direction, restate the outcome, current decisions and remaining checks. Keep durable decisions in an explicit artifact the next run can read. Context management is easier when the work itself has a clear state. The agent should not have to reconstruct the business decision from a trail of half-finished suggestions.

Audit memory through a concrete change

Use a harmless preference to test the controls. For example, set a preference that account briefs should separate facts from unknowns, then begin a new task and observe whether the preference appears. Record which environment you tested. Do not infer that the same behavior will occur in every client.

Next test a change. Update the preferred brief length or remove the preference through the supported settings. In local Codex, chat-level memory controls can distinguish using existing memories from contributing the current chat to future memories. These choices do not necessarily change the global setting.

The test should remain about behavior, not secret storage. Do not put credentials or sensitive account details into a memory experiment. Even where generated memories redact known secret patterns, that does not make memory an appropriate place to store access tokens.

Build a task packet for changing facts

For fictional Cedar Metrics, imagine the old targeting range was 50 to 200 employees and the approved ICP now says 100 to 500. A useful task packet supplies the dated current ICP and asks the agent to flag any conflicting assumptions. It does not rely on the agent remembering a strategy meeting correctly.

The expected result uses the current range and identifies uncertain records. If the answer still applies the older range, inspect the source and instructions responsible. Changing the model would be an expensive way to avoid updating the actual rule.

I would save the current ICP, one accepted scoring example and a short change note together. This is the bridge between personal continuity and team reliability. The next operator can understand the decision without inheriting your entire chat history.

Where memory becomes a liability

The first failure is stale certainty: an old fact arrives as familiar context and nobody asks where it came from. The second is hidden policy: a required workflow exists only in one person's memory. The third is assuming deletion, disabling and source removal mean the same thing across products.

Use the documented controls for the specific store, and verify the result with a fresh task. Local generated memory files can be useful for inspection, but the official guidance recommends supported controls rather than relying on manual edits as the primary management method.

The goal is useful continuity with visible authority. Keep preferences easy to reuse, facts fresh and mandatory rules reviewable. If a teammate started tomorrow with no memory history, could they still run the workflow correctly?

How to set it up

Frequently asked questions

Sources & further reading

• Memory stores and controls
• Personalization
• Project context
• Required repository guidance

ChatGPT and Codex change quickly. This page was last reviewed September 22, 2026; verify time-sensitive details against the official docs above before relying on them.