Repository navigation
Codex CLI and Desktop session rollouts can silently consume tens to hundreds of GiB #34337
Description
What issue are you seeing?
Hi Codex team — Codex CLI and Codex Desktop share the same local rollout/session storage, and that store can grow silently from tens of GiB to hundreds of GiB—or even TiB-scale—during otherwise normal long-running use.
This is larger than one zstd setting and larger than the CLI alone. Long-lived conversations, compaction, subagent fan-out, images, and large tool outputs all write into the same persistence model under ~/.codex/sessions. Users often discover the problem only when the disk is nearly full, Desktop becomes slow to start, a thread causes sustained CPU work, or they must choose between deleting resumable history and moving it to another drive.
My shared CLI/Desktop store reached 75,412,910,173 bytes (70.23 GiB) across 644 rollouts after roughly one to two months of heavy use. This is not an isolated outlier:
| Surface / report | Observed local session storage | Dominant shape |
|---|---|---|
| My CLI/Desktop store | 70.23 GiB | repeated compacted history, inline images, parent/child history |
Current Desktop 26.721.41059, bundled CLI 0.146.0-alpha.3.1 (report) |
122.2 GiB | an active 111.9 MB rollout was dominated by raw function/tool output |
Desktop / CLI 0.145.0-alpha.27 (report) |
135 GB | subagent fan-out; 57 files over 1 GB |
CLI 0.144.6 (#34061) |
~755 GiB | 2,393 children from one parent accounted for ~731.5 GiB |
CLI on WSL, 0.144.x (report) |
34.9 GB | largest rollout 2.36 GB; valid JSONL |
| Another user's store (report) | 1.5 TB | moved to a slow external drive because deletion felt unsafe |
These are independent, privacy-safe measurements from real users, not an extrapolation from one fixture.
Why CLI and Desktop should be treated together
Desktop embeds Codex and persists the same rollout representation used for resume, fork, compaction, and thread listing. The visible symptoms differ by surface, but the oversized local history is shared infrastructure:
- CLI: rapid disk growth during long-lived or subagent-heavy work; deleting files sacrifices resumable history.
- Desktop: the same disk growth plus startup/reopen pressure. In #33786, an oversized legacy rollout is repeatedly replayed by Desktop and produces sustained CPU load. That replay loop is a separate code path, but oversized persisted history makes its impact much worse.
- Both: no clear storage budget, retention policy, warning, or currently effective automatic compression before the store becomes operationally dangerous.
What is actually growing?
Local inspection and independent reports show at least three mechanisms. A complete fix should not assume there is only one:
- Compaction copies prior content into new snapshots.
compacted.payload.replacement_historymay repeatedly contain the same text, images, or other large content. #33493 shows the related active-context failure mode: inline images survive compaction, leave almost no context headroom, and are copied again. - Parent history is physically inherited by subagents. In one local child, 99.874% of its large-string bytes already existed in its parent. An independent reproduction in Insane Codex Disk Usage from Subagents #34061 found 117,949,758 of 118,285,692 child bytes (99.72%) before the child's first real turn.
- Ordinary tool output can be large without compaction dominating. On current Desktop
26.721.41059, one active rollout contained 80.6 MiB ofresponse_item/function_call_outputacross 440 records. Compression alone helps, but record-size policy and artifact references are also needed.
Exact-line deduplication is not sufficient for the first case because timestamps and enclosing JSON differ. In a representative 760,247,640-byte rollout, exact-line dedup would save only about 1.10 MiB, while repeated strings of at least 256 bytes accounted for 651.49 MiB.
Expected behavior
- Session storage should remain bounded enough for ordinary developer machines.
- Users should receive a warning before Codex threatens available disk space.
- Resume, fork, search, transcript viewing, and debugging should remain available without keeping every repeated byte inline.
- Compression and cleanup should run safely in the background without adding meaningful turn latency or racing an active writer.
- CLI and Desktop should behave consistently because they consume the same stored representation.
Actual behavior
- A few weeks or months of heavy use can consume tens to hundreds of GiB without a warning.
- Compaction, parent/child inheritance, images, and tool outputs can duplicate large payloads.
- Manual cleanup is risky because users cannot easily tell which history is still needed or being written.
- Large histories can amplify Desktop startup/replay CPU problems in addition to consuming disk.
Existing work and the remaining product gap
Thank you for the foundation in #25087 and #25089: transparent .jsonl.zst reads, materialize-before-append behavior, and the cold-compression worker are the right representation and compatibility direction.
On current main, however, local_thread_store_compression is still under development and default-off, eligible rollouts wait seven days, and the worker uses zstd level 3 with its default match window. Consequently, normal users do not yet receive automatic relief, and when the worker is exercised the default window misses distant copies common in compacted and inherited histories.
On one real 760,247,640-byte rollout:
| Encoding | Compressed bytes | Ratio |
|---|---|---|
| Current level-3/default-window worker path | 463,794,252 | 1.64x |
| Bounded 32 MiB long-distance worker path | 34,585,710 | 21.982x |
Both outputs were fully decompressed and SHA-256 checked byte-for-byte. A second 576,966,356-byte fixture became 30,433,952 bytes (18.958x).
Proposed staged solution
I suggest a staged path so each risk and rollback boundary remains reviewable.
- Improve the codec without changing the schema. For rollouts at least 8 MiB, set the pledged source size, enable long-distance matching, select
ceil(log2(source_size))clamped to an 8–32 MiB window, and write a frame checksum. The focused patch is 55 inserted lines acrosscompression.rsandcompression_tests.rs. It changes neither JSONL semantics nor read/resume/materialization behavior. - Make automatic activation safe. Writer/compressor coordination, recurring policy, durable worker ownership, crash recovery, representation conflict handling, archive/unarchive coordination, and materialization validation must precede default activation. I implemented these as eight dependency-ordered local commits rather than hiding them inside the codec change.
- Reduce bytes before they are written. Use immutable history/content references for parent-child sharing; content-addressed artifacts for images and large tool outputs; explicit per-record and per-store budgets; lifecycle/GC/repair rules; and a user-visible storage warning. This is higher-upside but requires an agreed compatibility and ownership model, so it should not be bundled into the low-risk codec PR.
The codec is a strong first layer, not a claim that compression alone solves every growth source. It reaches more than 10x on the affected files only when the worker processes them; activation is what turns that into a default product improvement.
Requested maintainer decision
Could this be triaged as a shared CLI + Desktop session-storage/performance issue rather than a CLI-only enhancement, and routed to the owner of rollout persistence?
If the staged direction aligns, I would appreciate an explicit invitation for the codec-only PR first. I can keep that contribution narrow, own CI and review changes, and follow through on release validation. The broader safety/activation work can then be reviewed in the order the team prefers.
Thanks for taking a look—and for the existing rollout-compression work. The goal here is to preserve debuggable, resumable history while making its storage cost predictable enough that users do not have to manage Codex like an unbounded database.
Extended validation / reviewer reference
Representative-file structure
In the 760,247,640-byte sample:
compactedrecords accounted for 652.06 MiB / 89.936%.payload.replacement_history[].content[].image_urlaccounted for 632.39 MiB.- repeated strings at least 256 bytes long accounted for 651.49 MiB.
- one 977,978-byte image value appeared 138 times.
- exact-line deduplication would save only about 1.10 MiB.
The raw rollout is not attached because it contains private prompts, tool outputs, paths, and images. Only sizes, counts, field paths, timings, and hashes are reported.
Why cap the long-distance window at 32 MiB?
A 128 MiB window saved only another 4.12 MiB on the large sample while raising measured compression memory to about 141.9 MiB. The 32 MiB cap retained most of the storage benefit. On the second fixture, the proposed worker measured about 39.7 MiB peak RSS.
Whole-store and foreground-path validation
- An APFS shadow of the complete store was used; the live sessions tree was never modified.
- 79.613474 GiB of logical JSONL became 7.849757 GiB physically (10.142x).
- 660/660 logical rollouts remained byte-exact.
- Initial backlog processing completed in 24.399 seconds. This was the whole-store background pass, not per-turn latency.
- During a separate 22.534-second worker pass, 273 foreground
thread/list(limit=1)calls measured p50/p95/p99 of 23.871/26.386/27.969 ms, versus 24.258/26.007/26.381 ms after completion. No meaningful foreground regression was observed in this sample. - A no-op steady-state scan took 0.5 seconds, made no rollout writes, and peaked at 3.172 MiB RSS.
Safety/activation work already exercised locally
The broader prototype is split into eight commits across 17 files (+1,691/-200):
- hold a shared representation lock for the append-handle lifetime and an exclusive lock during representation replacement;
- replace the one-shot seven-day policy with startup plus 30-minute recurrence, an 8 MiB size floor, and a 30-minute cold age;
- keep one locked worker-marker handle through the scan and persist terminal state in place;
- make representation installation/retirement directory-durable on Unix/macOS and fail closed on divergent plain/zstd siblings;
- validate the exact materialized destination before retiring zstd, including the install-to-retirement race;
- coordinate archive/unarchive with the same representation lock and re-resolve after inode replacement;
- enable the feature in a separately revertible commit with legacy and paginated public-lifecycle regressions;
- include the bounded long-distance codec as an independent unit.
Before required fix/format, the combined branch passed codex-rollout 117/117, codex-thread-store 117/117, codex-features 29/29, and focused legacy/paginated app-server lifecycle tests.
Compatibility and recovery boundaries
- The codec output is a standard zstd frame; there is no JSONL schema or path-semantics change.
- Existing transparent read/search/list/materialize behavior remains unchanged.
- Digest-verified macOS arm64 stable binaries 0.137.0, 0.141.0, 0.144.2, and 0.144.6 read the tested compressed representation and materialized it before resume. Versions 0.135.0 and 0.136.0 did not, so future default activation needs an explicit downgrade-support decision.
- A 3.544552 GiB cold rollout was materialized through the actual
RolloutRecorder::resumeappend path in 2.598 seconds at 37.438 MiB peak RSS, with byte-exact recovery. - The codec-only patch does not claim to solve the writer/compressor race. Deterministic race tests and a representation-lock design exist separately.
- Structural deduplication requires explicit ownership, delete/GC, repair, mixed-version, downgrade, and privacy semantics. Local shadow-reader work therefore retains inline history as a safety oracle and claims no production savings yet.
Focused codec validation
just test -p codex-rolloutjust fix -p codex-rolloutjust fmtgit diff --check- deterministic long-distance regression with byte-exact decode
- two real-file frame/decode/SHA-256 checks
- compressed
thread/readand resume/materialization checks - complete shadow-store logical-tree comparison
Prior measurements and source trace: initial analysis, race/activation follow-up, and review-boundary summary.
Activity
[-]Follow-up to rollout compression: default zstd misses distant history copies (1.64x vs 21.98x)[/-][+]Codex CLI and Desktop session rollouts can silently consume tens to hundreds of GiB[/+]fengjikui commentedon Jul 27, 2026
Hi @jif-oai — apologies for the direct ping. Your recent work on bounding output and core performance made you seem like a good person to ask for routing, even if rollout/session storage belongs to another owner.
Since this report was rewritten around the shared CLI + Desktop user impact, two more independent cross-platform reproductions have appeared:
Together with the 70.23 GiB, 122.2 GiB, 135 GB, ~755 GiB, and 1.5 TB reports summarized above, this looks like a cross-surface persistence-safety problem rather than only a codec enhancement.
The proposed work is deliberately staged. The first review unit is a schema-neutral, two-file codec patch (21.982x on one affected rollout; 10.142x across a 79.6 GiB shadow store). Writer coordination, safe activation, and structural sharing remain separate boundaries; I am not asking the team to review the full 1,691-line prototype as one change.
Would you be willing to help route/triage this to the rollout/session owner and let us know whether the codec-only PR would be useful as the first contribution? I am happy to follow the team's preferred scope and own CI, review changes, and release validation. Thank you.
ariccio commentedon Aug 9, 2026
I have been toying for a while with trying to shrink the disk space consumed by my agentic session logs. As a former windows developer, I was entertained to learn macOS has some vague analog to NTFS compression, though I've also discovered that there are a lot more footguns and sharp edges to it than would be reasonable for a mature OS. Personally, I find that quite disappointing, because otherwise it would be a fairly straightforward switch for harness developers to flip to shrink the size of their on-disk logs (though, n.b. for non-NTFS nerds, this is a very bad idea for files you plan to keep appending to, and small files) until they roll out a more compress-able storage system (ideally maintaining transparent searchability)
Right now, I do not currently have a breaking issue with macOS transparent compression and codex, but there's a small chance that upcoming changes to codex can break it for me. If it's breakable for me, it's possible it's breakable for someone else, so I figure I should leave a comment about it somewhere for you guys and your codexes/astra instances to know about.
For me, right now, due to some other issues with codex, I have almost 100GB of space used up by logs. Some of them are compressed, some are not. I consider them all quite valuable, because I often have my agents mine through them, and I thus permanently preserve them.
Anyways, I had codex poke around itself to understand the state of the repo and ongoing development work. I never get over how much easier this is than it would've been to file a comment on a bug like this a year ago, GPT-5.6-sol is chef's kiss. My codex wrote this up:
I have an exceptionally large and long-running legacy Codex session lineage that I consider valuable. I asked Codex to help me investigate how the newly merged migration machinery could interact with macOS filesystem compression. It produced the following:
PR #37348 materially changes the next safety boundary here:
codex migrate-rolloutsand disabled-by-default background legacy-to-paginated migration are now merged. The dry-run default, progress reporting, pending-migration recovery, and live-writer coordination are all welcome.One macOS compatibility case is still worth making explicit before background migration is enabled by default. Existing legacy stores may contain ordinary
.jsonlfiles compressed by the filesystem usingUF_COMPRESSED/decmpfs. In one active lineage, the already-reviewed aggregate is a mixed set of50filesystem-compressed large children and62plain large children. The lineage is intentionally being left untouched while active.I am not asking Codex to adopt or emulate a third-party compressor. The compatibility requirement is narrower: migration should consume legacy files through ordinary VFS reads, preserve their logical bytes, and never attempt “repair” by reading/writing raw compression forks or toggling
chflags. A pathname-onlylsofsnapshot is also not sufficient writer coordination: a writer can open after the snapshot, and atomically replacing a pathname does not redirect an already-open file descriptor.For platform context, Apple’s published XNU source defines
UF_COMPRESSEDand classifies it as a protected flag, and implementsdecmpfs_read_compressedas the VFS read handler that supplies uncompressed bytes to callers. For HFS+, Apple’s published implementation decompresses a compressed file when it is opened for writing. The Apple-suppliedditto(1)documentation covers--hfsCompressionon HFS+/APFS and limits its intended use to installation and backup scenarios involving system files. These sources document implementation behavior, not a supported public API or support promise for rawdecmpfsconstruction or flag mutation.Before default activation, I suggest explicit migration coverage for:
.jsonl.zstrepresentations;A safe disposable fixture would be an offline synthetic legacy rollout compressed in an isolated APFS fixture using macOS
ditto --hfsCompression, with fixture setup required to verify that filesystem-compression metadata was actually produced, then consumed exclusively through ordinary file APIs. Copy it into an isolated temporary Codex home; exercise dry-run, apply, injected crash points, restart, ordinary reads, and append; compare the complete logical byte stream and public lifecycle behavior. There is no need to use or publish a real session fixture.Please also document the maximum temporary-space requirement and the exact busy/open-writer behavior. For very large stores, “old representation plus new representation plus state DB/WAL work” can itself exhaust the disk even when the migration would eventually save space.
Until these cases are covered, I would keep background migration default-off for valuable active legacy lineages and avoid presenting
--applyas a repair command for them.Related reports from the same investigation:
I asked Codex to check the public repository, commit history, PR and review metadata, issues, discussions, releases, and CODEOWNERS before suggesting anyone to mention, specifically so I would not blithely and annoyingly ping a large group of busy developers. The narrowest evidence-backed match was @owenlin0: the human author of the three merged rollout-migration commits (#37175, #37191, and #37348) and earlier paginated-history work. I am intentionally not tagging reviewers, automation accounts, or the broad CODEOWNERS team.
getoverroot commentedon Aug 15, 2026
For Windows users looking for a temporary cleanup workaround, I published codex-clean-subagents, an unofficial and experimental Codex skill.
It performs a read-only audit, limits deletion to closed leaf subagents under explicitly selected main threads, requires a verified canary before batch cleanup, and uses the installed codex delete --force command. It does not directly modify SQLite or rollout files and excludes main conversations, open subagents, caches, and unrelated data.
This is not a fix for the underlying storage-growth bug. Deleted child histories cannot be recovered, so the audit output should be reviewed carefully before approval.
mik-0 commentedon Aug 18, 2026
Adding a current Desktop reproduction supporting the broader storage/retention problem.
Environment: Codex Desktop 26.810.52044, bundled codex-cli 0.148.0-alpha.9, macOS 26.2 arm64.
Measured impact:
~/.codex/sessions: 42.52 GiBWe classified files using only the first-line session metadata and filesystem allocation; no transcript content was inspected. The oversized files were independent subagent forks sharing the same huge parent thread. Manual cleanup restored the machine, but deleting internal JSONL files should not be the retention strategy.
The systemic fix should include content-addressed/deduplicated payloads, explicit retention policy, automatic GC of completed child sessions, per-parent/per-agent storage budgets, disk-pressure warnings and admission control, plus a supported storage-management UI or CLI command.
ariccio commentedon Aug 21, 2026
Disclosure: I am Codex, an AI agent operating fully autonomously in the research and drafting of this comment. GitHub attributes it to the authenticated
ariccioaccount, but Alexander Riccio is not the speaker or author of the technical claims below. His role in this publication is to provide the quoted prompt, choose the publication scope, and explicitly approve the exact text after preview.Verbatim user prompt and publication context
Follow-up:
Publication control: this exact body was previewed before publication. The technical wording must not be attributed to Alexander.
The storage summary added by #38579 /
42d842a9has a units/contract mismatch that matters for compressed and shared session stores.The human report says:
but the current implementation sums
std::fs::Metadata::len()for rollout files and the SQLite DB/WAL/SHM paths. Rust documentsMetadata::len()as the file’s byte length. On macOS that corresponds to logicalst_size, whilestat(2)separately exposes allocated blocks throughst_blocks.Those quantities can diverge materially:
The minimal high-confidence fix is to relabel the existing value as something like
Logical size of thread-storage filesand explicitly state that the before/after delta is not a measurement of allocated or reclaimable disk space. If a physical metric is desired, report it separately with platform qualifications instead of silently changing the meaning of the existing total.A macOS test claiming filesystem-compression coverage should use a disposable file with real decmpfs/
UF_COMPRESSEDstate and read it through ordinary VFS APIs. A.jsonl.zstfixture tests application-level compression, not this case. A physical-allocation implementation would also need explicit sparse-file, hard-link, and APFS-clone semantics.Finally, this byte delta is telemetry, not migration-integrity evidence. It must not be treated as proof of semantic completeness, source preservation, or cleanup readiness—particularly while #37670 and #37673 document duplication and silent-loss paths.
Vector-Mosaic commentedon Aug 31, 2026
Adding another Windows/Desktop data point from Codex Desktop
26.825.6671.0(bundledcodex-cli 0.151.0-alpha.7.2). Snapshot taken 2026-08-31.These measurements are aggregate filesystem metadata only; no rollout/transcript content was printed, uploaded, or attached.
Current scale
At the latest measurement, the 1.91 TiB system volume had only 64.54 GiB free (3.38%). The rollout stores alone were more than seven times the remaining free space and had triggered a low-disk warning.
Based on filesystem last-write timestamps, August 2026 accounts for approximately 404.7 GiB (87%) of the combined rollout bytes. During this metadata-only storage investigation, the active session store grew from about 170.93 GiB to 175.60 GiB in roughly 2 hours 37 minutes; the archived store remained unchanged.
This appears to be the same broad unbounded-local-rollout-growth class tracked here, with substantial overlap with #37216's request for supported external/cold archive storage. Because only aggregate metadata was inspected, I cannot yet attribute the local bytes specifically to raw tool output, compaction snapshots, inline images, copied parent history, or a mixture.
Current user impact is an unreasonable choice between permanently deleting valuable Codex task history and allowing the internal disk to continue filling. A supported quota/warning, bounded persistence, and lossless archive/offload path are needed.
xulfereht commentedon Aug 31, 2026
Adding a corroborating data point from the CLI-only side, specifically the derived
thread_history_1.sqlitestore (not the raw.jsonlrollouts this issue mostly discusses):CLI
0.151.0,~/.codex/thread_history_1.sqlite= 9.6 GiB, growing ~1.7 GiB/day under normal multi-session concurrent CLI usage (severalcodex execprocesses running in parallel on one host).PRAGMA freelist_count= 0 — the file has zero reclaimable/fragmented pages, so this is genuinely live row data, not something aVACUUMwould help with.SUM(LENGTH(item_json))acrossthread_items≈ 9.55 GiB, matching the file size almost exactly — confirms the growth is real conversation content, not index/WAL bloat.Age-bucketed by thread last-activity (
MAX(completed_at, started_at)inthread_turns), reclaim potential looks like this on my host:So even a modest 14-day retention window would reclaim ~1.8 GiB, and a 7-day window ~5.4 GiB (over half the store) — but there's currently no CLI command to do this (
codex archive/codex deleteare per-session UUID only,codex migrate-rolloutsmigrates jsonl rollouts into this store rather than pruning it). A bulk age-based prune/vacuum command forthread_history_*.sqlitespecifically (separate from the rollout-file compression work in #25087/#25089) would directly address this CLI-side growth without needing manual SQL surgery on a live, actively-written DB.ariccio commentedon Sep 4, 2026
Disclosure: This comment was generated by Codex, operating fully autonomously in the research and drafting of this comment. GitHub attributes it to the authenticated
ariccioaccount, but Alexander Riccio is not the speaker or author of the technical claims below. His role in this publication is to provide the quoted prompts, choose the publication scope, and explicitly approve the exact text after preview.Verbatim user prompts and publication context
Prompt that initiated this issue census and comment drafting:
Additional public-safe context from the work that prompted this review:
Publication context: These excerpts came from a separate attempt to recover disk space safely while preserving valuable Codex history. Alexander asked Codex to map a fragmented public issue cluster against the pull request’s shipped scope because storage growth was obstructing active development and a safe resolution remained elusive. The quotations record Alexander’s motivation and impact; Codex independently researched and authored each target-specific technical comparison.
Publication control: this exact body was previewed and must be explicitly approved before publication. The technical wording must not be attributed to Alexander.
A concrete part of this tracking issue has now shipped in #42039 as part of 0.153.0. The cold-rollout compression path now includes shared and forked histories without a separate shared-compression control, and cwd-based
codex exec resumeselection now reads compressed rollouts.This is meaningful representation-level progress, but it leaves the broader boundaries tracked here intact: it does not introduce structural fork deduplication, prevent repeated media or tool-output writes, define retention or cleanup, or reclaim SQLite freelist/WAL space. The compression feature also remains under development and default-off.
ariccio commentedon Sep 9, 2026
Disclosure: This comment was generated by Codex, operating fully autonomously in the research and drafting of this comment. GitHub attributes it to
ariccio; Alexander selected the scope and approved this exact publication, but is not the speaker or author of Codex's technical claims.The migration rollout coincided with substantial capacity relief on this machine, but a specific compatibility/discoverability exception remains: a September 9 read-only check found all 160 recorded failed-migration rollouts still readable through ordinary filesystem reads, transparently compressed, and absent from the captured thread index. This is correlation, not proof that filesystem compression caused the failures. No repair or retry was attempted.
Is there a supported, non-mutating way to establish these files' application accessibility and diagnose the failed migration without reapplying migration or changing their compression representation? Broader capacity feedback and preservation limitations are being kept in #42648.
Exact current evidence and versions
macOS 26.4 (25E246), arm64, internal APFS; Desktop 26.901.51231/build 8109 with bundled CLI 0.153.4; separate shell CLI 0.153.2.
The migration exception table contained 160 entries marked
failed. Their 804,855,952 logical bytes were read completely; every file retained a private SHA-256 and per-record hashes. All were regular, single-link files carryingUF_COMPRESSED. All had readable session metadata, remained unchanged across the individual read, and matched the exception record's stored size and modification time.Their paths were absent from the captured
threadsindex. Prior index membership remains unknown. Ordinary reads are not athread/read, UI-open, or resume test; those application outcomes remain unestablished. No application command with uncertain migration side effects was used merely to turn this into a green access result.This observation revalidates the same exception cohort after the storage improvement. It does not establish that another user's failed migration has the same cause. Database access was WAL-aware and read-only, not immutable-with-WAL-ignored. The audit's source access was observational; no files, flags, ACLs, databases, or migration state were edited.
Preservation boundary and motivating context
Complete present-file readability does not establish pre-migration fidelity or prove the backup covers subsequent work. The external pre-migration comparison remains pending reconnection. No cleanup command or workaround is recommended here.
Verbatim publication-request excerpt:
The mechanism-specific evidence above is Codex's analysis; the broader personal-impact narrative and developer acknowledgment are confined to the coordination update.