Codex queue steering and feedback upload

Sending messages into a running Codex turn, and uploading Codex thread logs with diagnostics. Part of the Codex harness runtime guide; Where each section moved lists every section.

Queue steering

Active-run queue steering maps onto Codex app-server turn/steer. With the default messages.queue.mode: "steer", OpenClaw batches steer-mode chat messages for the configured quiet window and sends them as one turn/steer request in arrival order.

Inline images and stored attachments keep their original image order. Stored images use the same hydration, size limits, and filesystem restrictions as a new turn. If an attachment cannot be prepared or steering is rejected, the complete message remains queued for a follow-up turn. Preparation and the turn/steer acknowledgment do not confirm transcript commitment. A message sent to Codex without a confirmed transcript commit is not replayed automatically.

When Codex confirms the transcript commit, OpenClaw saves completed visible assistant items before the steered user message, including items before a tool or sleep handoff. Each item keeps its own identity so later steers do not duplicate it. This history prefix is separate from the turn's final-answer selection. A commit confirms that the input entered history; it does not prove that a subsequent model request has read it.

Codex review and manual compaction turns can reject same-turn steering. In that case, OpenClaw waits for the active run to finish before starting the prompt. Automatic compaction inside a regular turn keeps steering available; Codex buffers the input for the next model boundary.

Use /queue followup or /queue collect when messages should queue by default instead of steering. See Steering queue.

Configuration and policy warnings

The Codex warning about an unknown ultrafast_mode feature requirement appears once per OpenClaw chat session, including bursts of separate native notifications in one response. Later turns, retries, and replacement native threads or app-server connections reuse the chat's receipt. Different text, details, or diagnostic locations still get their own first notice. Other operational and policy warnings, and Guardian events, keep their normal delivery even when their wording repeats.

Receipts contain hashes, not private policy names or warning text, in the chat's existing plugin-owned session state. They survive Gateway restart. A new chat or an actual reset gets its own first warning, including resets that retain the session ID but rotate its lifecycle revision. Incognito state follows the chat's existing process-lifetime contract; it is not copied to durable storage. Existing plugin-state cleanup on reset, deletion, or plugin disablement clears receipts.

Only successful projection is acknowledged. Failed or ignored projection can retry. Storage failure, or a crash between projection and receipt persistence, can allow a repeat rather than hide an unseen warning. Each chat retains at most 256 distinct variants of this diagnostic without evicting acknowledged receipts; additional variants remain visible but are not remembered for deduplication.

This changes duplicate delivery, not Codex feature support or enterprise policy enforcement. The managed-app-server Doctor check validates the selected binary and version; a passing result does not certify that Codex recognizes every feature in the account's policy.

Diagnostic-log warnings

If Codex reports a process-wide failure to save its diagnostic logs, OpenClaw records that notice at warning level in the Gateway logs. It records each native notice when received, rather than repeating it in every conversation sharing that app-server. A new app-server can report a new failure.

This routing does not repair the native logging failure or upload diagnostics. The warning alone does not mean conversation state was lost. Other task-specific, configuration, and unrecognized warnings still reach chat. Gateway log visibility follows the configured logging levels and available sinks. As with other Gateway diagnostics, reporting is best effort: a logging failure never interrupts the native connection, and these operator-only notices do not fall back to chat.

Codex feedback upload

When /diagnostics [note] is approved for a session on the native Codex harness, OpenClaw also calls Codex app-server feedback/upload for relevant Codex threads, including logs for each listed thread and spawned Codex subthreads when available.

The upload goes through Codex's normal feedback path to OpenAI servers. If Codex feedback is disabled in that app-server, the command returns the app-server error. The completed diagnostics reply lists the channels, OpenClaw session ids, Codex thread ids, and local codex resume <thread-id> commands for the threads that were sent.

If you deny or ignore the approval, OpenClaw does not print those Codex ids and does not send Codex feedback. The upload does not replace the local Gateway diagnostics export. See Diagnostics export for the approval, privacy, local bundle, and group-chat behavior.

Use /codex diagnostics [note] only when you want the Codex feedback upload for the currently attached thread without the full Gateway diagnostics bundle.