I used to have a workflow that felt natural.
ChatGPT was where I explored. When an idea had no clear boundary yet, I asked questions, tested directions, discarded half of them, and narrowed what remained.
Codex was where I entered a local project. It read the repository, ran commands, edited files, and inspected logs. Once a task touched code and a real workspace, I moved there.
Recently I used Work for a complete cloud task: research, judgment, and a slide deck. The deliverable was fine.
The friction came from the new desktop entry points.
Before the same task could begin, I had to answer an extra question: should it go to Chat, Work, or Codex?
Three entry points, each with a sensible job
OpenAI describes the split clearly. Chat handles quick questions, search, and conversation. Work handles research, analysis, and deliverables such as documents, spreadsheets, presentations, reports, and Sites. Codex is for code, tests, commands, and repositories.
That division makes sense in isolation. A task rarely grows along product boundaries.
I may begin in Chat to find the question. Once the judgment sharpens, I want Work to organize research and create a shareable document. When that document needs a site, data, or a script, I move to Codex.
The task did not change. I became its router.
Continuity becomes manual work for the user
The official documentation is explicit: cloud Work chats can sync across web, mobile, and desktop. Codex remains a separate view, with history separate from ChatGPT history. Local chats remain on the computer.
Those boundaries have sound reasons in implementation, permissions, and use cases. The user still feels their consequences.
Every time I cross an entry point, I have to restate the task: what I am doing, what I already found, which judgments are settled, which files are in scope, and who the final result is for. A model can reconstruct some of it. The project can move forward. The work has already been fragmented.
The system manages kinds of work. The user maintains the life of one task.
More entry points create a routing cost
Choosing a tool used to mean choosing a capability: write in a document, code in an editor, meet in a video app.
Agent tools add another decision. You must decide where a task’s context lives, which history carries over, which environment owns the files and permissions, and whether it can continue on another device.
The cost is subtle. At the beginning of a task, people shrink their goal to avoid choosing the wrong place. Work that could have opened up becomes “let me ask a couple of questions here first.” An idea that belongs in a project remains trapped in an isolated conversation.
Put the task before the entry point
A smoother workspace does not need to collapse Chat, Work, and Codex into one undifferentiated tool. They can retain different permissions, environments, and execution modes.
The task should be the first-class object.
Within one task, I should be able to chat, launch research, and enter a local repository. The system should show what crosses the boundary, what remains local, and what needs renewed permission. The task history should show those handoffs instead of leaving several conversations that cannot see one another.
The entry points can remain. They should not require the user to route the system before work can start.
I do not object to Work, Chat, and Codex existing separately. I do not expect every piece of context to be shared without conditions.
I care about who keeps a task intact when it has to cross between them.