OpenAI ecosystem: the web / desktop split
The question is continuity of the assistant: what happens to settings, inherited behavior, context and saved conversations when the user moves between ChatGPT Web, Codex Web and Codex Desktop?
These are logical ownership and behavior maps. They do not assert private service topology or physical database layout. Documentation establishes some common mechanisms, not universal feature, preference or history equivalence.
Current map
Newly clarified capability split: current reusable Codex cloud environments list computer/browser use as unsupported and do not sync personal local skills. Work Cloud and Dots have different cloud tool paths. “Cloud” is therefore insufficient as a capability label. S7 S9 S11
Settings, instructions, memory and style
| Experience | Settings / authority | Behavior and context | Conversation scope | Execution | Evidence |
|---|---|---|---|---|---|
| ChatGPT Web — Chat / Work | Account/workspace preferences; Work cloud controls. | ChatGPT personalization and memory. Web Work writing-style feature. | ChatGPT conversations; Work history remains distinct from Codex. | Chat in browser; Work hosted, or eligible synced conversation with local steps. | C01 C04 C06 C07 C11 C12 |
| Codex Web — new Cloud path | Published environment, environment access and task controls. | Repository skills available; personal local skills not synced. Personal profile inheritance: Q1. | A cloud task’s own conversation and working state. | Prepared cloud workspace. Computer/browser use currently unsupported in this path. | C03 C08 C09 C25 |
| CODEX DESKTOP — local / worktree | Selected host’s local Codex configuration, policies and project setup. | Personality, global/project instructions, skills and optional local Codex memories. | Host-backed chats / local state; desktop and IDE can share project chats. | Local folder or Git worktree; tools depend on the selected host. | C04 C05 C06 C07 C10 C21 C22 |
| CODEX DESKTOP — Cloud selected | Cloud task/environment controls. Desktop UI settings still describe the client. | Do not presume local personality, personal skills or memory transfer. Q1 remains explicit. | Reopens the same cloud task; does not turn all local chats into cloud chats. | Same prepared cloud-task class accessed from Web or mobile. | C08 C09 C18 |
| Desktop ChatGPT — Work with sync | Workspace cloud orchestration policy plus applicable local execution requirements. | Work memory controls; local execution does not imply local Codex memory inheritance. | Eligible new Work conversation across clients; separate Codex history. | Cloud coordinates; approved steps run in cloud or on connected computer. | C07 C11 C12 C20 |
| Dot — persistent agent | Dot instructions/rules plus separate messaging, app and computer permissions. | Relevant ChatGPT memory and dot’s own notes. Local skills require local access. | Persistent dot conversation; children have distinct conversations and context. | Own cloud computer, background agents, delegated Work/Codex tasks. | C13 C14 |
| Team Tasks / Space / plugins | Different ownership: team service account; artifact sharing; connected-account permissions. | Plugins supply capabilities/workflows; Space is shared content, not a universal agent memory. | Team runs and artifacts have their own access; private chats are not shared by sharing a Page. | Team Tasks cloud; plugins operate where supported and permitted. | C15 C16 C19 C23 |
Conversation continuity
| Route | Mechanism | What continues | Boundary | Evidence |
|---|---|---|---|---|
| Codex Web ↔ Codex Desktop (Cloud) | Reopen the SAME cloud task | Its task conversation and saved cloud workspace continue. | Does not establish shared local settings, memory or browser sessions. | C08 |
| Codex Desktop local → mobile / another desktop | Remote connection | Use the SAME host-backed conversation and resources. | The host must be available; credentials and tools stay associated with that host. | C10 |
| Local host A → connected host B | Explicit host handoff | Transfer the chat and Git state to a matching project. | Separate from Remote; Codex Cloud is not a supported destination. | C18 |
| Eligible desktop Work → web / mobile | Work Sync / cloud coordination | Continue an eligible new Work conversation; local tools require an online computer. | Older tasks keep their mode. Work and Codex histories remain distinct. | C11 / C12 |
| Local conversation → shared link | Read-only snapshot | Show a fixed view of the conversation. | Not continuation or two-way synchronization. | C17 |
| Published cloud environment → new task | Start a NEW workspace | Reuse prepared setup for a fresh task. | Not resuming an existing task; environment republishing does not rewrite old task state. | C08 |
| Dot → delegated Work / Codex task | New task with selected context | The dot can coordinate and follow up while its own conversation remains open. | Child conversation is separate; entire dot history is not automatically copied. | C14 |
Supporting scopes that do not fit a single “product” box
Desktop Chat / Work
Shares the desktop application with Codex, but has its own presentation and Work continuity path. App packaging does not remove the history boundary. S1 S2 S10
Mobile / Remote / SSH
A client may access cloud conversations or a selected computer. Remote keeps host resources; handoff explicitly transfers chat and Git state between compatible connected projects. S7 S8
CLI / IDE / app-server
Local developer clients share Codex configuration. The app-server models threads, turns, items and streamed events. These are public client contracts, not proof of one hosted backend. S3 S18
Dots
A persistent responsibility and coordination layer, with its own notes and cloud computer. Its children are distinct tasks with selected context and their own conversations. S11 S12
Space / Pages / files / Sites
An artifact and collaboration plane. Content permissions, project context, private memory and chat visibility are distinct. S13
Plugins / skills / MCP / Events
Capability and workflow packages. Installation, deployment, external account access and event subscription are different operations. S14 S20
Team Tasks / workspace connections
Team-owned automation uses a service account and configured external identities. This differs from personal-agent ownership. S15
Legacy Codex Cloud
Keep the older code-review/integration workflow separate from new reusable cloud environments. GitLab capabilities in the digest must not be attributed to the new path, whose current limitations exclude GitLab. S7 S17
OpenAI Platform API
Adjacent developer access and authentication plane. API-key local workflows and ChatGPT-authenticated cloud workflows have different eligibility and account controls. No private backend equivalence is asserted. S21
Candidate reorganization boundaries — proposed, not current
Each repair follows a documented seam or a reported user friction. A shared contract may be the right repair without replacing every implementation or forcing identical interfaces.
| ID | Problem boundary | Proposed repair | Basis |
|---|---|---|---|
| F1 | Behavior changes with the entry point | Expose an effective-profile view: chosen model/personality, instruction sources, memory scope, project guidance and active skills. Show each override’s origin. | C04 C05 C06 C07 / Q1 Q2 |
| F2 | Several meanings of “continue” | A unified index should distinguish reopen, Remote, handoff, snapshot and new-task delegation. Preserve stable links; explain when the executor is unavailable. | C08 C10 C11 C17 C18 |
| F3 | “Cloud” hides different capabilities | Use explicit execution-target descriptors for Work Cloud, a dot’s cloud computer, new Codex Cloud, legacy cloud workflows and a connected local host. | C09 C13 C20 C25 |
| F4 | Same name, different setting scope | Separate portable personal preferences from client appearance, project guidance, executor configuration, connection permissions and managed requirements. Show scope before applying a change. | C04 C05 C16 C20 C22 |
| F5 | Context looks shared when it is not | Show the provenance of recalled memory and attached context. Keep personal memory, dot notes, project sources and shared Pages distinguishable. | C07 C14 C15 |
| F6 | Delegation loses visible lineage | Connect a responsibility, child task, run, execution target and resulting artifact through inspectable links without granting access to unrelated private conversations. | C13 C14 C15 C19 |
Start with an effective-profile inspector and a unified conversation index. Then define portable preferences and explicit execution descriptors. Preserve scoped overrides and ownership; do not silently pool private memory, credentials or local files.
Release cutoff and changes that affect the map
| Date in 2026 | Map-relevant change | Sources |
|---|---|---|
| July 9 | Codex joins the desktop app; dedicated Codex experience remains. | S16 |
| August 20 | Read-only thread snapshots and desktop/iOS pinned-thread continuity are announced. Neither establishes a universal editable web history. | S17 |
| September 29 | Dots, Work sync, Space, reusable cloud environments, Team Tasks, event-driven plugins and GPT-6.1 Sol change the topology. | S15 S16 |
| October 1 | CLI 0.160.0 is the latest dated entry found through the October 3 cutoff. Client/runtime updates do not prove feature parity. | S16 |
| After cutoff | The October 14 GPT-5.5 retirement is announced future work, not an already-completed change. | S16 |
Evidence ledger
SOURCE_REVIEWED identifies reviewed sources. Evidence class distinguishes official documentation from the supplied screenshot. Proposed repairs are SPECIFIED; account-level validation is AWAITING_LOCAL_RUN. No private local configuration observation is included.
| Claim | Status | Finding | Source |
|---|---|---|---|
| C01 | SOURCE_REVIEWED | ChatGPT Web offers Chat and Work. Work and Codex have overlapping abilities but different presentation contracts. | S1 S2 |
| C02 | SOURCE_REVIEWED | Codex joined the ChatGPT desktop application on July 9. Codex Desktop remains a distinct user experience in this map; packaging is not evidence of settings or history unification. | S16 |
| C03 | SOURCE_REVIEWED | The user identifies the attachment as Codex Web. It shows chatgpt.com, Cloud, an environment chooser, an approval control and a model control. Its URL path and product heading are not visible. | User attachment |
| C04 | SOURCE_REVIEWED | Desktop local Codex uses configuration shared with CLI and IDE. Hosted Work does not read local Codex configuration files. | S3 |
| C05 | SOURCE_REVIEWED | Local Codex defaults can come from user, trusted project, managed and system layers, with session overrides. Requirements constrain permitted values. | S4 |
| C06 | SOURCE_REVIEWED | Personal Codex instructions are kept in global AGENTS.md; projects can add guidance. Personality and Work web writing-style personalization are additional behavior inputs. | S5 |
| C07 | SOURCE_REVIEWED | ChatGPT memory and local Codex memory are separate. Work uses account/workspace memory controls, rather than local Codex memories. | S6 |
| C08 | SOURCE_REVIEWED | Web, desktop and mobile can reopen the same Codex cloud task. Each task starts from a published environment and retains its own working state. | S7 |
| C09 | SOURCE_REVIEWED | New Codex cloud environments have repository skills, but do not sync personal skills from the local computer. Computer and browser use are listed as unsupported. | S7 |
| C10 | SOURCE_REVIEWED | Local Codex chats and resources belong to the selected host. Remote access exposes that host’s configuration and tools; it is not migration to a cloud task. | S8 |
| C11 | SOURCE_REVIEWED | Eligible synced Work tasks use cloud coordination and may execute approved local steps on a connected computer. Existing tasks retain their original mode. | S9 |
| C12 | SOURCE_REVIEWED | Enabling Work local access does not combine Work history with Codex history or change Codex configuration behavior. | S10 |
| C13 | SOURCE_REVIEWED | Dots persist in the cloud with their own computer, relevant ChatGPT memory and saved notes. Messaging, plugin and computer connections grant different capabilities. | S11 |
| C14 | SOURCE_REVIEWED | Dots can delegate Work or Codex tasks and parallel work. Delegated tasks have their own conversations and selected context; they do not inherit the dot’s entire conversation. | S12 |
| C15 | SOURCE_REVIEWED | Space organizes Pages and shared artifacts. Page sharing does not share private chats or memories. A ChatGPT workspace governs membership and access; a space groups content. | S13 |
| C16 | SOURCE_REVIEWED | Plugins can bundle skills, MCP tools and UI. One directory serves supported ChatGPT and Codex surfaces, but installation does not deploy local hook scripts everywhere. | S14 |
| C17 | SOURCE_REVIEWED | Shared local-thread links are read-only snapshots. This is a distinct mechanism from continuing the original conversation. | S17 |
| C18 | SOURCE_REVIEWED | Host handoff moves a chat and Git state between matching connected projects. Handoff to a Codex cloud environment is not supported. | S8 |
| C19 | SOURCE_REVIEWED | Team Tasks are cloud work owned through a team service account and configured app connections. Their account authority differs from a personal dot or personal task. | S15 |
| C20 | SOURCE_REVIEWED | Work, Codex local execution and cloud targets have scoped controls. Cloud orchestration and local tool execution can have different policy and hook behavior. | S9 S10 |
| C21 | SOURCE_REVIEWED | Local Codex persists local state under CODEX_HOME. App-server exposes threads, turns, items, history and approval events; public client contracts do not disclose the full hosted backend. | S22 S18 |
| C22 | SOURCE_REVIEWED | Desktop-only local environments configure worktree setup and project actions. These are distinct from published Codex cloud environments. | S19 |
| C23 | SOURCE_REVIEWED | MCP Events uses subscribed webhooks for supported Work Cloud and Dots workflows; it does not imply unrestricted monitoring in every client. | S20 |
| C24 | SOURCE_REVIEWED | Local clients can use ChatGPT sign-in or API-key authentication. Codex Cloud requires ChatGPT sign-in. Account identity does not erase tool or permission boundaries. | S21 |
| C25 | SOURCE_REVIEWED | The cloud docs distinguish a legacy workflow for code review and integrations from new reusable cloud environments. Do not transfer legacy feature claims to the new environment path. | S7 S17 |
| C27 | SOURCE_REVIEWED | September 29 introduced Dots, Work sync, Space and reusable cloud environments. GPT-6.1 Sol and October 1 CLI updates are dated before the cutoff. The announced October 14 GPT-5.5 retirement is still future. | S15 S16 |
| C28 | SOURCE_REVIEWED | Local Codex already offers /status and /debug-config for effective session settings and configuration provenance. A proposed common profile view should extend these diagnostics across clients and context sources. | S3 |
Source directory
- S1 — Use ChatGPT
- S2 — Desktop app
- S3 — Developer settings
- S4 — Config basics
- S5 — Personalization
- S6 — Memories
- S7 — Codex cloud environments
- S8 — Remote connections and handoff
- S9 — Work Cloud and Dots local access
- S10 — Work architecture and history boundary
- S11 — Meet Dots
- S12 — Dot tasks and memory
- S13 — Space
- S14 — Plugin architecture
- S15 — September 29 DevDay releases
- S16 — Dated changelog
- S17 — Feature digest / shared snapshots
- S18 — Codex app-server
- S19 — Local environments
- S20 — MCP Events
- S21 — Authentication
- S22 — Local state locations
Open questions
No missing arrow should be read as proof that an integration does not exist. These questions set the next investigation boundaries.
Q1 — Codex Cloud personal profile
Exact precedence and portability of personality, personal instructions and memories between Codex Web and a cloud task opened in Desktop are not established.
How to resolve: Compare the same cloud task in both clients and inspect exposed settings / effective context. Do not infer missing integration from missing documentation.
Q2 — This user’s two effective styles
The user reports different inherited styles. The effective settings and instruction sources in those sessions have not been established.
How to resolve: Compare session-level preferences, product presentation, project instructions and skill activation for the actual two conversations.
Q3 — Hosted history implementation
Logical continuity is documented; physical databases, replication and a universal history index are not.
How to resolve: Keep the map at ownership and continuity-contract level. Implementation discovery is needed before specifying backend migrations.
Q4 — Exact screenshot route
The screenshot lacks a URL path and product heading. Codex Web is the user’s identification, not an independently visible header.
How to resolve: Record the full route and selected environment during a focused UI comparison.
Q5 — Account-specific availability
Rollout, workspace, authentication and client version can change exposed capabilities.
How to resolve: Validate each intended transition with the same account and workspace. The map states conditions rather than universal availability.