Legacy shell tool discards output beyond 1 MiB without counting it; the model-facing truncation notice is a constant

What version of the Codex App are you using?

The affected rollout records report cli_version: 0.144.2. The matching public source is tag rust-v0.144.2, commit a6645b6b8a656360fa16fb7e1c6721d0697d3d6a. The desktop build string was not captured for these sessions.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Windows 11, x64.

What issue are you seeing?

Legacy shell tool output loses data in two stages. The first stage is silent and uncounted, and the notice the model receives for the second stage is a constant that carries no information about the first.

Stage 1 — silent, unbounded, never counted.

The shell capture path retains only the first 1 MiB and discards the rest without recording how much was lost:

• DEFAULT_OUTPUT_BYTES_CAP = 1024 * 1024, aliased as EXEC_OUTPUT_MAX_BYTES
• applied via ExecCapturePolicy::ShellTool
• append_capped retains only the prefix
• the reader continues to EOF to avoid back-pressure, returns truncated_after_lines: None, and does not count discarded bytes
• ExecToolCallOutput has no total-byte or omitted-byte field

So everything past 1 MiB is gone before any model-facing formatting runs, and the quantity is not carried forward anywhere.

Stage 2 — marked, but the number is a constant.

The legacy shell model formatter calls bare truncate_text, which performs a 50/50 head-and-tail elision and inserts …N tokens truncated… in the middle. A nearby alternate formatter calls formatted_truncate_text, which prepends Warning: truncated output (original token count: N) at the head. The shell path does not use it.

For ASCII-heavy output the mid-payload number is fully determined:

captured prefix              1,048,576 bytes
model-facing budget         10,000 × 4 = 40,000 bytes
removed by presentation      1,048,576 − 40,000 = 1,008,576 bytes
reported token notice        1,008,576 / 4 = 252,144

252144 therefore appears on every shell output that exceeds 1 MiB, regardless of whether the command produced 1.1 MB or 900 MB. It measures what the second formatter removed from the already-capped prefix.

Observed behaviour

Across three days of sessions on a large private repository:

• 7,070 tool outputs, 84 truncated (1.19%)
• of 4,841 shell_command / function_call_output records, 9 carried …252144 tokens truncated… — the identical figure every time
• 0 shell-path records carried the head Warning: truncated output form
• a representative capped record delivered 40,069 characters, with the notice at offset 20,044 — roughly 20k of head, the notice, then roughly 20k of tail

The practical effect is that the agent receives a response that begins and ends normally, with the only indication of loss placed mid-payload where content competes with it, and the magnitude it reports is a constant. Work then proceeds on partial data. In our case the largest losses landed on diagnostic reads during an incident, and the resulting repairs were made against evidence that was missing its middle.

Expected behaviour

1. Bytes discarded by the 1 MiB capture cap are counted and carried forward.
2. The model-facing notice appears at the head of the payload, in the same form the exec path already uses.
3. The reported original size reflects all observed bytes, not the retained prefix.

Suggested fix, with existing precedent

PR #32150 (merged 2026-07-10, commit 6138909d) already does exactly this for unified exec: it preserves omitted-byte metadata and computes the original estimate from all observed bytes. It did not touch the legacy shell formatter, which still calls bare truncate_text on current main (source).

Applying the same pattern to the shell path:

1. Count total or omitted bytes in read_output while it already drains to EOF.
2. Carry that metadata through RawExecToolCallOutput and ExecToolCallOutput.
3. Emit a head warning in format_exec_output_for_model, using the total-byte count for the original-token estimate.
4. Keep the head-and-tail body if desired, but do not rely on the inline marker as the only warning.
5. Add a regression using two outputs above 1 MiB of differing sizes, asserting the reported original count differs rather than remaining 252144.

Note that the deployed suite currently locks the existing shape — this test expects shell output to begin normally and contain only the middle marker, so it would need updating alongside.

Related

• #35226 — context auto-compaction loop; this is a different mechanism but the same underlying path
• #35050 — Code Mode batching; that thread has been treating truncation as a batching side-effect, and this shows the large losses come from the non-batched shell path
• #9758 — earlier, closed, async-path variant of the byte-cap accounting