web/openai-codex-search-llm-request events make sessions unloadable after restart #24

web/openai-codex-search-llm-request events make sessions unloadable after restart

Summary

Every Codex standalone web search appends a web/openai-codex-search-llm-request
session event to the initiating agent's session log (src/search-event.ts →
recordOpenAICodexSearchRequest). That event type is not in the Harness
core's frozen v0 migration vocabulary, so after any Harness restart the
session can never be observed again:

Failed to load history: failed to observe session "session-bbb17e99-…":
format v0 contains unknown historical event type
"web/openai-codex-search-llm-request" at seq 381;
migration refuses unknown historical events even when ignorable;
source v0 artifact remains unchanged (gateway/internal)

The session data itself is intact (the migrator is non-destructive and the raw
session.jsonl.zstd stays fully readable) — but the UI, and anything reading
through sessionPersistence (e.g. usage-dashboard backfill), can never open
that session again. In my deployment 6 of 26 sessions are affected, all under
one cwd, each containing a handful of these events (9 in the largest log, at
seqs 381–383, 1577–1579, 1877–1879 out of ~37k events).

Root cause (verified against installed code)

• Writer: dsh-codex@0.2.7 src/search-event.ts registers the type only in
  the runtime KNOWN_SESSION_EVENT_TYPES set (installOpenAICodexSearchEvent),
  which covers live in-process reads.
• Reader/migrator: @deepseek-ai/dsh-session-format-v0-to-v1 (and the copy
  bundled in @deepseek-ai/dsh-session-persistence-jsonl/lib/worker.cjs)
  validates every historical event against the frozen
  RELEASED_V0_EVENT_DISPOSITIONS table (51 types). That table contains the
  sibling web/deepseek-search-llm-request but not
  web/openai-codex-search-llm-request, and assertReleasedEventPayload
  throws SessionFormatUnsupportedMigrationError for any unknown historical
  type unconditionally ("even when ignorable"). The v1→v2 stage
  (transformReleasedEvent) refuses unknown types the same way, and
  RELEASED_V0_EVENT_DISPOSITIONS is Object.freezed, so there is no
  runtime registration path for the migration.
• The old Harness process kept working because the sessions were already
  observed before the search events were appended; the restart forced a fresh
  v0→v1 migration and exposed it. So this bites on every restart for any
  session that used Codex web search — the poison accumulates silently while
  running and detonates on reboot.

Versions (all latest at time of writing — no update fixes it)

• @deepseek-ai/dsh 0.1.5-rc.1, @deepseek-ai/dsh-session-format-v0-to-v1
0.1.5-rc.2 (newest on npm; table still lacks the type)
• dsh-codex 0.2.7 installed; 0.2.9 (newest on npm) still writes the
  event identically (src/search-event.ts unchanged)

Suggested fixes (maintainer's pick)

1. Stop writing the event to the session log by default (or gate it behind a
   config flag, e.g. searchRecordRequest: false), keeping the request data
   in memory/opaque diagnostics instead; or
2. Write it with ignorable: true and coordinate with core so the
   migrator tolerates ignorable unknown types (currently it refuses them even
   when ignorable); or
3. Upstream the event type into core's frozen disposition table (core change).

Option 1 alone un-bricks all future sessions; already-written logs stay
unopenable until core learns the type, so users with affected sessions still
need (a core-side allowance or) a repair path.

Workaround for affected users

None that preserves the log: relabeling to web/deepseek-search-llm-request
fails its exact deepSeekSearchBodyValue shape, and every other known type
has a strict payload disposition plus later-stage (v1→v2 turn-tracking)
invariants. I recovered my conversations by extracting user/assistant text
from the raw zstd logs (read-only). To stop new poison I would have to pin
web.searchProvider: deepseek-official (whose pre-dispatch event is in the
frozen table) — but that backend needs a DEEPSEEK_API_KEY I don't have, so
currently there is no prevention that preserves working search.