codex - 💡(How to fix) Fix [Feature request] Add a “hold queued tasks” control for human-in-the-loop review

What variant of Codex are you using?

CLI and MacOS desktop App

What feature would you like to see?

Problem

During development, I often queue several predefined follow-up prompts while Codex is already working. Those prompts are still useful and should be executed later.

However, a common human-in-the-loop workflow looks like this:

1. Start a Codex run.
2. Queue several predefined follow-up prompts that should run later.
3. While inspecting the current run, notice something unexpected or inconsistent with my assumptions.
4. Decide that I need a few minutes to review the current output, logs, diffs, or reasoning before allowing the queued prompts to continue.
5. Keep the queued prompts intact, because they are still relevant after review.

Today, the current behavior appears to automatically start the next queued prompt once the current run finishes. The only practical workaround I have found is to manually clear the queue, wait for the current run to finish or pause, and then reconstruct the queued prompts later.

That feels counterintuitive: I do not want to delete the queue; I only want to temporarily prevent automatic queue draining while I inspect the current run.

Desired behavior

Add a user-facing control to hold/resume queued prompts.

Possible names:

• “Hold queue”
• “Pause queued prompts”
• “Pause queue auto-send”
• “Review before continuing”

When the queue is held:

• The current run should continue normally.
• Existing queued prompts should remain in the queue.
• Queued prompts should still remain visible like usual.
• Queued prompts should still remain editable if the current UI supports editing.
• When the current run completes, Codex should not automatically start the next queued prompt.
• The user can explicitly resume the queue when ready.

When the queue is resumed:

• Codex should continue using the existing one-at-a-time queued prompt behavior.
• Resuming could either immediately start the next queued prompt or simply re-enable auto-send while idle. I do not have a strong preference on the exact UX.
• The important behavior is that the user has an explicit review checkpoint before queued prompts continue.

The default behavior could remain unchanged for users who prefer the current automatic queue flow.

Why this matters

This would better support human-in-the-loop development workflows.

Queued prompts are valuable because they let me plan follow-up work while Codex is running. But software development often requires review checkpoints. While inspecting a run, I may notice:

• an unexpected implementation direction;
• a suspicious test result;
• a diff that needs manual review;
• a log or error that changes the next step;
• an assumption mismatch that should be resolved before continuing.

In these cases, I want to keep my predefined queued prompts, but temporarily stop Codex from advancing into them automatically.

A “hold queue” control would make the queue safer to use for multi-step workflows, because users could preserve their planned prompts without losing the ability to inspect and steer between runs.

Additional information

I am opening this as a feature proposal rather than an unsolicited PR, in line with the current contribution policy.

Some observations from the public repo:

• The public repo appears to include the CLI/TUI, core/app-server protocol, SDK/tooling, and desktop app launcher/installer integration, but not the full macOS desktop app frontend source.
• codex-rs/app-server exposes turn-level primitives such as starting, steering, and interrupting a turn, but I could not find a user-facing queue hold/resume behavior for queued prompts.
• The TUI appears to have a local queued-input state machine, including a queue auto-send suppression flag. I understand this may be TUI-specific and may not apply directly to the macOS app, but it suggests that “do not auto-drain the queue right now” is a natural state-machine boundary.

Because I observed this in the macOS App, I am not assuming the fix belongs in the TUI. It may belong in the App frontend, shared app-server semantics, or as a cross-surface UX convention so that App / IDE Extension / CLI / Web queue behavior stays consistent.

If the Codex team thinks this proposal is aligned with the intended product direction, high-impact enough to prioritize, and suitable for external contribution, I would be happy to help with a focused implementation or design iteration after receiving an explicit invitation to submit a PR.