Codex App: `/goal clear` creates a new active Goal with objective `clear` instead of clearing

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.10989 (Windows package version 26.803.10989.0)

What subscription do you have?

ChatGPT subscription; the exact tier was not captured before the affected thread was archived.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Pro)

What issue are you seeing?

In a very long-running Codex Goal, the user invoked /goal clear to remove the Goal. Instead of treating clear as the reserved lifecycle command, Codex created a new active Goal whose objective was literally clear.

The injected Goal context showed:

<codex_internal_context source="goal">
  <objective>clear</objective>
  ...
</codex_internal_context>

A subsequent get_goal confirmed that an active Goal existed with objective clear. The Goal did not disappear until the agent called update_goal(status="complete"); only after that did get_goal return goal: null.

This is distinct from reports where /goal clear fails, or where old steering remains in history after a successful clear. Here, the control-command argument itself was routed into Goal creation as an objective.

The affected run was unusually long:

• Thread/session ID: 019fcbcd-30d4-7792-a810-8edded0a9c7e
• Original Goal ID: 69abc8eb-bac5-447a-999f-e58a4cd546d3
• Approximately 9,404,479 tokens
• Approximately 94,310 seconds (26h 12m)
• 20 Goal continuations
• 80 context compactions

The original project objective is omitted because it contains private infrastructure details.

What steps can reproduce the bug?

I do not yet have a small deterministic reproduction. This is the exact observed sequence:

1. Start a long-running Goal and allow it to continue across many automatic continuations and context compactions.
2. Pause/stop the original Goal after observing stale continuation behavior.
3. Invoke:

``text
/goal clear
``

1. Observe that Codex does not simply clear the Goal. Instead, Goal context is injected with:

``xml
<objective>clear</objective>
``

1. Call get_goal.
2. Observe an active Goal whose objective is clear.
3. Call update_goal(status="complete").
4. Call get_goal again and observe goal: null.

A useful regression test would route /goal clear while a Goal has queued or in-flight continuation state, then assert all of the following:

• no new Goal is created;
• the literal string clear never becomes an objective;
• get_goal returns null after the clear completes;
• queued/in-flight continuation leases lose publication eligibility.

What is the expected behavior?

/goal clear should be parsed as a reserved lifecycle command before any Goal objective creation/update path runs.

It should atomically:

1. clear the persisted Goal;
2. prevent creation of any replacement Goal;
3. invalidate queued and in-flight continuation leases for the cleared Goal;
4. cause subsequent get_goal calls to return null.

The word clear should never become a Goal objective when entered through the /goal clear command.

Additional information

This run also showed two related Goal lifecycle failures:

1. Previously handled user-message replay after compaction. A Windows Defender question submitted once at 2026-08-11 22:43 CST and answered at 22:44 was answered again, without new user input, at approximately 23:40, 00:32, 10:06, 10:51, 11:29, 11:53, and 12:25. This overlaps with #27894 and #29811.
2. A paused Goal still allowed an in-flight continuation to publish. The Goal was paused at 2026-08-12 13:11:38 CST, but a stale continuation reply was published at 13:47:30, about 36 minutes later. This overlaps with #37869.

This issue is intentionally focused on the distinct /goal clear → objective clear routing defect rather than duplicating those existing reports. The three symptoms occurred in the same long-running thread and may share a lifecycle/routing race, but that is an inference rather than a confirmed implementation detail.

Possible implementation checks:

• Parse clear, pause, and other reserved Goal control commands before objective set/create routing.
• Give each Goal generation/continuation a generation ID or lease.
• On pause/clear, atomically invalidate queued and in-flight leases.
• Before publishing an assistant turn, perform a CAS-style check that the Goal generation and status still match.
• Persist an exactly-once handled marker for user messages so compaction cannot promote an already-consumed message back into the current request.

The affected thread has now been archived. Continuing to send turns in that original thread currently triggers a Windows Defender alert on each turn; that appears to be a separate issue and is being investigated in a new thread. For that reason I have not reopened the archived thread solely to submit in-app feedback. This report is based on the preserved transcript, timestamps, and direct get_goal observations.

Current locally installed CLI for reference: codex-cli 0.144.1.