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
- Split the content across several queued messages, each under the limit
- Move oversized content into a file and reference or attach the path instead of inlining the text
- 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)
- 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
- Count chars, not bytes - the limit is chars().count() summed over Text items only
- Files belong in LocalImage/LocalAudio attachments or referenced paths, not inlined text
- Show a live character counter as the composer approaches the cap
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
- only user input can be added to the user-message queue
- queue storage failed: {0}
- queued submission payload is invalid: {0}
- local queued attachment is invalid: {0}
- Core failed to submit queued user message: {0}
AI-assisted analysis of openai/codex@339751715c (2026-08-25).
Data as JSON: /api/errors/4abb2e4dae71a1f4.
Report an issue: GitHub.