Safety rejection incorrectly ends turn as "aborted by user" without explanation

Description

A long-running Codex Desktop turn was forcibly interrupted while I was asleep. I did not press Stop or provide any input.

The local session transcript shows three automated safety rejections of proposed file changes. Immediately after the third rejection, Codex recorded:

• Tool result: aborted by user after 4.2s
• Turn status: turn_aborted
• Reason: interrupted

The desktop app then displayed the turn as complete, without allowing Codex to provide a final explanation or next step.

Expected behavior

If an automated safety system terminates a turn:

• Do not label it “aborted by user.”
• Clearly state that an automated safety rule stopped the turn.
• Explain which action triggered the stop.
• Allow a plain-English final response when safe.
• Preserve an obvious Resume option.

Actual behavior

• The turn stopped without user input.
• It was falsely attributed to the user.
• No final explanation appeared.
• The preceding technical errors made it look like Codex had crashed or silently abandoned the work.

Environment

• Time: August 13, 2026, approximately 3:33:25 AM EDT
• Codex CLI recorded in the session: 0.147.0-alpha.6.5
• Desktop release recorded in the logs: 26.803.61601
• macOS desktop app

There was no matching crash report, and the application continued running.

I have not attached the private project conversation or full logs to this public issue. I can provide the affected session and turn identifiers privately to OpenAI if needed.

Start by tracing how the CLI and macOS desktop app handle the recorded turn_aborted and interrupted states after automated safety rejections. Use the supplied session transcript behavior as the reproduction; done means safety termination is not attributed to the user, includes an explanation, and preserves a Resume option when safe.