Remove manual approval of "Keep Waiting" (auto-accept waiting extra time)

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

• #31935

Powered by Codex Action

I am having the same issue. Since I'm working with multiple agents this blocks their work unnecessarily. By the time I click "continue anyway" it probably would have finished.

In my opinion a better option is to just print a NOTE in the transcript rather than a prompt.

I'm having this problem as well, and would like to see it fixed; it's especially disruptive for all-night AFK workflows.

<details>
<summary><b>Expand for hacky workaround using tmux, generated by sol</b></summary>

This wrapper starts Codex inside a new tmux session when needed. If already inside tmux, it uses the current pane. It watches for the safety-check prompt, moves the selection to Keep waiting, and presses Enter.

mkdir -p "$HOME/.local/bin"

cat > "$HOME/.local/bin/codex-auto-wait" <<'EOF'
#!/usr/bin/env bash
set -u

SELF="$(readlink -f "$0")"

# Find the real Codex binary, excluding this wrapper.
REAL_CODEX="${CODEX_REAL:-}"

if [[ -z "$REAL_CODEX" ]]; then
    while IFS= read -r candidate; do
        if [[ "$(readlink -f "$candidate")" != "$SELF" ]]; then
            REAL_CODEX="$candidate"
            break
        fi
    done < <(type -aP codex)
fi

if [[ -z "$REAL_CODEX" ]]; then
    echo "Could not find the real Codex binary." >&2
    exit 1
fi

if ! command -v tmux >/dev/null 2>&1; then
    echo "tmux is not installed." >&2
    exit 1
fi

# Outside tmux: create a session and rerun this wrapper inside it.
if [[ -z "${TMUX:-}" ]]; then
    session="codex-${USER:-user}-$$"
    printf -v command '%q ' "$SELF" "$@"
    exec tmux new-session -s "$session" "$command"
fi

# Inside tmux: watch the current pane.
pane="$TMUX_PANE"

(
    armed=1

    while tmux display-message -p -t "$pane" '#{pane_id}' \
        >/dev/null 2>&1; do

        screen="$(
            tmux capture-pane -p -J -t "$pane" 2>/dev/null || exit
        )"

        if grep -Fq "Additional safety checks" <<<"$screen" &&
           grep -Fq "Retry with a faster model" <<<"$screen" &&
           grep -Fq "2. Keep waiting" <<<"$screen"; then

            if [[ "$armed" == 1 ]]; then
                # Option 1 is selected initially. Move to option 2 and confirm.
                tmux send-keys -t "$pane" Down Enter
                armed=0
            fi
        else
            armed=1
        fi

        sleep 1
    done
) &

watcher_pid=$!

cleanup() {
    kill "$watcher_pid" 2>/dev/null || true
    wait "$watcher_pid" 2>/dev/null || true
}

trap cleanup EXIT INT TERM

"$REAL_CODEX" "$@"
exit $?
EOF

chmod +x "$HOME/.local/bin/codex-auto-wait"

echo "alias codex='$HOME/.local/bin/codex-auto-wait'" >> "$HOME/.bashrc"
source "$HOME/.bashrc"

Codex can then be invoked normally:

codex
codex --yolo

Down Enter is intentional: option 1 is highlighted by default, so Down selects 2. Keep waiting, then Enter confirms it.

</details>

This remains a UX problem in codex-cli 0.145.0, even though the current implementation appears to have changed the backend semantics so that no confirmation is required.

The current popup is:

Our systems are thinking a bit more about this request before responding.
Hang tight or retry with a faster model...

> 1. Retry with a faster model
  2. Dismiss and keep waiting
  3. Learn more

No action is required. Codex will keep waiting, and this menu will close when the response is ready.

I initially interpreted this as a blocking approval prompt and had to inspect the implementation to determine whether an unattended Sol request would continue. In the current TUI source, "Dismiss and keep waiting" has no action callback; only "Retry with a faster model" sends an event. So the server-side safety check continues without input.

The remaining issue is interaction semantics: a three-item selection view, with "Retry with a faster model" highlighted first, strongly communicates "the program is waiting for your choice." The footer contradicts the control presented above it. For unattended/all-night workflows, users should not have to inspect source code to know that the request is still running.

Suggested behavior:

• Render safety buffering as a non-modal status/transcript notification: "Additional safety check in progress; Codex will continue automatically."
• Keep "Retry with Luna" as an optional secondary action, not the default highlighted choice.
• Do not present "keep waiting" as an action, because waiting is already the default state.
• Alternatively, provide a persisted setting such as safety_buffering_prompt = "status-only".

Expected result: unattended requests continue exactly as they apparently already do in 0.145.0, while the UI no longer resembles a blocking approval dialog.

This is still a serious unattended-workflow failure in codex-cli 0.147.0.

I started a long-running /goal and went away. Almost immediately afterward, the safety-buffering dialog appeared asking whether to retry with a faster model. The goal then did no further work for hours until I returned and noticed the dialog. In the end, the overnight run accomplished nothing.

This must have a persistent config.toml opt-out. When enabled, Codex should always keep waiting, never present the modal selection UI, and never pause or otherwise interfere with an unattended goal. For example:

[tui]
safety_buffering_prompt = "status-only"

A non-modal status message is fine. Asking for an optional model switch must never strand an autonomous run.

I traced this to codex-rs/tui/src/chatwidget/safety_buffering.rs. The current turn already keeps waiting, but ModelSafetyBufferingUpdated still installs the modal selection view and can disrupt unattended/goal workflows.

A minimal persistent opt-out is an optional global config field:

[notice]
hide_safety_buffering_prompt = true

When true, the handler follows the existing hidden-UI path: it does not register a retryable buffered turn or open the model-switch chooser, while the original turn and model continue waiting unchanged. Default behavior remains unchanged when the field is absent/false.

I implemented the config type, generated schema, TUI guard, and snapshot test here for reference:
https://github.com/mik-tf/codex/commit/d9e71be191

The focused TUI test and all 281 codex-config tests pass. Since the contribution guide says external PRs are not accepted, I am linking the implementation here as root-cause analysis/reference for an internal fix.