Skip to content

[Bug]: Codex /goal clear is sent as a chat message instead of clearing the persisted goal #13252

Description

@f-trycua

Before submitting

  • I searched existing issues and did not find a duplicate of this clearing behavior.
  • I included enough detail to investigate the problem.

Area

apps/desktop / Codex provider

Problem

Clearing an existing Codex Goal does not seem to be supported through the T3 Code chat composer. Sending /goal clear by itself reached the assistant as an ordinary user message, and the persisted Goal remained unchanged.

Steps to reproduce

  1. Open a Codex-backed thread with an existing persisted Goal. The observed Goal was in blocked status.
  2. Enter /goal clear by itself in the chat composer and submit it.
  3. Inspect the persisted Goal through get_goal or the Codex app-server thread/goal/get API.

Expected behavior

Clear the attached Goal and show confirmation, without deleting the thread or project files. If this command is unsupported, show an explicit unsupported-command message and an available Goal-management action rather than silently submitting it as conversation text.

Actual behavior

The assistant received the literal /goal clear message. A subsequent Goal read returned the same existing Goal in blocked status. This is a client command-handling observation, not a confirmed diagnosis of the underlying implementation.

Backend check / workaround

Calling the supported Codex app-server thread/goal/clear API for the same thread returned {"cleared":true}. A subsequent thread/goal/get returned {"goal":null}, and the assistant-side get_goal also confirmed that the Goal was gone. A replacement Goal could then be created successfully.

This required using the Codex CLI app-server API outside the T3 Code composer; there was no obvious in-app route for the user.

Version / environment

  • Installed T3 Code (Alpha) app version: 0.0.42. Exact running frontend commit was not captured.
  • macOS, Apple Silicon.
  • Codex provider; installed CLI 0.156.1.
  • The Goal-management workaround used a standalone CLI app-server 0.156.1. The separately queried shared daemon reported 0.155.1; this report does not assume it was the provider process serving the T3 thread.

Impact

An obsolete blocked Goal is difficult to remove or replace from the client, even though the backend supports clearing it. Ordinary conversation can continue, but Goal management requires an out-of-band API workaround.

Related

#2819 covers general Codex /goal support. This report concerns clearing an already persisted Goal.

No session transcripts, Goal contents, thread identifiers, project details, screenshots, or logs are attached.

Activity

  1. juliusmarminge commented on Sep 23, 2026

    @juliusmarminge
    Member

    Triage

    Confirmed. /goal clear is submitted as an ordinary Codex turn, and T3 never calls the app-server method that actually clears a goal. This is present on the v0.0.42 tag (719a76ca) and on current main (f5ef0ddb9). The desktop package version on main is still 0.0.42, so an update does not add this.

    Codex threads only advertise two slash commands, compact and feedback:

    slashCommands: [
    COMPACT_SLASH_COMMAND,
    {
    name: "feedback",
    description: "Send this thread and Codex logs to OpenAI",
    input: { hint: "Describe the issue (optional)" },
    },
    ],

    The composer intercepts only those local cases:

    • /feedback is handled in the client and uploaded with feedback/upload (packages/client-runtime/src/state/threadFeedback.ts, apps/web/src/components/ChatView.tsx).
    • An exact /compact message is turned into thread/compact/start (apps/server/src/orchestration/Layers/ProviderCommandReactor.ts).
    • /plan and /default only switch interaction mode (apps/web/src/composer-logic.ts).

    /goal clear matches none of those. It is sent as the text of turn/start (buildTurnStartParams in apps/server/src/provider/Layers/CodexSessionRuntime.ts), which is why the assistant sees the literal message. The same path is used by the web and mobile composers, not only the desktop app.

    The Codex app-server schema already has thread/goal/set, thread/goal/get, thread/goal/clear, thread/goal/updated, and thread/goal/cleared (packages/effect-codex-app-server/src/_generated/meta.gen.ts). The session runtime never requests the goal methods. It requests thread/start, thread/read, thread/compact/start, turn/start, turn/interrupt, and feedback/upload. Goal notifications are not mapped to orchestration events (apps/server/src/provider/Layers/CodexAdapter.ts drops unrecognized methods), so the client has no goal state and no clear control. The model cannot dismiss the goal either: its tools can mark a goal complete or blocked, not clear it.

    That matches the report. thread/goal/clear returning {"cleared":true} and a following thread/goal/get returning {"goal":null} is the supported operation, and there is no in-app equivalent.

    Related, not duplicates:

    No further info is needed to confirm the gap. The out-of-band thread/goal/clear call remains the workaround.

  2. added
    bugSomething is broken or behaving incorrectly.
    acceptedfeature request accepted
    via-triageFiled through npx t3 triage
    on Sep 23, 2026
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

    acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions