›_ Codex Issues
Codex Issues / #35357

Feature request: add a frozen state for queued messages

Open 💬 2 comments Opened Jul 25, 2026 by ScDor
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Problem

When an agent is busy, I want to jot down follow-up ideas without interrupting it. Currently, queuing a message means it auto-sends as soon as the agent finishes, giving me no chance to review, tweak, reorder, or hold back the thought.

Proposed solution: Frozen Messages

Add a Frozen Messages state to the message queue. Instead of auto-sending when the agent finishes, these messages stay paused in a dedicated box until I manually release them.

How it should work

  • UI: A visual box holding pending frozen messages as editable cards/lines.
  • Shortcuts and buttons: A way to send a message directly into the frozen state rather than the active queue.
  • Manual release: Frozen messages remain paused after the current task completes until explicitly sent.
  • Indexed sending: Keyboard combinations, for example ending with a number like 1, 2, can instantly send the corresponding frozen message when multiple messages are lined up.
  • Editable: Frozen messages remain fully editable text until sent.
  • Reordering and deletion: Allow frozen messages to be reordered, deleted, or moved into the active queue before release.

Why this helps

This supports rapid follow-up thinking without interrupting a long-running task or accidentally sending an unreviewed prompt. It separates two different intents:

  1. Queue this to run automatically next.
  2. Remember this for later, but let me review and decide when to send it.

The current queue supports the first intent, but there is no clear way to express the second.

Related OpenAI Codex discussion

A related request in Codex proposes grouping queued user messages and sending them as one request: https://github.com/openai/codex/issues/35356

This issue is specifically about adding a user-controlled, manually released draft/frozen state rather than only grouping or automatically processing queued messages.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #35356

Powered by Codex Action

Nothinglessss · 3 days ago

I have the same need, but I think the underlying abstraction is slightly broader than a frozen message/draft state.

The key workflow is:

  1. Codex is working on an active task.
  2. During that work, either the user or Codex discovers a useful follow-up (refactor, regression test, adjacent bug, cleanup, etc.).
  3. I want to capture that item immediately so I don't have to remember it.
  4. But capturing it must not imply that it should execute after the current turn. The current task may require several more iterations/turns before it is actually complete.
  5. Only when the active task reaches a real task boundary should I review/select from deferred work.

So the semantic distinction I would like Codex to support is:

  • Execution queue: run this automatically after the current work/turn.
  • Deferred work / backlog: remember this durably, but do not execute until explicitly promoted/selected.

In other words, discovery != transition: discovering a follow-up should create a candidate work item without mutating the active task.

A useful invariant would be: the end of a model turn is not a task boundary. Multiple Codex turns can belong to the same active task, while deferred items accumulate alongside it.

This could be implemented as the proposed Frozen Messages UI, but I think treating these items as first-class deferred work (editable/reorderable/deletable, with optional provenance such as “discovered while working on X”) would make the feature substantially more useful for long iterative coding sessions.

The user experience I want is essentially: capture eagerly, execute conservatively.