Unified ChatGPT Work/Codex desktop UI makes the active execution mode unclear #33475

What variant of Codex are you using?

Unified ChatGPT desktop app / Codex desktop app, observed on macOS in the current unified Work/Codex interface.

What issue are you seeing?

The new unified desktop interface makes it difficult to tell whether the current conversation is actually running as ChatGPT Work, ordinary Chat, or a Codex task with local project context.

In the sidebar, the product area can show ChatGPT Work, which naturally suggests that the user has switched into a Work-style task environment. However, the currently opened thread can still behave as a Codex task because it retains a local project binding and Codex execution context. From the user's perspective, the UI label and the actual runtime behavior do not clearly match.

This creates confusion around important safety and workflow questions:

• Can this assistant access local project files?
• Can it run commands or tests?
• Is it operating as a general Work assistant or as a repository-aware coding agent?
• Did switching the top-level area change only the navigation surface, or did it change the thread's actual execution mode?
• Is a projectless Codex chat equivalent to ChatGPT Work, or are there still Codex-specific defaults and assumptions?

The current design makes the Work/Codex distinction feel ambiguous. The UI looks unified, but users still need to understand which capability boundary is active for the current thread. That boundary is not visible enough.

What steps can reproduce the issue?

1. Open the new unified ChatGPT desktop app.
2. Navigate to the ChatGPT Work area in the left sidebar.
3. Open or continue a thread that was created from, or still carries, Codex/local-project context.
4. Ask the assistant what mode the current conversation is in.
5. Observe that the visible UI may indicate ChatGPT Work, while the assistant/runtime still identifies the task as Codex because local project context and Codex engineering instructions are active.

What is the expected behavior?

The app should make the current execution mode and context boundary explicit, not just the top-level navigation area.

Possible improvements:

• Show a persistent badge such as Chat, Work, Codex, or Codex: local project attached in the thread header.
• Clearly distinguish between switching the product area and changing the actual thread runtime/context.
• Warn or explain when opening a Codex-context thread from inside the Work interface.
• Make project binding visible: No project attached vs Project attached: <name/path>.
• Use stronger visual separation, separate windows, or clearly separated task containers for Work vs Codex if they have different runtime semantics.
• Provide an explicit promote/switch action when a user wants to turn a general Work/Chat conversation into a Codex task with local execution tools.

Why this matters

This is not only a cosmetic issue. The mode boundary affects user trust and safety. Users need to know when the assistant is merely chatting or researching versus when it has access to local files, repository instructions, shell tools, tests, and coding-agent behavior.

In the current unified UI, the user can reasonably believe they are in ChatGPT Work while the thread still carries Codex behavior. That mismatch costs time and makes the product feel internally inconsistent.

Related issues

Related to #33112, which requests first-class Chat and Study modes with separate runtime contexts. This issue is narrower: the current Work/Codex UI should clearly expose the active execution mode and project attachment state for each thread.

Additional information

This confusion happened while trying to understand the new ChatGPT Work vs Codex desktop experience. The user had to ask the assistant why the UI showed ChatGPT Work while the assistant still identified the active task as Codex.

If this is an intentional product model where navigation area and execution mode are separate, the UI should explain that distinction directly. If it is not intentional, Work/Codex switching should create a more obvious mode transition so users can reason about the current task safely.

This caused avoidable confusion and usage friction for a paying user. If account-level goodwill credit or usage adjustment is available for users affected by this rollout confusion, please route that request to the appropriate support path.