openai/codex · error · QueueServiceError

queued user input exceeds the maximum length of {MAX_USER_IN

Error message

queued user input exceeds the maximum length of {MAX_USER_INPUT_TEXT_CHARS} characters ({actual_chars} provided)

What it means

QueueServiceError::InputTooLarge { actual_chars } is returned by prepare_queued_user_input (codex-rs/ext/queue/src/service.rs:491-500) when the summed character count of all UserInput::Text items in the queued message exceeds MAX_USER_INPUT_TEXT_CHARS = 1 << 20 (1,048,576 chars; codex-rs/protocol/src/user_input.rs:9). The cap exists so one user message cannot monopolize the model context window. Only Text items count - images and audio are not included - and the limit is chars (chars().count()), not bytes.

Source

Thrown at codex-rs/ext/queue/src/service.rs:58

#[derive(Clone, Debug, PartialEq)]
pub struct QueuedItem {
    pub id: String,
    pub input: TurnInput,
}

#[derive(Debug, Error)]
pub enum QueueServiceError {
    #[error("queue storage failed: {0}")]
    Storage(#[from] ThreadStoreError),
    #[error("queued submission payload is invalid: {0}")]
    InvalidPayload(#[from] serde_json::Error),
    #[error("local queued attachment is invalid: {0}")]
    InvalidAttachment(#[from] std::io::Error),
    #[error("Core failed to submit queued user message: {0}")]
    CoreSubmissionError(#[from] CodexErr),
    #[error("only user input can be added to the user-message queue")]
    InvalidInput,
    #[error(
        "queued user input exceeds the maximum length of {MAX_USER_INPUT_TEXT_CHARS} characters ({actual_chars} provided)"
    )]
    InputTooLarge { actual_chars: usize },
}

#[derive(Clone)]
pub struct QueuedItemService {
    queue: Arc<dyn QueueStore>,
    thread_manager: Weak<ThreadManager>,
    event_sink: Arc<dyn ExtensionEventSink>,
    dispatch_locks: Arc<StdMutex<HashMap<ThreadId, Weak<Mutex<()>>>>>,
    resumed_threads: Arc<StdMutex<HashSet<ThreadId>>>,
}

impl QueuedItemService {
    pub fn new(
        queue: Arc<dyn QueueStore>,
        thread_manager: Weak<ThreadManager>,

View on GitHub (pinned to 339751715c)

Solutions

  1. Split the content across several queued messages, each under the limit
  2. Move oversized content into a file and reference or attach the path instead of inlining the text
  3. Cap client-side using the same rule the queue uses: sum of text.chars().count() over Text items compared against MAX_USER_INPUT_TEXT_CHARS (1 << 20)
  4. If a single blob legitimately exceeds about a million chars it also exceeds practical context - send it as a file attachment instead

Example fix

// before
let item = queue.enqueue(thread_id, input).await?; // InputTooLarge { actual_chars }

// after
use codex_protocol::user_input::{UserInput, MAX_USER_INPUT_TEXT_CHARS};
let chars: usize = content.iter().filter_map(|i| match i {
    UserInput::Text { text, .. } => Some(text.chars().count()),
    _ => None,
}).sum();
if chars > MAX_USER_INPUT_TEXT_CHARS {
    return Err(TooLong); // ask the user to trim, or split into multiple queued messages
}
let item = queue.enqueue(thread_id, input).await?;
Defensive patterns

Strategy: validation

Validate before calling

fn queued_text_chars(content: &[UserInput]) -> usize {
    content.iter().filter_map(|item| match item {
        UserInput::Text { text, .. } => Some(text.chars().count()),
        _ => None,
    }).sum()
}
// before enqueue:
if queued_text_chars(&content) > MAX_USER_INPUT_TEXT_CHARS { /* split or reject */ }

Try / catch

match err {
    QueueServiceError::InputTooLarge { actual_chars } => {
        // show: message is {actual_chars} chars; limit is 1_048_576
    }
    _ => {}
}

Prevention

When it happens

Trigger: enqueue()/update() with a message whose Text items together exceed 1,048,576 characters: a giant pasted log, an inlined file, or base64 stuffed into text. Multi-part content is summed across all Text items, not checked per item.

Common situations: Pasting a large log or dataset into the composer while the thread is busy; automation that inlines whole files as message text; non-ASCII content where a byte-based client-side check (.len()) passes but the char-based queue check rejects.

Related errors


AI-assisted analysis of openai/codex@339751715c (2026-08-25). Data as JSON: /api/errors/4abb2e4dae71a1f4. Report an issue: GitHub.