Let cross-task messages respect the recipient chat’s Queue setting

Codex Feature Requests
1

Feature request

I regularly use several Codex tasks at the same time and sometimes ask one task to send an update to another.

My default Follow-up behavior is set to Queue. However, when ChatGPT sends a message from another task to a chat that is already running, the message appears to be inserted directly into the active run instead of waiting for the next turn.

This makes cross-task coordination unpredictable. A status update or additional piece of context can redirect work that was already in progress, even though the recipient chat is configured to queue follow-ups.

Steps to reproduce

  1. Set Settings → General → Follow-up behavior to Queue.
  2. Start a task and let it continue working.
  3. From another task, ask ChatGPT to send a message to the active task.
  4. The message appears as “Sent by ChatGPT from another task” and is handled during the active run instead of waiting for a new turn.

Requested behavior

When a task receives a message from another task:

  • Respect the recipient chat’s existing Queue or Steer preference.
  • If Queue is selected, hold the message until the current run finishes.
  • Show clearly that the incoming message is queued.
  • Allow the sending task to explicitly request Steer when an interruption is intentional.

The recipient’s preference could remain the default, with Queue or Steer available as an optional override when sending the message.

If cross-task messages are already intended to respect this setting, this may be a bug rather than a new feature.

Why this would help

This would make multi-task workflows much safer. Tasks could exchange findings and status updates without unexpectedly changing each other’s active work.

Environment

  • Component: ChatGPT/Codex desktop app
  • App version: 26.924.22138, build 11645
  • Bundled Codex command-line interface: 0.158.0-alpha.2.1
  • Operating system: macOS 26.6.2
  • Follow-up behavior: Queue
2

Your optional Steer override should require permission on the recipient side; without it, the message stays queued for the next turn.

3

Yeah i agree, i like that approach, thats a better way to handle it. The recipient should remain in control, and without explicit permission, the message should stay queued for the next turn.