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

[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.

[juliusmarminge]

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:

t3code/apps/server/src/provider/Layers/CodexProvider.ts

Lines 680 to 687 in f5ef0dd

	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:

• [Feature]: Support /goal in codex provider #2819 is the broader /goal request. It is closed, and the feature is not on main. The comment there already describes this one-way door.
• feat(goals): track native provider goals across clients #11516 would have added /goal commands and a clear control. It was closed without merging.
• fix(server): pause Codex goals before stopping turns #10447 only pauses an active goal before Stop. It does not clear a blocked goal, and it is not on main.

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