Skip to content

Add first-class Chat and Study modes with separate runtime contexts #33112

Open
Open
Add first-class Chat and Study modes with separate runtime contexts#33112
Labels
appIssues related to the Codex desktop appenhancementNew feature or request

Description

@Yuimi-chaya
Yuimi-chaya
opened on Jul 14, 2026

What variant of Codex are you using?

Unified ChatGPT desktop app (Codex/App surface)

What feature would you like to see?

Add Chat and Study as first-class top-level modes alongside the existing Work and Code modes, with a separate runtime context for each mode rather than only different UI labels.

Chat mode

Chat should provide a lightweight, general-purpose conversation environment comparable to ChatGPT on the web. A new Chat thread should:

  • not require or create a local workspace;
  • not inject the current directory, repository metadata, AGENTS.md, or other project instructions;
  • not load the Codex coding-agent prompt or assume that the user wants files edited, commands executed, tests run, or a task delivered;
  • keep local filesystem, shell, Git, and coding tools disabled unless the user explicitly promotes the conversation to Work or Code;
  • use the general ChatGPT conversation behavior and show regular ChatGPT conversation history.

This distinction needs to exist at the runtime/prompt level. A projectless Codex thread is not equivalent if it still receives Codex-specific instructions and treats the conversation as a coding task.

Study mode

Study should use a separate teaching-oriented initial prompt and interaction policy. It should optimize for helping the user learn rather than immediately completing the task. Expected behavior includes:

  • asking about the learner's goal and current level;
  • using guided explanations and Socratic questions;
  • providing hints before complete solutions when appropriate;
  • generating exercises, checking answers, and adapting to demonstrated understanding;
  • supporting documents, code, mathematics, and other learning material without assuming a software-engineering workspace;
  • allowing the user to explicitly switch to Work or Code when they want an artifact produced or a project modified.

Suggested information architecture

  • Chat: lightweight conversation, no workspace or Codex prompt injection by default
  • Study: tutoring and guided learning
  • Work: general agentic work with files, apps, and tools
  • Code: repository-aware software engineering

Threads should clearly display their active mode and permission/context boundary. Switching or promoting a thread between modes should be explicit so the user understands when workspace context and execution tools will be introduced.

Acceptance criteria

  • The unified desktop app exposes Chat and Study as first-class modes.
  • A Chat thread can be created without a generated workspace or local project context.
  • Chat does not receive Codex-specific engineering instructions or repo-level instruction files by default.
  • Study uses a documented, teaching-oriented behavior profile distinct from Chat, Work, and Code.
  • The UI clearly communicates which mode, tools, permissions, and context sources are active.
  • Users can explicitly promote a Chat or Study thread to Work or Code while preserving conversation context.

Additional information

The unified app currently presents Work and Code as its primary environments. General conversations can therefore end up categorized under a coding workspace and run with Codex-oriented context even when the user only wants to talk. This makes the product name and behavior feel inconsistent and adds unnecessary agentic assumptions to casual conversations.

Related issues:

The goal is not to reduce Work or Code. It is to make the unified application honest and predictable about which interaction model is active.

Activity

  1. github-actions
    added
    enhancementNew feature or request
    appIssues related to the Codex desktop app
    on Jul 14, 2026

  2. github-actions commented on Jul 14, 2026

    @github-actions
    github-actionsBot
    on Jul 14, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. Dohyeon2006 commented on Sep 16, 2026

    @Dohyeon2006
    Dohyeon2006
    on Sep 16, 2026 – with ChatGPT Codex Connector

    Cross-platform reproduction: Study Mode missing from the unified desktop app

    I can reproduce the missing Study Mode across three desktop platforms using the same ChatGPT Pro account:

    • Web: Study Mode is available and works.
    • Windows 11 LTSC desktop app: searching for Study or 学习 in the + menu returns No results / 无结果.
    • Debian 13 desktop app: Study Mode is absent.
    • Fedora 44 desktop app: Study Mode is absent. This is the machine currently being used.
    • Plan: ChatGPT Pro.

    Because the same behavior occurs on Windows 11 LTSC, Debian 13, and Fedora 44, this does not appear to be OS-specific. It looks more like the unified desktop surface does not expose Study Mode, or desktop is excluded by a feature flag.

    There is also a documentation inconsistency:

    • The current dedicated Study Mode help article lists availability on web, iOS, and Android.
    • The July 29, 2025 ChatGPT release notes state that Study Mode works on iOS, Android, web, and desktop.

    Expected behavior

    Either:

    1. expose Study Mode as a first-class option in Chat on the unified desktop app, with parity with the web experience; or
    2. clearly document that desktop support was removed or is currently unsupported, instead of returning no result in the tool search.

    A screenshot shows the Chinese query 学习 returning 无结果. Exact desktop app build numbers can be supplied if maintainers need them.

  4. Yuimi-chaya commented on Sep 16, 2026

    @Yuimi-chaya
    Yuimi-chaya
    on Sep 16, 2026
    Author

    One clarification on the intended end state: this request is not only about exposing the Study or Chat UI from ChatGPT Web in the desktop app. We ultimately want Study and Chat to be independently driven by the Codex harness itself.

    In practical terms, both modes should be usable with a user-configured API base URL and API key, while retaining their own isolated prompts, context boundaries, and tool policies. They should be native capabilities of the Codex harness, rather than features that only exist when backed by ChatGPT Web.

  5. Dohyeon2006 commented on Sep 20, 2026

    @Dohyeon2006
    Dohyeon2006
    on Sep 20, 2026 – with ChatGPT Codex Connector

    Implementation triage: reuse existing environment/provider support, add an explicit runtime-mode contract

    Following the clarification that Chat and Study should be native harness capabilities, here is a source-based implementation breakdown. This is static analysis, not a desktop reproduction or an implemented/tested fix. Source snapshot: bba48e5.

    Existing building blocks

    • ThreadStartParams already supports base_instructions, developer_instructions, provider selection, and experimental environments. Its documented environments: [] semantics disable environment access for turns without an override. There is no dedicated Chat/Study interaction-mode field in this struct. Reusing the environment mechanism seems preferable to inventing a parallel workspace subsystem; an empty environment selection alone is not the complete mode contract.
    • load_project_instructions combines host-provided user instructions with discovered project instructions. Chat/Study isolation therefore needs to cover both host-supplied context and automatic discovery, not just removal of one AGENTS.md block after assembly.
    • ToolRouter maintains model-visible specs and an executable registry, including deferred discovery and nested dispatch. A mode policy should constrain both advertisement/discovery and execution; hiding a button or telling the model not to use a tool is insufficient.
    • ModelProviderInfo already exposes base_url, env_key, and requires_openai_auth. This can be reused. Its WireApi currently accepts responses and explicitly rejects chat: a Chat interaction mode must not be confused with Chat Completions protocol support. The initial compatibility target should be a Responses-compatible custom endpoint, not an unspecified promise to support every API provider.

    Suggested implementation split

    1. Harness contract first. Introduce an explicit, persisted interaction profile for Chat/Study, separate from the existing tool-dispatch ToolMode. Select a conversation/teaching prompt instead of layering it over the coding-agent prompt. Default to no attached execution environment or ambient project context. Enforce a capability allowlist in the runtime; preserve all applicable managed restrictions. Ordinary configuration or turn overrides must not silently restore local execution. Existing clients that omit the new field should retain existing behavior.
    2. Explicit transitions. Promoting a thread to Work/Code should require user action and workspace/permission selection, rebuild the active context/tool policy, and preserve conversational content. Resume, fork, and compaction must retain the mode boundary. For a reverse transition, define how earlier project-derived context is handled rather than implying that changing modes erases information already supplied.
    3. Desktop integration separately. Add the mode selector and a visible effective context/permission summary. Treat ChatGPT history integration and the reported missing Study menu entry as a separate product-integration track; they should not make API-key-backed harness modes depend on ChatGPT Web.

    Proposed acceptance tests

    • Start Chat/Study while the host is inside a repository containing sentinel AGENTS.md text: assert no automatic workspace creation and no ambient project text/path in the assembled model request. Explicitly supplied learning material remains usable.
    • Assert that local filesystem/shell/Git/coding capabilities are absent from the available tool surfaces, and that attempts to invoke excluded capabilities through direct, deferred, or nested routes fail before any side effect.
    • Attempt to reintroduce an execution environment through a later turn override without promotion: reject it. Repeat isolation checks after resume/fork/compaction.
    • Verify distinct Chat/Study prompt assembly; separately evaluate Study behavior on hinting, checking understanding, and adapting explanations. Prompt snapshots alone do not establish teaching quality.
    • Exercise both modes against a mock Responses-compatible custom endpoint with API-key configuration and no ChatGPT login, without exposing secrets in prompts or logs.
    • Verify explicit promotion and confirm that clients without the new mode field retain their existing behavior.

    Could maintainers confirm whether this harness-first scope fits the intended direction, with desktop/history integration tracked separately? The desktop UI omission and a feature-flag cause have not been established by this source review; no desktop build or runtime tests were run.

  6. jeonghakhui-art commented on Oct 20, 2026

    @jeonghakhui-art
    jeonghakhui-art
    on Oct 20, 2026 – with ChatGPT Codex Connector

    Please preserve the quality of open-ended Chat, not only its UI

    I support this request to make Chat and Study first-class modes alongside Work and Code. I would like to add a concern that goes beyond the interface and runtime separation: Chat should retain the ability to be a thoughtful, context-aware conversational partner, even when there is no task to complete.

    I use ChatGPT both to get real work done and to explore ideas through everyday conversations. Some discussions begin with nothing more than curiosity and move between technology, economics, history, personal experiences, or seemingly unrelated topics. There may be no predetermined objective or deliverable.

    Most of those conversations will not immediately produce anything tangible. But sometimes, a connection to something discussed days or weeks earlier leads to an idea that can eventually be tested or implemented using Work or Codex. That may happen once a week, once a month, or not at all for some users. A conversation should not have to generate a measurable outcome to be worthwhile.

    A related concern: conversational continuity and understanding

    In recent use, I have noticed more instances where ordinary Chat does not proactively consult relevant long-term or Project context. Instead, it may rely on the latest messages, guess what the user meant, or turn an exploratory remark into a goal-oriented response. Sometimes the relevant information can be recovered only after repeated requests to check earlier context.

    I am describing the user-visible behavior, not claiming to know its internal cause. A related report is #48718, concerning ChatGPT Projects failing to proactively use relevant Project Sources.

    For long-term users, having to repeatedly correct interpretations and direct the assistant to previously available context is a real regression in the experience of thinking together.

    What I hope this proposal will preserve

    1. Genuinely first-class general Chat behavior, not merely a Chat button attached to a coding-agent or task-completion prompt.
    2. Room for exploration without a required goal. Curiosity, reflection, and conversation should not automatically become plans, action items, or deliverables.
    3. Meaningful long-term contextual understanding. Earlier conversations and relevant Project sources can be essential not just for tracking requirements, but for recognizing unexpected connections between ideas.
    4. Conversation-quality evaluation independent of task completion. Listening to what the user actually means, retaining nuance, recognizing when no action is requested, and reasoning across topics and time are valuable capabilities.
    5. A natural path from conversation to execution when the user chooses it, preserving the relevant context when moving to Work or Code, without requiring every conversation to start in an agentic mode.

    I value Work and Codex and want their execution capabilities to improve. But it would be a serious product loss if better task execution came at the expense of thoughtful, open-ended conversation.

    Please do not let ChatGPT become better at completing tasks by becoming worse at having meaningful conversations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions