Reduce code-mode snapshot allocations by sharing immutable stored JSON values

What variant of Codex are you using?

CLI; the proposed change is confined to the shared codex-code-mode-runtime crate.

What feature would you like to see?

Reduce code-mode allocation overhead by sharing immutable stored JSON values between execution snapshots instead of deep-cloning their payloads.

This is an internal efficiency improvement: it preserves existing capabilities and behavior while making sessions with stored data cheaper to execute, especially when several cells overlap or stored values contain large tool results.

Current allocation cost

When a cell starts, SessionRuntime::start_cell clones the session's HashMap<String, JsonValue>. This copies every JSON payload, including values the new cell never loads. The store/load callbacks and completion paths also clone stored payloads.

Consequently, the cost of taking a snapshot grows with the total size of stored JSON, rather than just the number of keys. Overlapping cells can retain separate copies of the same unchanged data.

Proposed solution

Use HashMap<String, Arc<JsonValue>> for the internal store and completion writes. Continue to clone each cell's key map, but share the immutable JSON payloads behind those keys.

This retains the existing semantics:

• Each cell sees the values present when its snapshot was taken, even if another cell subsequently replaces a key.
• A cell can immediately load its own writes.
• load() still produces independent JavaScript objects; modifying them does not mutate the stored value.
• Completion merges only that cell's writes, so an older snapshot cannot overwrite unrelated concurrent updates.
• Replaced payloads are released once the snapshots retaining them are gone.

There are no public API changes, new dependencies, new configuration, retention limits, or discarded history. Snapshot creation still copies keys and map metadata, but no longer copies the JSON payloads. Reference-count bookkeeping and one shared allocation per stored value are the tradeoff; this is not a claim that every individual store operation becomes cheaper.

Measured benefit

An isolated Divan benchmark compared cloning the old and proposed map representations on Windows x64 in a release build, using 50 samples of 20 iterations:

Store contents	Allocated per snapshot, before	Allocated per snapshot, after
Empty	0	0
Eight 8-byte strings	About 1 KB	552 bytes
Eight 64 KiB strings	About 525.2 KB	552 bytes
Sixty-four 64 KiB strings	About 4.201 MB	4.358 KB

For the largest case, this removes approximately 99.9% of snapshot allocation bytes. Empty and small-string snapshots showed no slowdown in this run. These measurements isolate the map-clone operation; they do not measure whole-session memory, initial insertion cost, or end-to-end execution speed.

Additional information

A focused implementation is available in commit 96dd46d6e81a0d62b614725ad057906372d0ee4d on the implementation branch. It changes only the code-mode runtime, with most added lines devoted to regression coverage.

Validation completed on Windows x64 using the repository's checksum-verified Codex-built V8 artifacts:

• just test -p codex-code-mode-runtime: 75 passed, 0 skipped.
• just clippy -p codex-code-mode-runtime: passed.
• just fmt: passed.

The added tests exercise mutation isolation and overlapping commits, confirm that two live cells share the same 1 MiB payload allocation, and verify that the replaced payload is released after those cells shut down. Existing coverage also checks session isolation and cancellation of pending store commits.

The intended benefit is fewer allocations and less copying for the same code-mode behavior, with a small implementation footprint and no user-facing policy tradeoffs.

Start in the shared codex-code-mode-runtime crate at SessionRuntime::start_cell and trace the store/load callbacks and completion paths described in the issue. Review the focused implementation and its regression coverage, then run just test -p codex-code-mode-runtime, just clippy -p codex-code-mode-runtime, and just fmt; done means immutable stored JSON values are shared while snapshot isolation, mutation isolation, overlapping commits, and payload release remain covered.