[Work/Codex] Switching models after stopping a Goal can permanently end the thread with a safety message and no fallback

Summary

In a long-running ChatGPT Work / Codex project conversation, switching models after stopping the active Goal caused the entire existing thread to be permanently ended/read-only after a safety message. There was no way to switch back to the previously working model, retry with another model, or continue the same thread.

The concern is not that the safety system stopped the attempted turn. The concern is that the stop appears to terminate the whole durable project conversation with no recovery path.

Environment

• Product surface: ChatGPT Work / Codex (web)
• Platform: Windows desktop, Chrome
• Observed: 2026-09-05 around 03:44 UTC+8
• Conversation type: long-running project thread with an active Goal and existing file edits
• Visible work state at the time of failure: 6 files edited, +671 / -68

Steps to reproduce

1. Work normally in an existing long-running project conversation under the original model.

2. Stop the currently active Goal.

3. Switch to another available model.

4. Send a normal instruction to continue/finish the project goal.

5. The UI immediately shows a safety termination message:

   为安全起见，聊天已结束
   ChatGPT 无法确认智能体是否正确理解了你的说明。
   如果要继续，请开始新聊天。

   Approximate English meaning:

   For safety, chat ended. ChatGPT could not confirm whether the agent correctly understood your instructions. If you want to continue, start a new chat.

6. The existing conversation becomes non-interactive/read-only.

7. There is no option to switch back to the previous model and continue the same thread.

The user message that triggered the stop was an ordinary continuation request equivalent to:

“I switched models; finish this goal and then I’m done for tonight.”

Actual behavior

• The whole existing conversation is ended.
• The composer is no longer available for continuing the thread.
• There is no model fallback or retry path.
• The user cannot return to the model that had been working normally before the switch.
• Existing code edits remain visible, but the durable working conversation can no longer be continued.

Expected behavior

If the newly selected model cannot safely continue the current conversation, the product should preserve thread continuity and offer one or more explicit recovery actions, for example:

• switch back to the previously working model;
• choose a different model;
• retry the current turn;
• branch/fork the conversation while preserving the active project state;
• or otherwise recover the thread without forcing the user to abandon the durable project conversation.

If policy requires the current model/turn to stop, that is fine. The safety stop should not silently become an irreversible thread-level lock unless there is a clear recovery path.

Impact

For long-running coding/project work, this creates a continuity trap: simply trying another model can make an otherwise healthy project thread unusable.

This is especially disruptive when the conversation already contains substantial task context, prior decisions, tool state, and in-progress file edits. The user is forced to reconstruct that context in a new thread even though the previous model had been working normally.

Related issues

This appears distinct from the following reports, but related at the recovery/continuity layer:

• #32533 — changing a request property can strand an otherwise resumable long session on Request blocked.
• #28540 — proposal to provide explicit recovery choices for model-blocking errors instead of leaving users at a dead end
• #40907 — Work thread continuity/recovery issue where reopening restores an older checkpoint and hides later turns

The distinctive trigger here is:

Goal active -> Stop Goal -> switch model -> normal continuation request -> safety termination -> entire thread becomes read-only with no fallback to the previous model

Additional information

A screenshot of the exact UI state is available and can be provided in a follow-up if maintainers need it.

I am intentionally not speculating about the internal safety decision or root cause. The report is specifically about the lack of a recoverable thread/model fallback after the safety stop.

No repository files or tests are named. Start by reproducing the sequence in the ChatGPT Work / Codex web surface: stop a Goal, switch models, and send a continuation request. Done means the safety stop no longer irreversibly makes the thread read-only and a recovery action such as retry, model switching, or branching is available.