ChatGPT and Codex Need a Shared Continuity Contract

Glyphd Labs · October 3, 2026 · Continuity & operational interfaces

Moving from an AI assistant’s web interface to its desktop application should leave three questions easy to answer: Where is my work? What settings apply? Where will the next action run?

OpenAI’s public product documentation describes several answers, depending on the interface, conversation type, execution environment and permissions. Those distinctions can be legitimate. A local repository, a managed cloud container and a persistent agent’s computer have different resources and authority. The problem arises when the user must reconstruct those distinctions from product names, settings pages and separate histories.

This field note recommends one shared continuity contract for ChatGPT Web, Codex Web and Codex Desktop, with Dots participating through explicit tasks and delegated conversations. Specialized interfaces can remain useful while work retains a stable identity and explains its own behavior.

Evidence boundary. This is a review of official documentation available on October 3, 2026, a supplied web screenshot, and a user report of cross-client friction. It is not an inspection of OpenAI’s private backend. The reported style and chat-saving problems have not been reproduced in matched sessions. Proposed fixes and release targets remain unimplemented and unmeasured.

What the current ecosystem actually distinguishes

The terminology already contains an important historical wrinkle: the July 9 changelog records Codex joining the ChatGPT desktop app. “Codex Desktop” remains a useful description of the developer experience people recognize, while the surrounding app has broader ChatGPT functions. The September 29 release adds Dots, Work Sync, Space, reusable cloud environments and Team Tasks. These are substantial changes, rather than evidence of a system standing still. Changelog, DevDay release.

Current distinctions above; proposed repairs below. “Cloud” does not identify one universal execution environment. This is a product-contract map, not a private service topology. Download the diagram SVG.

The supplied screenshot shows chatgpt.com, a Cloud label, an environment chooser, an approval control and a model selector. It does not show the URL path or a product heading. The user identifies it as Codex Web; the image alone cannot independently identify its exact cloud route. That uncertainty is itself a useful reminder to name the execution contract explicitly.

Three failures worth designing against

1. Work is recognizable but its continuation path is unclear

A person starts work in the desktop developer experience, then opens the web expecting to find and continue it. Instead, they need to know which history owns the conversation, whether the relevant computer is connected, and whether a link represents a snapshot or live work.

The documented seams establish that this expectation needs qualification. They do not establish that every missing conversation is a synchronization bug. Shared local-thread links, for example, are read-only snapshots rather than a universal live continuation mechanism. Feature digest.

Proposed repair: one permission-filtered Activity index, with stable conversation and task links. Each entry should show its owner, execution location, availability and continuity class: hosted, synced to a named computer, or local-private. Opening the same eligible task from another client should preserve its identity. A local-private item can remain private and explain why continuation is unavailable.

The index is a shared discovery contract. It does not require uploading every local transcript or replacing all existing stores with one global database.

2. Behavior changes without an understandable explanation

The user reports different styles and settings between web and desktop. Official documentation establishes different configuration and memory inputs, and personalization controls also vary by client. It does not establish which input caused this user’s particular response. Model variation, project guidance, an override or account rollout could also contribute. Personalization.

Proposed repair: a common “What applies here?” view showing effective values and their origins: personal preference, project instruction, current-session override, memory scope and enforced policy. Make selected preferences portable only where their meanings match.

Build on existing local /status and /debug-config diagnostics. Their presence matters: the recommendation is to extend useful inspection across clients. A consistent profile does not require identical model wording, and appearance preferences should remain distinct from agent behavior.

3. Execution labels hide resources and failure behavior

A user sees “Cloud” and reasonably expects their tools, context and ability to recover work to travel with it. Yet a remote computer connection, Work Cloud and Codex Cloud expose different capabilities. Codex Cloud is not a supported remote-handoff destination; selecting another computer for a dot does not relocate an existing task.

Proposed repair: every run starts with an execution manifest naming the target, environment version, available tools, resource bindings, permissions and offline behavior. Required missing capabilities should be explained before dispatch. A change of target creates an explicit new attempt after checkpointing and rechecking resources.

When a host disconnects after an action was issued, the coordinator must distinguish “not started,” “running,” “completed” and “outcome unknown.” A missing response is insufficient evidence for rerunning a mutating operation. Record command intent and receipts, reconcile effects, and use provider idempotency where supported. Universal exactly-once external effects are not promised.

These are proposed contracts, rather than allegations that current implementations always retry unsafely. The October 1 CLI changelog already describes fixes for uncertain submissions and resumed settings; those improvements should be carried forward.

A minimal common model

Keep the user-facing vocabulary small: chat, task, project, dot and result, accompanied by visible run location and access scope. A workspace describes governance; a filesystem directory describes an execution resource.

Internally, distinguish conversation identity, task identity and run identity. A task carries an objective, owner and acceptance conditions. Runs record attempts to achieve it. Delegation creates a linked child task with selected context. Retry transport preserves a command ID; a genuine new attempt receives a new run ID.

Use one logical contract with scoped authorities and execution adapters. Existing stores can remain authoritative while clients share a compatible Activity projection, effective-profile description and execution manifest. Serialize writes per entity, expose revisions, preserve aliases for old links, and reconcile late observations.

Policy and context remain explicit. Configuration precedence is not the same as instruction authority. Project grouping and Page sharing must not silently grant credentials or conversation access. Current requirements vary with orchestration and execution scope, so a common interface must reveal those boundaries. Agent Security.

Dots make the distinction between responsibility and task especially useful. A dot can keep monitoring after a child task ends. Its task activity already exists; the improvement is consistent visibility across clients and clear evidence that the intended result was actually delivered.

Use the analysis as a comparison, then as a repair queue

The comparison record separates documented contracts, screenshot observations, user reports, hypotheses and unrun checks. The three-scenario protocol specifies how to test:

1. Find and resume: locate the same eligible conversation or task on web and desktop; record identity, history and continuation behavior.
2. Explain the profile: compare effective setting sources using a harmless prompt and documented diagnostics; identify unsupported or differing fields without judging prose alone.
3. Recover a disconnected host: use a disposable, read-only local task in a supported Work Sync path; record stale, waiting and recovered states without manufacturing a destructive failure.

Record account eligibility, client version, workspace policy and exact route for each trial. Keep credentials, private chats and raw memory out of public evidence. An unsupported setup produces “not applicable”; an inaccessible surface produces “not run”; neither becomes a reproduced bug.

Direct automation of the desktop application was unavailable during this investigation, so no matched web/desktop trial or disconnection experiment is claimed. That limits the empirical conclusion, while leaving the documented product boundaries and proposed repair sequence available for inspection.

Migrate through contracts users can inspect

Start with clarity: accurate location labels, continuity badges, profile sources and preflight explanations. Then introduce stable identities and read-through adapters over existing histories. Add durable command receipts, replay and recovery before enrolling new execution paths. Finally, introduce selective profile portability and checkpoint-based target transfer where the required grants and capabilities exist.

Keep old runs under their original contracts. Preserve legacy links through aliases. Enroll local-private transcripts only by explicit choice. During an authority transfer, quiesce the writer and reconcile outstanding effects before committing a new routing epoch. Rollback must not activate two competing writers.

Measure baseline find-and-resume time, eligible reopen success, profile-source comprehension, capability prediction and time spent in unknown states. The full blueprint proposes numerical release gates; they are targets awaiting validation, rather than current OpenAI service guarantees.

The architectural hypothesis is falsifiable: if these shared contracts fail to improve user comprehension, continuity and recovery in matched trials, their added complexity is unjustified. Naming changes alone would not establish success.

Artifacts, limitations and revision

• Full architecture blueprint with migration and acceptance criteria.
• Detailed current-state ecosystem map.
• Exact source-capture hashes.
• Source and claim ledger.
• Complete downloadable reference package.

Documentation describes published behavior on the review date; undated pages do not establish a historical launch date. Plan, rollout, client version and workspace policy may affect availability. Private data stores, replication topology and physical service ownership remain unknown. The screenshot’s exact route, this user’s effective profiles and measured incidence of cross-client failures remain unresolved.

The proposal is independent Glyphd Labs analysis. It does not imply OpenAI authorship, endorsement, access to private infrastructure or implementation of the recommended architecture. Its relationship to Glyphd’s existing continuity research, bounded-agent model and operational surfaces is conceptual; those publications do not validate this OpenAI migration proposal.

Revision 1.0.1 · October 3, 2026. Removes an account-specific configuration observation from the downloadable reference, separates evidence classes from canonical states and execution statuses, and adds exact source-capture hashes. This correction does not establish a reproduced runtime defect. Later revisions should attach dated observations and their effect on individual claims.