Codex app: add per-message offset/continuation to read_thread for replies over 20,000 characters

What variant of Codex are you using?

Codex desktop app on macOS, using the app-provided codex_app.read_thread tool to read ChatGPT conversations. Observed September 12, 2026. Exact desktop build was not recorded.

What feature would you like to see?

Please add bounded pagination within a single message, either through a message-specific offset/limit or an opaque continuation cursor. The existing thread cursor pages between turns; it cannot retrieve the missing suffix of an individually truncated reply.

A separate message-read operation would also work. It should target a stable thread/message identity, retain the existing per-call size limits, and expose enough metadata to reconstruct the original text and verify completion.

Suggested semantics:

• Target a specific message ID, with an optional content-part ID for multipart messages.
• Return a bounded text slice with a next-content cursor (or precisely defined offset), total length when available, and an explicit completion/truncation indicator.
• Keep content continuation separate from the existing turn-history cursor.
• Ensure successive slices preserve the original text without gaps, duplicated characters or broken Unicode boundaries.
• Bind continuation to a message revision/hash, or fail clearly if an edited message would invalidate it.
• Apply the same authorization checks and bounded response budgets as ordinary history reads.

Additional information

Observed limitation

During a source-consolidation task, two long assistant replies containing Markdown documents were truncated at the reader's 20,000-character per-message cap. Later conversation turns remained accessible; this is not missing conversation-tail history.

The exposed arguments were threadId, hostId, cursor, turnLimit, includeOutputs and maxOutputCharsPerItem. There was no message-content offset or continuation argument.

Attempting maxOutputCharsPerItem: 100000 returned:

read_thread received invalid arguments: maxOutputCharsPerItem: Too big: expected number to be <=20000.

Reproduction outline

1. Read an accessible ChatGPT conversation containing an assistant message longer than 20,000 characters.
2. Reach that turn using the reader's normal history pagination, with maxOutputCharsPerItem: 20000.
3. Observe the truncated message.
4. Attempt to retrieve the remainder: the existing cursor navigates older turns, and increasing the message limit above 20,000 is rejected.

Why this matters

Long design documents often place conclusions, exceptions and unresolved decisions at the end. Without a supported way to retrieve the suffix, an agent cannot produce a verifiably complete export or review of the message. Asking users to manually paste the missing text is especially awkward when they are using remote/mobile access.

Raising the cap alone is not the request: bounded continuation would preserve context and rendering limits while allowing complete retrieval. Related size-budget concern: #35753.

The public repository has a related read_thread schema with a turn cursor and per-item output limit in codex-rs/tui/src/dynamic_tools.rs. This report concerns the observed desktop/ChatGPT reader; it does not assume the TUI implementation is the same handler.

No private message text, project names, conversation/message IDs, local paths or logs are included.

Start with codex-rs/tui/src/dynamic_tools.rs and inspect the existing read_thread schema, turn cursor, and per-item output limit. Confirm whether that entry point serves the reported desktop reader before assessing the requested design; done requires an agreed bounded per-message continuation with stable reconstruction and explicit completion behavior.