Mid-Execution Input Interrupts and Reorders Task Flow, Breaking Sequential Workflows

What version of Codex CLI is running?

.98

What subscription do you have?

PRO

Which model were you using?

pt-5.3-codex

What platform is your computer?

Mac

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

After the recent update that allows adding new input while a task is actively running, sequential task workflows are no longer reliable.

While the ability to inject input mid-execution may be useful in some interactive scenarios, it currently disrupts ordered task execution and causes the model to deviate from the original instruction chain. This represents a regression for users relying on structured, step-by-step workflows.

⸻

What Issues Are You Seeing?
• When additional input is added while Codex is actively executing a task, the model:
• Deviates from the original sequence of instructions.
• Reprioritizes or merges the new input with the current task.
• Breaks the expected order of execution.
• Previously reliable step-by-step workflows now behave unpredictably.
• It is no longer possible to safely queue commands in advance and expect them to execute strictly in order.
• This creates instability for structured automation and multi-step task pipelines.

For users building deterministic workflows (e.g., “do A, then B, then C”), this change significantly degrades reliability.

⸻

Steps to Reproduce

1. Start a multi-step task that requires ordered execution (e.g., a structured workflow or scripted sequence).
2. While the model is still processing, submit additional instructions intended for later execution.
3. Observe that:

• The model immediately incorporates the new instructions.
• The original task flow is interrupted or altered.
• Execution order is no longer guaranteed.

⸻

Expected Behavior
• New input submitted during execution should either:
• Be queued and processed only after the current task completes, or
• Be ignored until the current execution cycle finishes, or
• Be controlled by a configurable setting (e.g., “interrupt mode” vs “queued mode”).

Sequential workflows should remain deterministic and predictable.

⸻

Actual Behavior

New input is treated as an immediate priority, causing deviation from the current task and breaking ordered execution.

⸻

Impact
• Breaks deterministic multi-step workflows.
• Prevents reliable task chaining.
• Disrupts automation-style usage.
• Represents a regression in workflow stability for structured users.

For users relying on sequential execution patterns, this change is a significant step backward in usability.

What steps can reproduce the bug?

After the recent update that allows adding new input while a task is actively running, sequential task workflows are no longer reliable.

While the ability to inject input mid-execution may be useful in some interactive scenarios, it currently disrupts ordered task execution and causes the model to deviate from the original instruction chain. This represents a regression for users relying on structured, step-by-step workflows.

⸻

What Issues Are You Seeing?
• When additional input is added while Codex is actively executing a task, the model:
• Deviates from the original sequence of instructions.
• Reprioritizes or merges the new input with the current task.
• Breaks the expected order of execution.
• Previously reliable step-by-step workflows now behave unpredictably.
• It is no longer possible to safely queue commands in advance and expect them to execute strictly in order.
• This creates instability for structured automation and multi-step task pipelines.

For users building deterministic workflows (e.g., “do A, then B, then C”), this change significantly degrades reliability.

⸻

Steps to Reproduce

1. Start a multi-step task that requires ordered execution (e.g., a structured workflow or scripted sequence).
2. While the model is still processing, submit additional instructions intended for later execution.
3. Observe that:

• The model immediately incorporates the new instructions.
• The original task flow is interrupted or altered.
• Execution order is no longer guaranteed.

⸻

Expected Behavior
• New input submitted during execution should either:
• Be queued and processed only after the current task completes, or
• Be ignored until the current execution cycle finishes, or
• Be controlled by a configurable setting (e.g., “interrupt mode” vs “queued mode”).

Sequential workflows should remain deterministic and predictable.

⸻

Actual Behavior

New input is treated as an immediate priority, causing deviation from the current task and breaking ordered execution.

⸻

Impact
• Breaks deterministic multi-step workflows.
• Prevents reliable task chaining.
• Disrupts automation-style usage.
• Represents a regression in workflow stability for structured users.

For users relying on sequential execution patterns, this change is a significant step backward in usability.

What is the expected behavior?

Introduce one or more of the following:

1. Queue Mode (Default or Optional Setting)

New input during execution is appended to a queue and processed only after the current task completes.

1. Interrupt Toggle

A user-configurable option:
• “Allow interrupting current execution”
• “Queue input until completion”

1. Explicit Command Mode

Ability to mark new input as:
• Interrupt
• Queue
• Cancel + Replace

Restoring deterministic task sequencing is critical for structured and automation-driven workflows.

Additional information

_No response_