Compaction-associated image payload amplification in a 71 GiB Codex rollout

A privacy-preserving streaming forensic case study

Niklas Osterman
Independent AI systems researcher and research-tool designer · NOMOTO MEDIA
August 27, 2026

Status: working paper. Not peer reviewed.

Abstract

This paper reports a forensic analysis of a 76,013,248,054-byte local Codex JSONL rollout recovered during investigation of a separate extreme-memory and SIGKILL event. The initial diagnostic record established the artifact’s size, 73,544-record count, and surrounding failure evidence, but aggregate counts did not identify the byte-amplification mechanism. Bounded streaming analyses were therefore performed without loading the complete rollout into memory and without emitting conversation or image content. The first attributed 74,699,177,108 bytes—98.271261% of the file—to 898 compacted records. A structural pass found that the largest 99,594,687-byte compaction contained 68 input_image / image_url data:image;base64 payloads totaling 99,139,600 bytes. A full-file repetition pass then required matching payload length, two independent 64-bit hashes, and SHA-256. It found 50,445 encoded inline image-payload instances inside compaction records totaling 74,291,179,068 bytes. Of those, 50,377 instances and 74,192,039,468 bytes were repetitions beyond each compaction group’s first appearance—69.10 GiB and 97.604091% of the entire rollout. A second implementation parsed all 73,544 JSONL records as semantic JSON and independently reproduced every compaction-image count and byte total exactly, with zero malformed records. The storage result directly demonstrates massive repeated encoded-image amplification inside compaction records. The inference that successive compaction operations generated those copies is strongly supported by the artifact and version-matched public source but is not path-identified from this rollout. The relationship between the oversized artifact and the observed memory termination remains a separate unresolved causal hypothesis. The measurements motivate, but do not validate, storage and hydration mitigations.

1. Introduction

Long-running agent sessions combine conversation, tool output, screenshots, state snapshots, and repeated context compaction. If large binary payloads remain embedded inline when context is compacted, nominally bounded context management can become a storage-amplification mechanism. Each compaction may contain changing textual or state data while reserializing the same large payload set. Whole-record deduplication will not reveal this pattern because the records differ even when most of their bytes do not.

This case began with a local Codex rollout occupying approximately 71 GiB. The affected system experienced repeated instability and extreme memory pressure. A sanitized diagnostic package established the existence of the artifact and the surrounding failure evidence, but it did not establish what structures owned the bytes.

The research question was therefore narrow:

Which record types and fields account for the 71 GiB rollout, and does the artifact contain repeated large payloads associated with compacted state?

The analysis was constrained by the failure itself. A tool that attempted to parse the entire JSONL file or load its largest records conventionally could reproduce the memory problem. It also had to avoid exposing the private conversation and embedded images.

1.1 Evidence status

Artifact byte ownership, payload equality, and record association are measured findings. The interpretation that successive compaction operations generated the repeated serialized payloads is a strong mechanistic inference unless tied to the exact runtime implementation path. The relationship between the oversized artifact and the observed macOS memory termination is a separate open causal hypothesis.

2. Hypotheses

Five candidate explanations were considered:

1. ordinary record accumulation — the file was large because it contained many ordinary text/tool records;
2. exact record duplication — identical JSONL records had been appended repeatedly;
3. large unique tool outputs — distinct tool results, world state, or attachments dominated the artifact;
4. compaction amplification — compaction records repeatedly re-embedded large payloads while otherwise changing;
5. filesystem or sparse-file artifact — the apparent size did not correspond to logical content.

An exploratory Bullshit Centrifuge review ranked oversized-session hydration as the strongest causal explanation but correctly identified raw byte attribution as the missing falsification test. Counts were insufficient. The raw artifact needed to be measured by record type, encoded-payload ownership, payload marker, and repetition.

3. Artifact and evidence boundary

3.1 Artifact

• Format: JSON Lines rollout.
• Logical bytes: 76,013,248,054.
• Records: 73,544.
• Approximate binary size: 70.79 GiB, conventionally described as 71 GiB.
• File creation: July 21, 2026.
• Last modification: August 6, 2026.
• Artifact SHA-256: 3d6b968d3cf6792b75601f5e99bdfd66b32837b7238d5e973e0051df6e2b3036.
• Recorded session originator: codex_work_desktop.
• Recorded Codex CLI version: 0.145.0-alpha.27.
• Recorded source: vscode.
• Recorded thread source: user.

The session_meta record contained no forked_from, parent-thread, migration, or import field. Its session ID and thread ID were identical. That is evidence against an explicit recorded fork/import lineage, not proof that no prior state was inherited through an unrecorded workflow.

The private local path and session identifier are omitted from this paper. The artifact remains quarantined and was not uploaded.

3.2 Associated failure evidence

The sanitized diagnostic record contains:

• repeated macOS instability/crash observations;
• a SIGKILL outcome associated with the affected Codex work;
• a preserved macOS memorystatus event near 46,052 MB;
• aggregate record-type counts matching the later raw scan.

These facts support, but do not alone prove, the complete causal chain from rollout hydration to a specific operating-system kill.

4. Methods

4.1 Design constraints

All analyzers were required to:

• stream the file in bounded chunks;
• avoid parsing the complete 71 GiB artifact into memory;
• avoid retaining or printing conversation text;
• avoid retaining or printing image payloads;
• emit only structural types, sizes, offsets, markers, hashes, and aggregate counts;
• preserve the original artifact unchanged.

4.2 Pass 1: full-file record and encoded-run attribution

A C analyzer read the JSONL file in 8 MiB chunks. It tracked LF-delimited record boundaries and recognized the top-level compacted marker as the literal byte sequence "type":"compacted" within the current record. It measured:

• total bytes and records;
• bytes and counts by top-level type;
• record-size distribution;
• long encoded-like runs of at least 4,096 bytes;
• encoded-like bytes by record type;
• largest records and their offsets;
• exact whole-record duplication using record hashes.

An encoded run was a contiguous sequence from the character set A–Z, a–z, 0–9, +, /, and =. A nonmember byte terminated the run; chunk boundaries did not. The run size excluded the data:image/...;base64, prefix and surrounding JSON quotes. The 4,096-byte threshold deliberately excludes short strings and focuses on payloads capable of materially affecting artifact size. It may undercount smaller encoded objects. LF resets record attribution; the source artifact contained no malformed or unterminated record under the independent semantic check described below.

4.3 Pass 2: bounded structural classification of the largest record

A second analyzer inspected only the largest record at its known byte offset. It identified allow-listed structural context around long encoded runs, including:

• type;
• content;
• image_url;
• input_image;
• data:image;
• base64.

It emitted run sizes, offsets, and hashes of limited preceding context, but not the context or payload itself.

4.4 Pass 3: encoded-payload repetition

A third C analyzer streamed the complete artifact and grouped every long encoded payload using:

• payload length;
• first independent 64-bit hash;
• second independent 64-bit hash;
• complete SHA-256 digest;
• safe marker classification: image, audio, application, or other.

Only aggregate equality groups and structural recurrence metadata were retained. No payload content was stored or printed. For the highest-impact groups, the analyzer recorded global and compaction-specific occurrence counts, first and last file offsets, and first and last record numbers.

A payload group was considered equal only when length, both independent 64-bit hashes, and SHA-256 matched. The first 64-bit hash was FNV-1a initialized to 1469598103934665603; the second used the explicitly released boost-style hash-combine recurrence initialized to 1099511628211. Complete SHA-256 remained the cryptographic equality requirement. The two smaller hashes accelerate grouping but do not replace SHA-256. The same pass recorded whether each encoded payload occurred inside a top-level compacted record.

4.5 Independent semantic JSON cross-check

A separately implemented Node.js analyzer did not reuse the C scanner’s encoded-run or record-type logic. It parsed every complete JSONL record with JSON.parse, selected records whose semantic top-level type equaled compacted, recursively traversed their payloads, selected strings with a data:image/...;base64, prefix, and grouped the payload portion by byte length and SHA-256. It applied the same 4,096-byte minimum. This pass was designed to falsify a precise but wrongly bounded result from the custom byte scanner.

4.6 Internal consistency checks

• The raw scan’s 73,544 records exactly matched the sanitized diagnostic count.
• Logical bytes were counted directly from the stream.
• Structural marker classification and byte attribution were performed in separate passes.
• Whole-record duplication and internal-payload duplication were measured separately.
• A synthetic JSONL fixture declared the exact global and compaction-specific duplication result in advance; the revised analyzer reproduced every expected value.
• The independent semantic parser processed all 73,544 records, found zero malformed records, and exactly reproduced the compaction-specific image counts and byte totals.
• A measured full-artifact C pass completed in 481.17 seconds with maximum resident set size 13,647,872 bytes and zero swaps. The independent semantic pass observed peak RSS of 1,247,019,008 bytes because it parsed one complete JSONL record at a time.

5. Results

5.1 Byte ownership by record type

Although compacted represented only 1.22% of records, it accounted for 98.271261% of all bytes.

Long encoded-like runs accounted for 75,423,228,707 bytes, or 99.223794% of the entire file. Encoded-like runs inside compacted records accounted for 74,291,179,068 bytes, or 97.734515% of the file.

5.2 Record-size distribution

The largest record measured 99,594,687 bytes. It was a compacted record, and 99,139,600 bytes were long encoded-like runs.

The average compacted record measured approximately 83,183,939 bytes.

5.3 Structural payload classification

The bounded scan of the largest record found:

• 68 long encoded runs;
• 99,139,600 total encoded-run bytes;
• structural markers identifying every run as an inline image under input_image / image_url using data:image;base64.

The full-file maximum encoded run was 8,127,548 bytes.

5.4 Payload repetition

The global figures above include encoded image payloads in all record types. The decisive compaction-specific cross-tab was:

The duplicate group contributing the most redundant bytes contained a 4,079,584-byte encoded image payload appearing 609 times, producing 2,480,387,072 redundant bytes beyond its first appearance. Smaller payloads reached repetition counts above 800.

5.5 Independent parser agreement

The semantic parser reproduced the decisive C-scanner measurements exactly while using different extraction and type-recognition logic. This does not make the private artifact publicly reproducible, but it removes the original scanner as the only methodological route to the result.

5.6 Recurrence across the compaction sequence

The highest-impact groups were not confined to one late snapshot. They recurred across large spans of the artifact and overwhelmingly inside compaction records.

For four of these five groups, only the first global appearance occurred outside a compaction record; every later occurrence was inside compaction. The largest-by-redundant-bytes group had three non-compaction occurrences and 606 compaction occurrences. This sequence evidence supports repeated retention and reserialization through successive compactions rather than a single isolated compaction containing many unique images.

5.7 Whole-record duplication does not explain the file

Only five exact duplicate whole-record groups were found, contributing 625 redundant bytes beyond first appearance.

This resolves an apparent contradiction. The rollout does not repeatedly append identical JSONL lines. It repeatedly embeds identical large payloads inside compaction records whose surrounding state changes. A line-level duplicate finder therefore reports almost nothing while internal payload duplication accounts for nearly the entire file.

6. Storage mechanism and runtime hypothesis

6.1 Observed storage structure and inferred mechanism

The measurements establish the storage structure on the right; source and sequence evidence support—but do not uniquely path-identify—the generating operations on the left:

input images encoded as inline data URLs [observed] → image payloads retained when replacement history is built [inferred from sequence; supported by source] → repeated payloads occur across compacted records while surrounding state changes [observed] → individual compactions approach 100 MB [observed] → approximately 69.10 GiB of repeated encoded image-payload bytes inside compaction records [observed] → rollout reaches 71 GiB [observed]

The analysis does not infer image identity from file size alone. The structural scan identified input_image, image_url, data:image, and base64 structures. The independent semantic parser confirmed the same payload population. The repetition passes then found SHA-256-matching payloads recurring hundreds of times, with the overwhelming majority of redundant bytes directly attributed to compacted records.

6.2 Version-matched implementation evidence

Public source for the recorded tag rust-v0.145.0-alpha.27 provides strong external mechanistic support. In compact_remote_v2.rs, Codex clones retained messages into compacted history, explicitly counts retained InputImage items, assigns images zero in its text-token truncation accounting, preserves image items when text is truncated, constructs a CompactedItem with replacement_history: Some(new_history.clone()), and installs that replacement history.

The first compacted record in this artifact contains the corresponding replacement_history, window_number, first_window_id, previous_window_id, and window_id fields. However, local, remote, and remote-v2 implementations at the same tag all serialize that schema. The artifact therefore does not uniquely identify which of those compaction paths generated all 898 records. This is why the paper reports compaction-associated, not compaction-induced, amplification.

6.3 Runtime failure mechanism — unresolved causal hypothesis

Given a local application that reads, parses, serializes, indexes, renders, summarizes, or recompacts this state, extreme memory pressure is a credible risk. The preserved approximately 46 GB memorystatus event and SIGKILL evidence occurred in the surrounding incident record, but operation-level and PID/timestamp linkage to this artifact have not been established.

The evidence does not establish which application function was executing, whether the memory belonged to hydration, snapshot serialization, IPC, decoded image buffers, an independent leak, retained processes, or a combination. It also lacks the final PID/timestamp chain. Those questions require controlled runtime instrumentation, application source, or OpenAI telemetry.

7. Alternative explanations

7.1 Ordinary long conversation

Not supported as the primary byte source. Ordinary response and event records together account for approximately 1.30 GB, while compaction records account for 74.70 GB.

7.2 Exact duplicate records

Does not explain the dominant byte share. Exact line duplication contributed only 625 redundant bytes beyond first copies.

7.3 Unique large tool outputs

Not supported as the dominant explanation. Repeated encoded inline image-payload bytes inside compaction records account for approximately 69.10 GiB beyond first appearances.

7.4 Sparse-file or filesystem accounting artifact

Not supported for logical size. The streaming analyzer directly read and counted 76,013,248,054 bytes.

7.5 Unrelated application memory leak

Not fully excluded. A separate leak could coexist with the oversized rollout. It does not explain the rollout’s byte structure. The final hydration-to-kill link remains the main unresolved causal step.

8. Threats to validity and limitations

• This is a single-case forensic study.
• The artifact came from one product version and workload history.
• No outside party has independently rerun the artifact-level measurements against the private rollout.
• Runs shorter than 4,096 bytes were excluded from encoded-payload analysis.
• The primary structural classifier was bounded and purpose-built; an independent complete-record semantic JSON parser reproduced its decisive compaction-image totals exactly.
• The study did not decode or visually inspect the images.
• The study inspected public source for the exact recorded Codex tag but did not inspect proprietary application code or telemetry and could not uniquely identify the runtime compaction path from the serialized schema.
• The study cannot determine whether the usage accounting itself was correct.
• The study cannot prove that all publicly reported Codex memory failures share this mechanism; similar symptoms can have different causes.
• The final timestamp/PID link between session hydration, memory growth, and SIGKILL remains unavailable locally.

These limitations narrow the runtime conclusion but do not remove the central storage finding: repeated encoded inline image payloads inside compaction records account for nearly the entire artifact.

9. External consistency evidence

Public reports in the OpenAI Codex tracker describe related failure modes:

• issue #29812 reports repeated compacted snapshots duplicating inline base64 images, transcripts exceeding 1 GB, and SIGKILL/OOM when affected sessions reopen;
• issue #19166 reports image-heavy large threads and snapshot/allocation failure;
• issue #36431 reports runaway memory and roughly 54 GB of swap exhaustion;
• issue #30928 reports a 23.1 GB Codex app-server peak after relaunch;
• issue #38557 reports startup V8 heap failure across two Macs and two accounts that reportedly persisted after local session data was moved away.

Issue #29812 reports a directly mechanism-comparable pattern. Issues #19166, #36431, and #30928 report similar symptoms or possible runtime pathways, not verification of this byte mechanism. Issue #38557 is an important alternative-mechanism case: similar OOM symptoms can occur without this artifact path. These are user reports in OpenAI’s public tracker, not independently validated OpenAI findings.

10. Engineering implications and unvalidated mitigations

These measurements motivate the following mitigations. The present study did not experimentally validate them. Storage deduplication and lazy hydration address different failure surfaces: removing repeated bytes does not by itself prove bounded runtime memory, and lazy hydration does not correct the serialized amplification already present.

10.1 Content-address binary artifacts

Store images once, addressed by a cryptographic content identifier. Compacted state should reference the identifier rather than inline the complete base64 data.

10.2 Deduplicate before compaction

Before writing a snapshot, replace repeated binary payloads with stable references. Equality should be established cryptographically at ingestion.

10.3 Bound compaction records

Set explicit byte ceilings for individual snapshots and for total retained inline binary content. A compaction record approaching tens of megabytes should fail closed or switch representation.

10.4 Stream and lazy-load hydration

Session reopening should parse metadata and text incrementally. Binary artifacts should be decoded only when needed for the visible interaction.

10.5 Add an oversized-session safe mode

If preflight metadata exceeds safe thresholds, the application should offer:

• text-only recovery;
• attachment externalization;
• compaction repair;
• archival export;
• selective turn loading;
• explicit warning before full hydration.

10.6 Make diagnostics attribute bytes

Sanitized diagnostics should report bytes by record type and field class, duplicate-payload estimates, largest records, and hydration mode without exposing content.

10.7 Provide an official repair tool

A local repair command should transform inline repeated payloads into content-addressed references while preserving an auditable mapping and original backup.

11. Reproducibility and privacy

The analyzers and tests used in this case are preserved:

• rollout_byte_audit.c;
• inspect_encoded_runs.py;
• encoded_payload_dedup.c;
• semantic_image_crosscheck.mjs;
• semantic-image-crosscheck-result.json;
• generate_encoded_payload_fixture.mjs;
• test_encoded_payload_fixture.mjs;
• encoded-payload-fixture.jsonl.

The public source, independent parser, fixture, tests, and aggregate summaries are packaged at:

https://www.nomoto.media/wp-content/uploads/2026/08/codex-rollout-forensic-reproducibility-kit.zip

The final analysis environment was macOS 26.6.2 build 25G83 on arm64, Apple clang 21.0.0, and Node.js 20.19.5. The SHA-256 artifact fingerprint permits an authorized independent reviewer to establish that the same quarantined artifact was analyzed without making the artifact public.

The original private artifact cannot be publicly released. Reproducibility should therefore proceed in two tiers:

1. publish source code, compile instructions, schemas, and aggregate outputs;
2. validate on a synthetic JSONL fixture containing known repeated inline payloads, then allow OpenAI or an independent reviewer with authorized access to rerun against the quarantined artifact and compare the aggregate result.

The synthetic fixture contains known global and compaction-specific duplication values. The analyzer reproduced every expected value exactly. The independent semantic parser reproduced the complete artifact’s compaction-image measurements exactly, but no outside party has rerun either method against the private artifact. This is two-tier auditability, not independent reproduction.

The adversarial pre-release review that identified the missing joint attribution is publicly inspectable at https://chatgpt.com/share/6a908e09-61d8-83ea-bf5f-ef1df199d34a. The review is an analytic receipt, not independent verification.

The final bounded claim was also encoded in Review Lab’s local Collision claim contract. It passed the deterministic completeness check with no missing fields. That verifies contract shape and explicit claim boundaries; it does not independently verify the measurements.

12. Conclusion

A 71 GiB Codex rollout was not primarily the result of many ordinary conversation records. It was dominated by compaction-associated encoded-image amplification. Fewer than 900 compaction records owned more than 98% of the file, and approximately 69.10 GiB consisted of repeated encoded inline image-payload bytes inside compaction records beyond each group’s first appearance. A second semantic JSON implementation reproduced those decisive values exactly.

The measured storage pattern does not require an explanation involving model behavior; ordinary retention and serialization are sufficient to account for the file structure. Version-matched source strongly supports that mechanism, but the serialized record does not uniquely identify the implementation path. The resulting artifact creates a credible extreme-memory risk, but the exact runtime operation that produced the observed termination remains unproved.

The case illustrates a broader rule for agent systems: state is not harmless because it is “context.” Anything admitted into durable state needs a bounded representation, explicit authority, and a repair path. Storage without routing is not memory. At sufficient scale, such state becomes a material hydration risk.

References

1. OpenAI Codex issue #29812, “VS Code/WSL: repeated compacted snapshots duplicate inline base64 images and cause 1GB+ transcripts / OOM.” https://github.com/openai/codex/issues/29812
2. OpenAI Codex issue #19166, “macOS 26.4.1: repeated Codex crashes … Array buffer allocation failures on large threads.” https://github.com/openai/codex/issues/19166
3. OpenAI Codex issue #36431, “VS Code extension: codex app-server memory grows unbounded, exhausts ~54 GB swap, and crashes twice.” https://github.com/openai/codex/issues/36431
4. OpenAI Codex issue #30928, “Codex Desktop … app-server memory spike on macOS 27.” https://github.com/openai/codex/issues/30928
5. OpenAI Codex issue #38557, “Codex desktop crashes on startup—V8 JavaScript heap out of memory.” https://github.com/openai/codex/issues/38557
6. OpenAI Codex source, tag rust-v0.145.0-alpha.27, compact_remote_v2.rs, retained images and replacement history. https://github.com/openai/codex/blob/rust-v0.145.0-alpha.27/codex-rs/core/src/compact_remote_v2.rs#L282-L317
7. OpenAI Codex source, tag rust-v0.145.0-alpha.27, image retention and text-token truncation. https://github.com/openai/codex/blob/rust-v0.145.0-alpha.27/codex-rs/core/src/compact_remote_v2.rs#L447-L560