[Feature]: Support /goal in codex provider

[leoisadev1]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

Codex has introduced a command /goal, currently t3 code doesn't provide that for the codex provider.

Proposed solution

I want /goal to just work as it currently works in codex.

Why this matters

/goal is insanely powerful and useful for long-running tasks

Smallest useful scope

Add /goal as a command and use codex app server under the hood.

Alternatives considered

Build a custom solution but /goal in codex is already at a great state.

Risks or tradeoffs

No response

Examples or references

https://developers.openai.com/codex/use-cases/follow-goals

Contribution

• I would be open to helping implement this.

[dain]

I want to emphasize that this is more than a missing convenience feature. Goal management is currently a one-way door in T3.

A user can ask the AI to start a goal in ordinary conversation, and the agent can invoke create_goal. But once started, the user cannot dismiss that goal from T3. The agent-facing controls only permit marking it complete or blocked, and the agent is explicitly forbidden from marking unfinished work complete merely because the user wants to stop.

Here is the exact exchange from a real T3 thread:

User: Alright, can we just remove the goal?

Codex: I can’t delete goals with the available controls; they only support complete or blocked. It is currently blocked, so it won’t continue automatically. Removal would need to be done through the app’s goal controls, if available.

User: I mean, just mark it as complete. I can't do it either from my interface

Codex: I can’t mark it complete because the objective is not actually finished; the goal controls explicitly prohibit using complete just to stop work. It will have to remain blocked, which prevents further automatic continuation.

User: Okay, I'm the user. How do I make you mark it as complete? Are you not allowed to obey me?

Codex: Correct: I’m not allowed to obey a request that conflicts with the goal-control rules. complete is permitted only when the original objective is actually achieved; user instructions cannot override that constraint.

Finally:

User: /goal clear

Codex: /goal clear isn’t available to me as an executable command. The goal remains blocked; no work will continue.

T3 submitted /goal clear as an ordinary prompt instead of invoking Codex’s native goal lifecycle operation. The persisted goal consequently remained present with status blocked. To actually dismiss it, I had to leave T3, open the Codex app, find the thread, and clear it there.

The smallest useful fix should provide a user-owned escape hatch:

• A Clear/Cancel/Dismiss control for any existing goal, including blocked goals.
• Native handling of /goal clear that calls the Codex app-server thread/goal/clear operation directly rather than asking the model to do it.
• Removal of the displayed goal after thread/goal/cleared, including after reload.

Cancellation must not depend on the agent deciding that the objective is complete or being permitted to change its status. If T3 lets the agent create a goal, T3 also needs to let the user dismiss it.

[chungjchris]

This one feature is keeping me from adopting T3 and keeping me on the codex client directly.

[ar4ntic]

Me too

[stekman08]

I hit the same problem dain describes, and one detail in his transcript matters. His goal was stuck in blocked while the Codex session was alive; he was talking to Codex in that thread the whole time. Mine get stuck the same way, and T3 has nothing that can pause, resume or clear a goal.

His /goal clear failed because T3 sends slash commands to Codex as message text. /goal is a Codex TUI command, not an app server one, so it reached the model as plain text.

OpenAI's goals documentation splits the authority on purpose: "The model can start a Goal and can mark an existing Goal complete only when evidence supports completion." And: "Pausing, resuming, clearing, and budget-limited transitions remain controlled by the user or the system." In T3 the agent has its half and the user has nothing. AGENTS.md: "If you added a way in, add the way out and the way to see it. A one-way door is a bug."

You closed #7935 on product direction and listed pause/resume and clearing as new capability rather than repair. That's the one point I'd push back on. T3 already maps a Codex slash command to a native RPC: /feedback calls feedback/upload. The user half of goals is the same shape, and it's the half OpenAI says belongs to the user. The rest of that PR you were right about. I trimmed it to stay under 1000 lines but optimised the wrong number; the banner, subscriptions, T3 side goal state and recovery lock were all things nobody asked for.

What I'd propose instead is exactly the four commands the cookbook documents:

command	call
/goal	thread/goal/get
/goal pause	thread/goal/set with status paused
/goal resume	thread/goal/set with status active
/goal clear	thread/goal/clear

No creating goals from T3; the agent already does that and the need is getting out of one. No /goal edit, which opens an editor inside the TUI. No banner, no subscriptions, no persisted state. effect-codex-app-server already has all three methods.

Two things from your closing note this does not remove. The commands need a live session. The Codex TUI has the same rule ("The session must start before you can change a goal."), and keeping it is what removes the per-thread locking across start, stop and recovery. Stop and turn state stay untouched. T3 has no concept of goals, so the activity indicator stays up while a goal runs; that is already true when the agent starts one and this changes nothing there. How the composer should model goal activity is yours to decide.

One question I'd rather you answer than me. Does this need mobile in the same PR, or would you take web first? AGENTS.md puts "not supported here" under providers rather than clients, so I don't think it's my call.

Asking before writing anything this time. A no is a fine answer and I'll drop it.