fix(agent): omit over-long item ids when replaying Codex Responses input

[adambiggs]

What

Both Codex Responses replay paths (_chat_messages_to_responses_input and _preflight_codex_input_items) now route assistant-message item ids through a shared _replayable_item_id helper that omits any id longer than 64 characters instead of sending it.

Why

The chatgpt.com/backend-api/codex endpoint caps input item ids at 64 characters and rejects longer ones with HTTP 400 string_above_max_length. With store=False (our default) the backend returns ~400-char encrypted message ids on response.completed; echoing those ids back inside codex_message_items on the next turn fails the entire request, breaking every subsequent turn of the session.

id is optional on replayed assistant messages, so dropping a backend-illegal id is safe — the message content, status, and phase still replay intact (phase is what the prefix-cache guidance actually cares about).

How to test

scripts/run_tests.sh tests/agent/test_codex_responses_adapter.py

New tests cover the helper's accept/reject boundary (exactly 64 chars accepted, 65+ rejected, whitespace/non-string rejected) and both replay paths: a ~400-char encrypted id is omitted while content/phase survive, and backend-legal ids are preserved verbatim.

Full tests/agent + tests/run_agent suites: 5684 passed, 0 failed.

To reproduce the original failure manually: run hermes against ChatGPT-plan Codex OAuth (gpt-5.5), complete one assistant turn, then send a second message — pre-fix the second request 400s with string_above_max_length on the replayed message item id.

Platforms

Tested on Linux (x86_64, Python 3.11). Pure data-normalization change, no platform-specific behavior.

🤖 Generated with Claude Code

[liuhao1024]

Verification: Looks clean

Reviewed the Codex Responses input-item ID length cap. The fix correctly addresses the HTTP 400 string_above_max_length error from chatgpt.com/backend-api/codex when replaying encrypted message IDs.

Verified:

• _replayable_item_id() correctly returns None for non-string, empty, and >64-char IDs
• Applied at both call sites (_chat_messages_to_responses_input and _preflight_codex_input_items)
• The 64-char threshold matches the backend's documented limit
• Tests cover boundary cases (exactly 64 chars legal, 65 chars dropped, non-string dropped, empty dropped)
• id is optional on replayed assistant messages per the Responses API spec, so omitting it is safe

Good defensive fix for a silent failure mode that would be hard to diagnose in production.

[teknium1]

Thanks for the focused helper-based fix and boundary tests. #62225 has now landed the same 64-character guard at both replay boundaries, with full current CI and end-to-end preflight coverage. Closing as superseded; your parallel contribution is credited on the merged PR and issue closeout.