A coherent OpenAI product and execution model
Architecture proposal · Evidence checked October 3, 2026
Recommendation: standardize the identities, state and continuity of conversations, tasks and runs across every client. Keep specialized interfaces and distinct execution environments. The three highest-impact repairs are a shared activity index, an inspectable behavior profile, and an execution manifest that explains capabilities and recovery before work starts.
This addresses the user’s main problem: moving between Codex Web and Codex Desktop should change the interface and available resources predictably, without making the user reconstruct which assistant settings applied, where the conversation went, or whether work is still running.
The design below is proposed. It is not a description of OpenAI’s private infrastructure and has not been implemented or benchmarked.
1. Evidence and diagnosis
Documented means current official documentation fetched during this investigation. Observed means visible in the attachment. Reported means the user’s experience, not a reproduced defect. Inference means an architectural hypothesis. Proposed means a recommendation or target. Undated documentation establishes the published contract on the verification date; it does not establish a historical launch date.
The attachment shows chatgpt.com, a Cloud selector, an environment chooser, an approval setting and a model selector. The user identifies it as Codex Web. The full route is absent, so the screenshot alone cannot establish which cloud path it represents. The user reports different settings, styles and chat saving across web and desktop; we have not reproduced the exact two-session inheritance path.
Official evidence used for this design:
| ID | Documented boundary | Source |
|---|---|---|
| E1 | Web Work does not load local Codex configuration. Desktop Codex, CLI and IDE share configuration; desktop and IDE can share project chats. Local /status and /debug-config already expose some effective settings. | Developer settings |
| E2 | Personalization controls vary by client; Codex personal guidance uses global AGENTS.md. Web Work has a writing-style feature. | Personalization |
| E3 | ChatGPT memory and local Codex memory are separate. Memory is recall, not a substitute for required project instructions. | Memories |
| E4 | New Codex Cloud tasks use published setup and retain independent saved state. This path excludes computer/browser use and personal local skill synchronization; the legacy integration path remains separate. | Cloud environments |
| E5 | Remote accesses host resources. Handoff transfers a chat and Git state between compatible hosts; Codex Cloud is not a handoff destination. | Remote connections |
| E6 | Work Sync applies to eligible new tasks. Work and Codex histories remain separate. Work cannot switch local execution to cloud during a turn. Dot and Work local grants and revocation behavior differ. | Work and Dots local access |
| E7 | A dot persists in cloud, has its own computer, and uses relevant ChatGPT memory and notes. Contact-channel messages remain in their channels. | Meet Dots |
| E8 | Dots already expose task activity and delegate separate conversations with selected context. Selecting another computer does not relocate an existing task. Run completion does not prove the outcome was delivered. | Dot tasks and memory |
| E9 | Linked sources retain their permissions. Content copied into a Page is visible to that Page’s readers; Page sharing does not share private chats or memory. | Space |
| E10 | A common plugin listing can contain capabilities specific to a surface or runtime. Web installation does not deploy local hook scripts. | Plugin architecture |
| E11 | Codex joined the desktop app July 9. The October 1 CLI release fixes uncertain queued submissions and preserves resumed settings. Existing improvements must be reused, not described as absent. | Dated changelog |
| E12 | September 29 adds Dots, Work Sync, Space, reusable cloud environments, extensions/events and Team Tasks. Team Tasks use service-account authority and approved connections. | DevDay 2026 |
| E13 | Requirements differ by orchestrator and executor; Work Cloud capability controls have their own scope. Local hook presence does not establish cloud hook execution. | Agent Security |
| E14 | App-server exposes thread, turn, item and lifecycle contracts. Its public integration command remains experimental; it is a contract reference, not a production deployment recommendation. | App-server, changelog migration note |
| E15 | A shared local thread link is a read-only snapshot, distinct from live continuation. | Feature digest |
| E16 | Local configuration has explicit precedence and trust rules; defaults cannot override enforced requirements. | Config basics |
The most consequential problems follow. P1 means work, trust or recovery can be materially affected; P2 means repeated confusion or friction. These are design priorities, not measured incident frequencies. No undocumented backend defect is asserted.
| Problem | Concrete scenario and evidence | Cause or hypothesis | Severity | Proposed fix |
|---|---|---|---|---|
| D1. Opaque behavior inheritance | The user opens Codex on web after desktop work and gets another style. Reported; E1–E3 establish different inputs. | Contract gap, inferred: the effective profile is not explained consistently across clients. Existing local diagnostics are a useful partial solution. | P1, trust | A common “What applies here?” view, with sources and scope; selectively portable preferences. |
| D2. Conversation discovery is mistaken for execution continuity | A desktop chat is hard to find on web; a shared link looks like a way to continue. E5, E6, E15. | Navigation problem plus legitimate ownership boundary: host access, sync and snapshots expose different objects. Private storage implementation is unknown. | P1, continuity | One permission-filtered activity index with stable IDs, availability and precise Continue actions. |
| D3. “Cloud” conceals capability differences | A coding task expects a browser or local skill because another cloud agent had it. E4, E7, E10. | Naming defect plus real runtime constraint: distinct cloud environments are presented through similar language. | P1, task feasibility | Capability-aware execution manifests and preflight checks; state missing dependencies before accepting a plan. |
| D4. Context containers imply too much sharing | A shared Page or project appears to imply shared chat memory, repository access or credentials. E3, E9, E13. | Semantic problem: context, artifact access, governance and filesystem location are different dimensions. | P1, authority; P2, organization | Project as a context grouping, Workspace as governance, Space as artifact view; explicit resource bindings and separate grants. |
| D5. Delegated progress and delivery are confused | A dot reports a finished coding run, but the user cannot tell which version was reviewed or where its output was delivered. E8 already provides activity and output views. | Hypothesis: lineage and acceptance contracts need consistent treatment across Work, Codex and team automation; absence is not established. | P1, outcome | Link responsibility → task → attempt → artifact version → review receipt; make task success evidence-based. |
| D6. Recovery and control semantics depend on mode | A computer disconnects after a command starts; another client offers Retry or Stop without clarifying whether the command ended. E6, E11, E13. | Reliability risk, not a reproduced bug: acknowledgments, grants, running commands and coordination have separate lifecycles. | P1, duplicate effects | Shared command receipts, explicit unknown outcomes, scoped cancellation and executor fencing; never infer stopped from disconnected. |
| D7. Rollout and migration are hidden in product labels | An older Work conversation behaves differently from a newly synced one. Plugin installation appears complete despite missing runtime assets. E6, E10–E12. | Compatibility seam: version, enrollment and task generation affect the contract. | P2; P1 when blocking | Show the conversation’s continuity class and negotiated capabilities; migrate via adapters and opt-in upgrade paths. |
Distinct local files, credentials, browser sessions, offline operation and operating-system features are legitimate constraints. They should remain distinct. Different chrome, code detail and review tools can also be useful. The repair is predictable semantics and visible boundaries; identical interfaces or pooled memory would create new problems.
2. Target product model
Everyday use needs three concepts: Chat is where you communicate, Task is an outcome being pursued, and Dot is an agent accepting ongoing responsibility. Project organizes related context and results. Run location says where tools execute. The selected Workspace supplies the ownership and governance boundary. Attempts, execution epochs and environment versions remain available in details.
| Term | Recommended meaning and relationship |
|---|---|
| Chat / conversation / thread | Show Chat in the interface; store a Conversation entity. “Thread” is an API/legacy alias, not another user concept. A conversation has ordered turns, references and task links. |
| Task | One objective, acceptance evidence, owner and status. A conversation can contain several tasks; a task has one primary conversation and may link other authorized conversations. Creating a child task creates explicit lineage and its own conversation. |
| Work | The outcome-focused task view. It is not another identity or history namespace in the target. |
| Codex | The developer task view and coding role profile. Switching to Codex changes available detail and tools, not the underlying Task ID. Keep Codex Desktop clearly named in launchers and documentation. |
| Agent / dot | Agent identity is separate from model and owner. ChatGPT and a coding delegate are role-bearing agents; a dot is a persistent agent assigned Responsibilities. Responsibility stores ongoing objectives, cadence, limits and associated tasks. |
| Run | A recorded execution attempt for a task or conversation turn. Retries get new Run IDs; changing clients does not create a run. A successful run is not automatically a successful task. |
| Project | A stable grouping of context, chats, tasks and artifacts. Repository paths are bindings, not identity. It can bind several repositories, targets and content sources. Membership never grants arbitrary host or connector access. |
| Workspace | Account/organization boundary for membership, ownership, retention and policy. Do not use this word for a temporary runtime directory. Call that an execution directory. |
| Space | The library and collaboration view over artifacts and projects. Preserve existing Page and Space links; content sharing remains resource-specific. It does not introduce another agent memory or permission system. |
| Environment / run location | Environment is versioned setup. Target is an executable computer or cloud runtime using that setup. Show “Runs on: Maya’s Mac — local worktree” or “Codex Cloud — storefront setup v3”, rather than bare “Cloud”. |
| Team Task | A scheduled/event-triggered Task Template with a team service-account owner. Each trigger creates a Task and Run under that authority. It is not a personal dot with implicitly expanded access. |
| Plugin / connection | Plugin is a versioned capability package. Connection binds an external account and grant. Installation, account authorization and deployment remain separate states. |
Navigation and defaults. Use the same Activity, Projects, Dots and Space destinations on web, desktop and mobile. Activity contains chats and tasks, with filters for ownership, project, attention and location. Preserve the selected workspace and open entity across clients. CLI and IDE address the same IDs through commands and links rather than reproducing every menu.
Chat/Work is a presentation switch within an activity. Codex is the developer view of the same model. If a user starts a bounded outcome from Chat, create a linked task visibly. Do not silently create another conversation or move execution. Desktop can default to Codex without changing the account’s personal profile.
New tasks use the portable personal profile within project and managed constraints. Existing tasks keep their compatibility profile until explicitly upgraded. Use an eligible cloud target when the declared resources support it; select a named computer when local resources are required. Automatic selection may use only already-authorized targets and must show its choice before the first tool action. A change in required resources or authority requires a new preflight.
3. Recommended architecture
Choose one logical activity contract with scoped authorities and pluggable executors. The design has four logical areas: activity/state, coordination, execution adapters, and context/artifact access. Profile resolution, capability negotiation and policy enforcement are shared contracts across those areas. They may be implemented in existing components; the boxes do not prescribe new microservices, databases or engineering teams.
Canonical ownership and identity
Assign opaque globally unique IDs, independent of client, URL, title or filesystem path. Offline clients can reserve IDs; creation becomes canonical only when the selected authority accepts it. Every entity carries workspace/owner, authority locator, revision, creation provenance and legacy aliases. A locator can change through explicit authority transfer without changing identity. Unauthorized clients cannot use a reserved ID to claim someone else’s entity.
| Entity | Authoritative owner / writer | Key relationships and lifecycle |
|---|---|---|
| Workspace and Principal | Existing identity/governance authority; person or service account | Membership and role revisions; lifecycle active, suspended, deleted. Workspace is not the agent. |
| Conversation and Turn | Selected conversation authority: hosted, or opted-in local host | Revisioned conversation; append-only accepted turns/events. Archive and deletion are distinct from stopping work. Local-private remains a supported continuity class. |
| Task and Responsibility | Task owner’s chosen coordinator; dot owns responsibility state on behalf of its principal | Parent/child links, primary conversation, acceptance criteria. Task: draft, queued, active, waiting, review, succeeded, failed, cancelled. Responsibility: active, paused, closed. |
| Run and Step | Coordinator owns command intent/ordering; executor owns signed or authenticated observations | Task/turn, attempt number, execution epoch, step receipts. Run: queued, preparing, running, waiting, cancelling, succeeded, failed, cancelled. Outcome certainty is separately known or unknown. |
| Agent and Task Template | Principal/governance authority | Versioned role, model reference, allowed delegation; template trigger and schedule revisions. Model updates do not change Agent ID. |
| Project and resource binding | Project owner; resource provider remains authoritative for actual access | Context manifest and target/repository bindings. active, archived, deleted. Paths and branch names are references. |
| Environment version and execution target | Environment publisher; selected runtime host owns live resources | Immutable published setup version; mutable target capabilities/liveness. Target: online, offline, incompatible, access-revoked. |
| Profile and resolved behavior | Profile owner edits versioned inputs; resolver records immutable effective snapshot per turn/run | Style, language, detail level, instructions and source provenance. Record unsupported fields and applied overrides. |
| Artifact and artifact version | Explicit artifact owner; existing Page/file/repository authority governs bytes and ACLs | Stable artifact ID, immutable committed versions, producer Run ID, source references, review and publication receipts. Git results include base/commit/patch hashes. |
| Grant and Approval | Authorizing principal or administrator | Resource/action scope, expiry, policy revision and bound action digest. pending, allowed/denied, consumed, expired/revoked. Agents cannot manufacture grants. |
“Succeeded” on a Task requires its acceptance criteria, verified artifact version and required review/delivery receipts. A transport acknowledgment, completed model response or green command exit is insufficient alone. Waiting has a reason: user input, approval, device, quota, dependency or uncertain outcome. Task progress derives from child dependencies; independent work can proceed while one child waits.
Client and coordination contracts
All interfaces consume the same entity summaries and issue versioned commands. A command includes entity ID, client-generated command ID, expected revision, authenticated actor, intent and correlation ID. Acceptance returns a durable receipt and committed revision; rejection identifies a conflict, missing capability, policy denial or invalid state.
Events carry event ID, entity ID, per-entity sequence, schema version and causation. Clients subscribe with a replay cursor. Gaps trigger snapshot plus replay. Client projections may be eventually consistent; there is no required total order across all projects or agents. Within each authority, accepted command intent and state transitions have a single serialized order. Task rollups can lag and expose their last confirmed revision.
Coordination persists plans, dependencies, budgets, schedules and delegation intent. Work supplies an outcome view; Codex supplies a coding role and developer view; Dots attach responsibilities and follow-up decisions; Team Tasks attach triggers and service-account ownership. All use the Task/Run contract. A child’s connection to its parent provides lineage, not access to all parent content.
Use existing app-server thread/turn/item concepts through versioned compatibility adapters. Stabilize the production contract internally before depending on experimental public integration commands. Existing runtimes remain the writers until an explicit per-entity cutover. Avoid two active coordinators for one task.
Profiles, context and artifacts
Separate portable preferences (language, tone, desired detail), client appearance, project instructions, role/skill instructions, executor setup, memory recall and managed restrictions. The resolver emits the effective result and source of each field. Configuration field precedence is not a universal instruction hierarchy. Required rules keep their existing authority; recalled text and external documents never become privileged instructions.
Snapshot behavior inputs at a turn boundary. New personal defaults apply to the next turn, with a visible change record; project, role and task overrides remain explicit. Policy revocation can invalidate a pending action immediately at the enforcement boundary. Never rely on a stale behavior snapshot as execution authorization. Export only selected portable fields from local setup; do not upload the whole configuration, local instructions, memories or secrets implicitly.
A Context Manifest records authorized source IDs, versions/hashes, purpose, sensitivity, provenance and allowed disclosure destinations. Recall from personal memory, local memory, dot notes, Computer History or project sources remains distinguishable. A delegated task receives a selected, versioned bundle or access references. Reads recheck provider permissions; cached retention follows the governing policy. Lost access stops new reads and new disclosure, but cannot erase an external action already completed.
An artifact’s owner and ACL are explicit. Copying material into a shared artifact is a disclosure decision, not automatic inheritance of source access. Existing Pages, repository commits and external files retain their own versioning/permissions through adapters. Links in the common index do not grant access. A local output is labeled local until an approved upload/publication creates a durable web-accessible version.
Capabilities and policy
Before execution, show a compact manifest: owner; agent; run location; files/repositories; connected accounts; browser availability; active skills/plugin deployment; approvals; continuity class; offline behavior. Details show environment, model and policy versions. Display unsupported operations with a reason and an eligible alternative, rather than allowing a misleading plan to proceed.
The effective allowed action must satisfy applicable workspace requirements, user/agent grants, connector permissions and executor restrictions. Policy evaluation retains field-specific precedence; it is not a simplistic merge of every setting. Coordination checks delegation and disclosure; the executor checks each tool action and resource access. Both use a policy revision and fail closed when a required enforcement contract is unavailable. Optional advisory hooks remain distinct from required enforcement.
Credentials stay in the owning host, vault or connection. An execution envelope carries a bounded capability reference, not a copied token. A plugin manifest declares runtime assets, supported surfaces and minimum versions. “Installed” can coexist with “not deployed on this target”; the user sees the difference.
Consequential alternatives. A single global store would make some queries simpler but would force unnecessary residency, privacy and migration decisions. A common visual shell alone would leave continuity ambiguous. Prefer federated existing authorities with canonical IDs, projections and explicit transfers. Some local-only conversations therefore remain unavailable on web; that limitation is labeled and user-selectable.
4. Continuity and failure behavior
Continuity class is explicit: Hosted, Synced with named computer, or Local-private. A hosted index may mirror only opted-in local metadata or transcript content. A saved local card can remain discoverable while its host is offline; it cannot promise transcript access or execution. Local-only operation continues without cloud dependency and without cross-device guarantees.
| State or resource | Synchronizes | Remains scoped / requires transfer |
|---|---|---|
| Accepted conversation turns, task status, lineage, approval decisions | Across authorized clients for hosted/synced entities; replayable with a cursor | Local-private data only if explicitly enrolled; channel transcripts retain channel boundaries. |
| Portable profile fields and project metadata | Versioned values and provenance | Client appearance, unmanaged device defaults and local instruction content need a selected import. |
| Artifact metadata and committed hosted versions | Stable links and ACL-filtered versions | Local bytes require approved publication; repository edits require Git/patch transfer. |
| Run intent and receipts | Coordinator/executor reconciliation | Process memory, open handles and partial command state are not portable. |
| Memory and context | Authorized references and selected bundles | No universal memory pool; local recall and private notes keep their scopes. |
| Files, credentials, browser sign-ins | Only approved file snapshots or provider access references | Local paths, passwords, cookies, device grants and running sessions never follow a chat automatically. |
| Event | Proposed deterministic behavior and user feedback |
|---|---|
| Delegation | Persist child creation intent and one command ID before launch; retries return the same child. Recover pending launches from durable intent, so a crash between saving and dispatch does not orphan work. Record sponsor, execution principal, context version and resource grants. Child rights cannot exceed the permitted delegation scope. |
| Scheduled / event work | Identify an occurrence by template revision plus occurrence/event ID. Duplicate delivery returns the same task. Record time zone, daylight-saving behavior, missed-run policy, overlap limit and event coalescing rule. Disabling a trigger prevents new occurrences without falsely cancelling an in-flight run. |
| Steering / simultaneous prompts | Serialize accepted turns. If a turn is active, expose Steer current run or Queue next turn consistently. Changes to task scope use an expected revision; incompatible simultaneous edits return a conflict with preserved drafts. |
| Concurrent artifact edits | Use compare-and-set versions for files/patches; return both revisions on conflict. Keep existing collaborative-document merge engines where available. Never overwrite unseen human edits. Review acceptance is bound to the reviewed version. |
| Approval | Bind to exact action, destination, principal, parameters/content digest, policy version, expiry and execution scope. One client’s accepted answer resolves the request for all. Changed scope, content or policy requires reevaluation; broader approval is a separate recorded grant. |
| Cancellation | Distinguish Stop attempt, Cancel task and children, and Disable future triggers. Persist requested state first; no new steps after effective cancellation. Show “Stop requested; confirmation pending” until executor acknowledgment or reconciliation. Existing side effects are reported, not described as undone. |
| Retries / lost acknowledgment | Reuse command ID for network retry; create a new Run ID for a genuine new attempt. Maintain per-step deduplication receipts. Read-only or explicitly idempotent operations can retry with bounds/backoff; externally visible writes need provider idempotency or reconciliation. |
| Duplicate prevention | Accept at most one active writer lease/epoch for a task attempt. Connectors pass stable operation IDs to providers that support them. Unknown write outcomes enter “Needs reconciliation”; never promise universal exactly-once external effects. |
| Offline device | Detect heartbeat loss and expire execution authorization for new steps. Mark observations stale; keep coordination and independent cloud children active. A command already issued may still be running. An unavailable device is different from revoked access. |
| Reconnection | Query last accepted command, step receipts, current process status and filesystem/version digest. Reconcile before retrying. Reject events from obsolete epochs as current state while retaining them as late observations for audit/recovery. |
| Executor change | Quiesce and checkpoint; reconcile outstanding effects; create a new Run with a new target/epoch and explicit resource manifest. Transfer approved snapshots or patches, not live processes. Revalidate policy, capabilities and context before dispatch. |
| Original executor unavailable | Preserve Task ID and report Waiting for computer. Permit a cloud continuation only for independent steps with already-available context. Do not rerun an uncertain mutating step elsewhere until its effects can be reconciled. |
| Permission removal | Reject new dispatch at the authoritative grant boundary and recheck each next tool step. Cooperating executors stop on revocation/lease expiry. Show delayed or unknown stop status; an unreachable OS process cannot be guaranteed instantly terminated. |
| Quota, model or plugin change | Keep checkpoints and explicit waiting/incompatible state. Do not silently replace an unavailable model, owner, target or plugin version for an existing run. Offer a preflighted next attempt. |
For synced execution, propose heartbeats every 5 seconds and 30-second dispatch leases. Every externally visible operation must validate a current capability at the gateway or cooperating executor. Long-lived native operations require supervision/cancellation where supported; where a runtime cannot enforce the lease, flag that limitation and prohibit automatic concurrent takeover. Standalone local-private work has a local authority and does not lose its local permissions merely because cloud is unavailable.
Record step intent before dispatch and persist its result receipt before acknowledging completion. Recover uncommitted publications through the same command ID and verified artifact hash. If a target transfer fails before cutover, the original target remains authoritative; after cutover, old-epoch results are reconciled as late observations rather than accepted as new commands. A fresh policy check accompanies every resumed step.
Proposed consistency targets. Acknowledged hosted commands survive a process restart within the configured fault domain (RPO 0 for that fault class). Replicated-region disaster objectives depend on residency and replication design and must be established before rollout. Connected-client state propagation: p95 ≤2 seconds, p99 ≤5 seconds. Host availability marked stale within 15 seconds; dispatch lease expiry within 30 seconds. Reconnect after reachability returns: p95 ≤10 seconds for status/receipt reconciliation. A missing acknowledgment never changes unknown into succeeded or failed automatically.
5. Complete proposed experience
Assume the user already created a dot on desktop/web, has an eligible mobile app/workspace, a published coding setup and a connected Mac with explicit local access. Assigning a responsibility on mobile is the starting action; this does not assume unsupported mobile dot creation.
| Step | What the user sees | Identity, ownership and execution |
|---|---|---|
| 1. Assign from mobile | “Investigate checkout complaints; prepare a fix and evidence. Keep monitoring for a week. Publish a private review Page in this project; ask before merging.” A responsibility card shows access and notification scope. | Responsibility R1 is assigned to Dot A1 for user principal U1 in Workspace W1. Primary chat C1; project P1. Schedule/expiry and publication scope are stored separately from active runs. |
| 2. Research in cloud | “Researching approved issue reports on the dot’s cloud computer.” The manifest shows connected accounts and source scope. | Task T1, conversation C2, research Run X1. Selected sources/versions enter Context Manifest K1. No local repository or browser session is implicitly available. |
| 3. Delegate coding | A visible child card: “Codex — prepare checkout fix — cloud setup v3”. Opening it shows the same ID from mobile, web or desktop. | Task T2 has parent T1 and its own conversation C3. Codex role uses Run X2 in the prepublished environment. Selected evidence from K1 is supplied; U1 remains owner. Parent chat access is not inherited wholesale. |
| 4. Request local verification | “The integration test needs Maya’s Mac and its private fixture. Runs locally; results stay private. No merge permission.” The target and grant are visible before dispatch. | Next attempt X3 targets the Mac’s isolated worktree with the approved patch/base hash. This target change is a proposed adapter capability, not today’s supported cloud handoff. Local credentials and fixtures stay on the Mac. |
| 5. Mac disconnects | “Local test status unknown. Waiting for Maya’s Mac. Cloud research can continue.” Retry does not silently start another local or cloud test. | The dispatched step S3 has a receipt but no final result. Its lease expires for new steps. T2 waits; T1 can continue independent research. No terminal result is invented. |
| 6. Reconnect and review on desktop | Activity opens T2, not a copied chat. “Test completed while offline; results recovered.” If receipts cannot establish completion, the UI instead offers reconciliation. The developer view shows patch, tests and profile sources. | The executor uploads its durable receipt and artifact digest. Coordinator reconciles S3 before dispatching further work. U1 reviews the exact patch/output version; permission to merge remains absent. |
| 7. Open result on web | The same task links to “Checkout fix review — version 4”, with sources, patch, test evidence and outstanding risks. “Monitoring remains active until October 10.” | The approved private Page artifact F1/v4 is published to the specified project audience, with a delivery receipt. T1/T2 finish only after their acceptance checks. R1 continues its separate responsibility lifecycle. |
If the computer never returns, the task remains intelligible and reviewable on all clients. The user can withdraw the local step or select an alternative using available resources; no automatic promotion of private fixtures, credentials or uncertain effects occurs. If this were a Team Task, a team principal would own its tasks and connections from creation; converting personal work into team-owned automation would require a separate transfer and grant review.
6. Phased migration
These are planning ranges and suggested responsibility areas, not claims about OpenAI’s organization or committed delivery dates. Assign one accountable program owner across product semantics, client contracts and runtime compatibility. Use cohort feature flags and stop at each acceptance gate.
| Phase | Work and dependencies | Suggested engineering responsibility | Gate | Rollback / existing work |
|---|---|---|---|---|
| 0. Clarity, roughly 0–3 weeks | Consistent run-location labels, continuity badges, effective-profile panel using existing diagnostics, and explicit snapshot/continue actions. Inventory unsupported capability states. | Client/product owners with configuration, permissions and support owners | ≥90% comprehension in cross-client scenario tests; no changed execution/configuration defaults | UI flags only; preserve old routes, settings, history and active behavior. |
| 1. Identity and read compatibility, roughly 3–8 weeks | Define canonical IDs, legacy alias resolution, summary schema, authority/ACL filtering and profile/capability versions. Read-through adapters index old Chat/Work/Codex/Dot/team objects. Depends on ownership inventory. | Identity, conversation/state and client contract owners | No alias collision; permissions match legacy authorities; index lag targets hold; offline entries clearly labeled | Turn off common projection and use original index. Old stores remain authoritative; no automatic upload of local-private content. |
| 2. Commands and recovery, roughly 8–16 weeks | Standardize command receipts, cursors, per-entity revisions, cancellation, approvals, step journals and fencing. Stabilize runtime adapters; shadow read comparison before enrolling new tasks. | Orchestration, runtime/host, connector and reliability owners | Fault-injection suite passes; no duplicate irreversible action in supported test contracts; uncertain outcomes stay unresolved | Route new tasks back to legacy adapters. Tasks already enrolled stay pinned to their known writer/contract until quiesced; never activate both runtimes. |
| 3. Profiles, context and target transfer, roughly 16–24 weeks | Selective profile portability, context provenance, artifact-version review and checkpoint/patch transfer. Depends on grant enforcement, receipts and resource manifests. | Personalization/context, artifacts, execution and policy owners | Equivalent effective profile for a declared profile; unsupported capabilities explained; target-transfer recovery and ACL tests pass | Preserve prior versions/checkpoints and target; offer explicit revert as a new attempt. No automatic rollback of external side effects or current human edits. |
| 4. Consolidation, gate-driven | Work/Codex/Dot/Team Task flows use the shared contracts. Retire redundant launch/history paths only after usage and compatibility prove replacement. | Cross-client product and integration owners | ≥99.9% eligible reopen success; migration acceptance below; legacy integration feature gaps closed | Keep alias redirects and read-only archive access. Retain legacy runtime path for unsupported code-review/integration features until replacement passes. |
Old conversations and tasks. Start by wrapping existing entities; retain content, IDs through aliases, permissions, creation provenance, mode and profile version. Do not rewrite history into a fictitious shared transcript. Historical artifact sharing does not become conversation sharing. Current runs finish under their original contracts. Enroll a stopped eligible task only after a comparison of profile, context, owner, target and grants, with a verified checkpoint and a reversible routing record. A local-private user can decline migration permanently.
Single-writer cutover. Freeze command admission briefly for an enrolled entity, reconcile outstanding receipts, record last source revision, create the destination projection, then commit a new authority epoch and alias redirect atomically at the routing boundary. Replay reads can continue during cutover. If finalization fails, the original writer resumes; after commitment, a rollback requires another quiesced transfer. Never solve migration by uncontrolled dual writes.
Retirement gate. Old routes can disappear from default navigation once aliases, archives and supported continuation work. A runtime can retire only after its integrations, permission semantics, history access and failure paths have proven replacements. Feature equivalence is per contract/capability, not a marketing-name match.
7. Acceptance criteria and measurement
All numbers below are proposed release targets, not current service guarantees or observed baselines. Measure the baseline first, segment by workspace, platform, runtime and continuity class, and report tails and errors. Fault tests must exercise delayed/lost acknowledgments and late effects, not only happy-path requests.
| ID / change | Observable acceptance and proposed target | Validation / rollout gate |
|---|---|---|
| A1. Shared discovery and IDs — D2, D7 | ≥99.9% eligible cross-client reopens retain the same Conversation/Task IDs, owner and primary lineage. Median find-and-resume time improves ≥50% from baseline. | Cross-client cohorts and alias fixtures; verify offline/private cases show appropriate unavailability. |
| A2. Profile visibility — D1 | ≥95% of participants correctly identify which tone/instruction/memory source applies. Same declared profile resolves to the same supported field values across clients; presentation may differ. | Field-level contract tests and user scenarios; unsupported fields and overrides must be visible. No requirement of identical model wording. |
| A3. Capability clarity — D3, D7 | ≥90% correctly predict resources, run location and offline behavior before starting. 100% of required unsupported capabilities in the conformance suite cause preflight rejection or an explicit alternative. | Usability sessions plus runtime-manifest fixtures including missing plugin assets and old client versions. |
| A4. State consistency — D2, D6 | Connected propagation p95 ≤2s / p99 ≤5s; status/receipt recovery p95 ≤10s after connectivity returns. Zero loss of acknowledged events under the specified restart fault model. | Replay tests, process restart and partition injection; measure authority acceptance separately from optimistic UI state. |
| A5. Duplicate control — D6 | No duplicate accepted command/child from 10,000 repeated delivery trials. No duplicate external write in supported provider-idempotency tests; 100% of ambiguous non-idempotent writes enter reconciliation instead of automatic retry. | Connector fixtures inject “performed write, lost response”; test expired dedup windows and late executor completion. |
| A6. Safe control — D6 | 100% of changed action digests/owners/policies invalidate stale approval in tests. No new supervised steps after lease expiry; stop UI distinguishes requested from confirmed. | Revocation, disconnect, cancellation and concurrent approval tests across every execution class. Count non-cooperating native operations separately. |
| A7. Coherent delivery — D4, D5 | Every completed task in the release suite has required acceptance evidence and artifact/review/delivery versions. Zero implicit cross-owner context grants in negative tests. | Run the full mobile-dot → cloud → local-disconnect → desktop-review → web-artifact journey with both success and unresolved outcomes. |
| A8. Compatibility — D7 | 100% of sampled legacy tasks preserve owner, history, original mode and links; no local-private upload without enrollment. No legacy path retired with uncovered critical fixtures. | Inventory-based migration tests, production read comparison and per-entity rollback exercise. |
Instrument command acceptance, event sequence lag, unknown-outcome duration, resume success and task-to-artifact delivery. Correlate Task/Run/Step IDs across coordination and executor telemetry without logging raw credentials, memory contents or private source text. Capture support reports of “wrong chat,” “different settings” and “where did it run?” as separate measures. Proposed SLOs must be validated before being advertised.
8. Decision limits and validation status
The private data stores, replication topology and staffing are unknown. Exact cross-inheritance of Codex Cloud personality/global guidance and the user’s two effective sessions remains unverified. Account rollout, runtime versions and workspace policy can change availability. The design therefore targets logical contracts; implementation discovery and comparative session traces are required before specifying physical migrations or explaining a particular style difference as fact.
Before implementation, establish the supported fault domain, transcript enrollment and residency rules, required connector idempotency/reconciliation support, and which native operations can be supervised. The short IDs in the walkthrough are explanatory aliases for canonical IDs. Existing public diagnostics and rollout capabilities should be reused after testing their actual account/version behavior.
Design coverage: SPECIFIED for the seven requested deliverables. Official boundaries E1–E16: SOURCE_REVIEWED, with exact retrieved-source hashes in the source-capture manifest. Runtime validation: AWAITING_LOCAL_RUN; execution status NOT_RUN. This is an architecture proposal without access to an OpenAI implementation. No OpenAI preferences, permissions or production behavior were changed.
First three changes to implement
- One activity index with stable continuation links. Make the same chat/task discoverable across clients, showing owner, location, continuity class and availability. Preserve local-private boundaries. This directly addresses lost chats and ambiguous continuation before requiring runtime convergence.
- One “What applies here?” profile view. Expose effective preferences, instruction origins, memory scope and overrides in every client, building on existing local diagnostics. This makes differences explainable immediately and provides the evidence needed for selective preference portability.
- One preflight and recovery contract. Show resources, capability limits and offline behavior before dispatch; retain command receipts and explicit uncertain outcomes. This prevents unsupported plans and unsafe retries, and makes subsequent executor unification achievable.
Maintained reference and applied comparison
Reference update, October 3, 2026: source-reviewed web/desktop comparison, three-scenario test protocol, and public field note. The field note's publication status is recorded separately from this architecture proposal.
Direct desktop UI automation was rejected by Computer Use for safety reasons. The comparison therefore applies documented contracts and the supplied screenshot; matched effective-profile traces, eligible same-ID reopening and host-disconnection trials remain NOT_RUN. No workaround, preference change, permission change or network-disconnection experiment was attempted. The proposal's implementation and numerical targets remain untested.