Dump byte-diff baseline is in-process, so the first request after a restart has no diff

[ualtinok]

Verified in this repo after ALF routed the equivalent report (cortexkit/anthropic-auth#158) here. Same defect, same cause.

What happens

previousBodies in packages/opencode/src/dump.ts:18 is a module-level Map. It is the only baseline the byte-diff has, so it dies with the process. Every dump written by a freshly started plugin carries diff: null.

Reproduced by dumping two requests in one module instance, then re-importing the module (a restart) and dumping a third:

request 2 (same process)     diff=changed@63
request 3 (after restart)    diff=NONE

Why this one matters more than it looks

The diff exists to answer one question: what changed on the wire between consecutive requests. The single most valuable instance of that question in this project has been the first request after a restart, because that is where prompt-cache busts concentrated — it is the reason openai-auth-sessions.json exists at all, persisting Codex thread ids so a restart does not mint a new prompt_cache_key.

So the instrument is blind on precisely the request it was built to explain. An operator restarts to test a fix, the cache busts, and the dump for that request reports no diff — not "no change", but no comparison at all.

Direction

Persist the last body per dump key alongside the dumps rather than only in memory, and load it lazily on the first dump for that key after start. The dump directory already holds the bodies; a small sidecar (or reading the most recent prior body for that session key) restores the baseline without changing the wire path.

Worth keeping the in-memory map as the fast path and treating disk as the cold-start fallback, so steady-state dumping does not gain a read per request.

Note the related report on the sibling repo about a requested-but-unread diagnosis header does NOT apply here: this plugin sends x-codex-beta-features: terminal_resize_reflow, which is a feature negotiation rather than a diagnosis channel, and nothing is expected back.

[ualtinok]

One design constraint for whoever takes this, since the obvious storage location is the wrong one.

The tempting shape is to persist the baseline beside the Codex thread ids in openai-auth-sessions.json — it is already on disk, already survives restarts, and already keyed by session. Do not. Three reasons:

• Dumping is opt-in and default off. Putting its bookkeeping in a production state file means either writing debug state on every request for the 99% of users who never enable dumps, or a conditional write path in a file that has its own locking discipline.
• That file is load-bearing for prompt-cache continuity. A debug instrument should not be able to corrupt, lock-contend with, or grow the file whose whole job is keeping prompt_cache_key stable across restarts. The failure mode of a broken diff is a missing diagnostic; the failure mode of a broken sessions file is a cache bust on every restart.
• Lifetime differs. Clearing the dump directory should clear the baseline with it — otherwise the next dump diffs against a body whose dump no longer exists, which is worse than no diff because it looks authoritative.

The baseline belongs in the dump directory, next to the artifacts it describes. Storing a hash rather than the full body is fine for detecting that something changed, but the diff reports first/last changed byte offsets, so reconstructing those needs the bytes — and the previous body is already sitting in the dump directory as a .body.json. Reading the most recent prior body for that key on cold start may need no new file at all.