Feedback based on user-side black-box testing, 1 October 2026 (Asia/Shanghai)
Environment: The reported tests used the same ChatGPT Plus account in the iPhone app and ChatGPT Desktop on macOS. At report preparation, the desktop environment was verified as macOS 26.6.2 (build 25G83) and ChatGPT Desktop 26.928.20755 (build 12246). These captured versions should not be assumed to match every test session. The iOS app version, model and reasoning selections, and Memory settings were not fully recorded; I am not guessing them.
Summary
Across Chat, Work Local/Remote, Codex, and Projects, different capabilities are reasonable. The concern is that project identity, execution location, agent specialization, synchronization, and memory scope are difficult to distinguish and appear coupled.
The key reported case is the synced ChatGPT Project “mode test.” Remote Work showed cross-conversation summaries; the Local session received Desktop Work/Codex-style agent context. But Local made history/tool calls before its final answer, so that answer cannot isolate what automatic context alone would support. This raises a Project-continuity concern, with the limitation that the Local result mixes supplied summaries and later retrieved material.
Please route this report to the ChatGPT Desktop / Work / Codex product team to investigate automatic project-context continuity across execution modes. If the observed differences are intentional, please document the included context sources and expose their scope to users.
What I observed
These are user-reported black-box observations, not confirmed internal facts, and not every case had strict controls; the protocol below is a proposed repeat. Distinguish account Personal Memory, automatically supplied session context, and explicit history/file retrieval. Model and Memory settings were not fully documented in the available record, which limits a controlled comparison. Personal-background knowledge alone cannot identify a backend because the same fact may enter different summaries. The claim concerns visible continuity and source transparency, not proven memory routing.
-
Ordinary Chat showed cross-device personal-memory continuity. On iPhone and Desktop Chat, questions about previously stored personal background received similar answers, consistent with account-level Memory continuity.
-
Desktop Work Local and Codex appeared to share agent-oriented automatic context. Their visible work, workflow, project, and study summaries were similar and differed from ordinary Chat’s personal-background context. This is not proof of internal architecture.
-
Cloud Project synchronization worked. The “mode test” Project, first created on iPhone, appeared in Desktop ChatGPT Projects after waiting or refreshing. The Remote Work conversation also appeared in Desktop Recent with a cloud/remote indicator. I am not reporting a persistent sync failure; there may have been initial refresh latency.
-
The project lists appeared to expose different subsets. Desktop ChatGPT Projects showed both cloud ChatGPT Projects and local projects. The same local projects were available from Desktop Codex, but the synced cloud “mode test” Project was not visible in Codex Projects. In this test, Desktop ChatGPT therefore behaved like a union view (cloud plus local), while Codex showed the local-project subset. Local projects could be opened from both Desktop ChatGPT/Work Local and Codex.
-
The same synchronized Project raised a Remote/Local continuity concern. Remote Work appeared to have recent cross-conversation summaries, not the full transcript. Local’s supplied context included a Desktop agent-style summary, but stable continuity with the Remote experiment was not established. Local made history/tool calls before its final response, so that response was already informed by explicit retrieval and cannot isolate what the initial context alone supported. A repeat should capture the initial context and first response before any calls.
Before its final answer, Local explicitly searched local
MEMORY.mdand app history, retrieving accessible user/assistant transcript material from this Project and another Chat. Local can therefore retrieve history; that is distinct from automatic injection. Remote later corrected its claim that it definitively used Chat Memory. Answers do not establish source or provenance. -
Remote-to-Chat context appeared summary-level. A distinctive test sentinel, “海盐-蜻蜓-7392,” was created in Remote Work. Later, ordinary Chat recognized the sentinel and the general subject/conclusion of the Remote experiment, but could not reproduce the complete original Remote prompt. This is consistent with summary-level cross-conversation context, not proof that Chat and Remote share a full transcript or a particular memory service.
-
Execution locations were observably different. Remote Work ran in a hosted Linux workspace; Desktop Work Local indicated it ran on the computer. Their file/tool access can differ. Whether execution also changes automatic memory scope needs a controlled repeat.
A compact view of the observed project lists is:
Projects
├── Cloud Project: iPhone ChatGPT + Desktop ChatGPT
└── Local Project: Desktop ChatGPT + Desktop Codex
Desktop ChatGPT view = Cloud + Local (observed)
Desktop Codex view = Local subset (observed)
The central comparison to verify is:
Same synchronized Project: “mode test”
|
+---------+----------+
| |
Remote Work Local Work
| |
cross-chat / Desktop agent-style
account-style supplied summary
summaries (clean automatic
(not full transcript) continuity test needed)
Recommended controlled reproduction
The steps below separate observations reported from the stricter controls needed to verify automatic context. In particular, capture the initial context and first answer before any file or history calls.
-
For each run, record account, client versions, model/reasoning selection, and Memory settings; the desktop versions captured at report preparation are listed above.
-
In fresh ordinary Chat on iPhone and Desktop, compare a known, non-sensitive personal-background fact. Separately start fresh Desktop Work Local and Codex sessions. Record the automatically supplied context before any file, memory, or history calls, and compare whether their agent summaries are similar. Do not treat an agent’s explanation of where its context came from as provenance evidence.
-
Create a cloud Project on iPhone, wait or refresh until it appears in Desktop ChatGPT, and verify that it is the same Project record with the original conversation—not a different Project that merely has the same name. Check its visibility in Desktop ChatGPT Projects and Desktop Codex Projects after synchronization.
-
In Remote Work inside that Project, ask about the recent Chat experiment, then introduce a new harmless sentinel and save the exact question text. Return to a fresh ordinary Chat and ask separately about the experiment, the sentinel, and the complete original question. Record whether it recognizes the general summary, the marker, or exact wording; do not assume that recognition means full transcript access.
-
After allowing synchronization and refreshing the project list, start a new Local Work conversation inside that exact synced Project. Before any tool, file, or history calls, capture the context already available and ask what it knows about the Remote experiment and marker. Preserve the initial response separately from any later research.
-
Only after recording that result, test explicit history retrieval as a separate phase and note which accessible sources were searched. Retrieval success does not show that the material had been injected automatically. Repeat with a clean conversation if the first response was affected by tool calls.
Product interpretation
These observations fit different user-visible context behaviors but prove no separate backend services. Users naturally expect a Project’s goals, terminology, decisions, progress, constraints, and open issues to persist across devices and execution locations.
Project synchronization without reliable, visible automatic Project-context continuity gives users only partial continuity. Cloud versus Local should determine where a step runs, not silently which context it receives. Switching Remote to Local inside one Project should preserve Project context.
A useful product model would make these six dimensions explicit and independent:
-
Conversation type: Chat or Work.
-
Project identity: the shared workspace and its persistent project context.
-
Execution location: Cloud or Connected Desktop.
-
Agent specialization: General or Coding/Codex.
-
Memory scope: Project, Work/Agent, and Account/Personal.
-
Synchronization scope: which Project data and resources sync across devices or remain linked to a desktop.
Resource location and availability should also be visible—for example, whether a linked desktop resource is online or offline—instead of inferred from the surface on which a Project appears.
Proposed direction
1. Add stable Project Memory and explicit memory controls
Use three distinct scopes:
-
Account / Personal Memory: durable user background and preferences.
-
Work / Agent Memory: working habits, tools, and agent-level preferences.
-
Project Memory: this Project’s goals, terminology, decisions, progress, constraints, preferences, and open issues.
Project Memory should remain available to Chat, Remote Work, and Local Work in the same Project, subject to the user’s permissions. Give users direct controls such as “Project only,” “Project + Work,” and “Project + Work + Account,” or separate toggles for each scope. This supports both a clean, isolated workspace and a more personalized one. The controls should describe what context is included, not require users to infer it from choosing Chat, Work, Local, Remote, or Codex.
2. Make Work one logical task with Cloud or Desktop execution
Treat Local and Remote as execution locations for a Work thread. If a step needs a connected computer, explain that requirement and its status—for example, “This step needs your Mac” or “Local folder unavailable — Mac offline.” Keep the Project and conversation visible when the device is unavailable. The user should be able to resume the same work when switching between phone, cloud, and a connected desktop, with memory scope preserved.
3. Make Codex a Coding specialization within Local Work
Desktop Work Local and Codex appeared to overlap in local projects, agent-oriented context, files, and tools. Consider presenting Codex as the Coding specialization, preset, or toolset within Work Local, while retaining the Codex name and coding experience where useful. This would reduce the need to understand separate Work Local and Codex workspaces and project lists without removing coding-specific capabilities.
4. Treat a Project as one logical container and label resource locations
Desktop ChatGPT already appeared to combine cloud Projects and local Projects, while Codex displayed local Projects only. Move toward one Project identity that can contain cloud context and resources linked to a desktop. On every surface, clearly label each Project and resource, for example:
Project: mode test
☁ Cloud Available
▣ This Mac — project folder Offline
A phone should still show the Project when a linked desktop is offline, with a clear unavailable status. Labels should tell users whether a Project syncs across devices, which computer owns a local resource, whether that computer is online, and whether the current Work step can use the resource.
Desired model
Independent dimensions:
Conversation: Chat | Work
Project: shared identity
Execution: Cloud | Connected Desktop
Agent: General | Coding (Codex)
Memory: Account | Work/Agent | Project
Sync scope: Cloud data | Desktop-linked resources
Project
├── Chat
└── Work thread
├── Execution: Cloud | Connected Desktop
└── Specialization: General | Coding (Codex)
The core request is to separate conversation type, Project identity, execution location, agent specialization, memory scope, and synchronization scope. Keep Project Memory stable across Chat, Remote Work, and Local Work; let Cloud or Connected Desktop determine execution; and let users choose whether Account and Work/Agent Memory are included. This would make the product’s behavior predictable while preserving meaningful differences between cloud resources, local tools, and specialized agents.