macOS: Goal selected from + menu briefly exposes /goal in task title before automatic rename

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

ChatGPT desktop app / Codex surface: 26.901.51231 (build 8109), verified from the installed app bundle during troubleshooting. The original screenshot does not itself display a version.

What subscription do you have?

Not collected for this report; plan dependence has not been established.

What platform is your computer?

macOS 26.6.2 (25G83).

What issue are you seeing?

After selecting Goal through the composer + menu, the initial task title in the sidebar and header showed a literal /goal prefix followed by the prompt. The task was subsequently renamed automatically after a noticeable delay.

The user selected Goal through the menu rather than manually typing the command. Displaying the command prefix in the title makes the UI look as though it is echoing a manually entered slash command.

The screenshot also showed Sent as goal under the user message and Pursuing goal above the composer. This report concerns temporary title presentation and delayed renaming. It does not allege failure to activate Goal, duplicated execution, or lost work.

What steps can reproduce the bug?

Observed sequence; not independently repeated in a fresh task:

1. Start a new local Codex task in the macOS desktop app.
2. Open the composer + menu and select Goal.
3. Enter an objective and submit.
4. Inspect the initial sidebar and header title: it contains /goal.
5. Wait: the title is replaced with a generated descriptive title.

For a non-sensitive reproduction, an example objective is “Explain the difference between a list and a tuple.” This example has not been run as a test.

Frequency: one owner-reported incident, supported by screenshots and subsequent read-only task retrieval. Exact click-to-rename latency was not measured.

What is the expected behavior?

The provisional title should display the objective without the internal /goal prefix, including while descriptive title generation is pending. The existing Goal status indicators can communicate the selected mode.

Additional information

Troubleshooting completed before submission:

• Inspected both supplied screenshots locally.
• Retrieved the exact affected task read-only: its later title no longer contained /goal; its stored initial user message did contain the prefix. Stored text alone does not prove the user typed that prefix.
• Inspected the installed JavaScript bundle without modifying it. It contains a helper that formats Goal text with a /goal prefix and an asynchronous title-generation path that can set a provisional title from input before awaiting a generated replacement. This is consistent with the observation; it is not a runtime trace proving the exact incident’s call path or latency cause.
• Searched existing public reports. #28287 concerns duplicated timeline messages on Windows and is related but does not match this symptom.
• Reviewed the official Goal documentation. It documents Goal mode but does not establish a maximum title-generation delay.

No fresh UI reproduction, timing trace, server-side diagnosis, restart, or app modification was performed. Please investigate whether the provisional title should strip the Goal prefix before asynchronous renaming completes.

Attachments: none. Private prompts, task identifiers, project content, file links, screenshots, and raw diagnostics are omitted.

Start in the installed JavaScript bundle's Goal text formatter and asynchronous title-generation path, tracing how selection from the composer + menu supplies the provisional title. Confirm that pending titles omit the /goal prefix while the later generated title still replaces them; the issue provides no source file or test path.