[Bug]: clear command does not reset context for codex #7402

Activity

1. nleborgne

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Aug 18, 2026
2. nleborgne

   changed the title [-][Bug]: reset command does not reset context for codex[/-] [+][Bug]: clear command does not reset context for codex[/+] on Aug 24, 2026
3. yanqingcheng commented on Aug 24, 2026

   

   yanqingcheng

   on Aug 24, 2026

   More actions

   Independent reproduction on T3 Code 0.0.33, with the server running on Linux and the command submitted from the mobile client. This suggests the issue is not limited to macOS or the web UI.

   The persisted orchestration event sequence makes the failure mode fairly explicit:

   1. /clear is stored as an ordinary thread.message-sent user message.
   2. T3 immediately emits an ordinary thread.turn-start-requested.
   3. The same T3 thread and Codex provider session continue; there is no clear/new-session lifecycle event.
   4. The following Codex turn reported about 63.8k input tokens (62.2k cached), and the assistant could still answer from messages sent before /clear.

   The especially confusing part is that the assistant may respond as though the command worked, because it receives /clear as natural-language input while retaining the old context. A safe interim behavior would be to reject or visibly mark unsupported reset commands rather than send them to the model as ordinary prompts.

   Current workaround is still to create a new T3 thread.
4. bathan commented on Sep 10, 2026

   

   bathan

   on Sep 10, 2026

   More actions

   Reproduced with the Cursor provider (Claude model) on desktop, so it is not Codex-specific. Same failure mode: /clear (and /compress, which is not a command anywhere) reaches the agent as ordinary user text, the agent improvises a "cleared" or "compressed" reply, and the thread carries on with the full context.

   Filed the feature side as an Ideas discussion — a native /clear that resets the provider session in place, and until then rejecting unsupported reset commands instead of forwarding them: #11091
5. w00dy1981 commented on Oct 7, 2026

   

   w00dy1981

   on Oct 7, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction / workflow impact (8 October 2026):

   I use T3 Code to keep a complete task lifecycle in one thread, from Opus-heavy discovery through implementation with GPT-6 Sol, PR review and finally settling the thread once the PR is accepted.

   After an Opus discovery session, I select /clear from the suggested supported slash commands and submit it. The context does not appear to reset. When I switch the same thread from Opus to GPT-6 Sol, Sol still receives a nonzero amount of the preceding Opus context.

   What I want is a fresh provider/model context within the existing T3 thread, while keeping the visible thread history, worktree/branch and PR association, so I can track one task in one place and settle it at the end. Starting a separate T3 thread defeats that workflow.

   Expected:

   1. /clear genuinely resets the model context for subsequent turns (including across model/provider switches).
   2. The existing T3 thread, its visible history and task tracking remain intact.
   3. T3 should not advertise or silently forward /clear as a supported command if it cannot perform that reset.

   This is an observed behaviour report, not a claim about the precise internal cause. Related feature discussion: #11091.