Queue new instructions instead of interrupting running agent tasks

Resolved 💬 3 comments Opened Jan 12, 2026 by pamudu123 Closed Jan 12, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

Current Behavior: When the agent is running, adding a new instruction interrupts and stops the current process. To avoid this, we currently have to create a completely new session or chat to run a new instruction.

Expected Behavior: New requests should be queued instead of interrupting the active process. Once the current task finishes, the queued request should start automatically.

Additional information

This behaviour would improve workflow reliability and user experience, especially when working with long or multi-step agent tasks. It also aligns better with how task queues work in other automation and agent-based systems.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 7 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#9067
#6980

Powered by Codex Action

etraut-openai contributor · 7 months ago

@pamudu123, thanks for posting the suggestion. We've received similar feedback from other users.

A few quick questions for you:

Are you using the Codex IDE Extension or the CLI? I'm guessing it's the extension because the CLI already defaults to queueing rather than interrupting.
If you enter new instructions, would you expect them to be injected at the next tool call boundary (i.e. mid-turn) or wait until the active turn (the last prompt you entered) is complete? There are arguments to be made for both behaviors, and we're debating which one is preferable. Interested in your input.

pamudu123 · 7 months ago

Thanks for the follow up.

I am using the IDE extension.

My preference would be not to interrupt the current session. Instead, new instructions should be queued. Once there are multiple messages in the queue, Codex can then pass all queued messages together to the next processing step.

I feel that this avoids partial execution.