Some Responses API conversations can safely replay prior response item
IDs because the server stored those items. That assumption breaks when
`store=False`: prior `rs_*` reasoning items and `msg_*` assistant
message IDs are not available on the server for the next turn, so
replaying them can crash with `Item with id 'rs_...' not found` or
similar item lookup errors.
This updates the Responses API payload builder to treat `store=False` as
a stateless replay mode. The visible assistant text is still preserved
in history, but server-side response item IDs are not sent back unless
they are usable without server persistence.
In practical terms:
- Bare `rs_*` reasoning items are dropped for `store=False` because they
only reference server-side state that was not stored.
- Reasoning items with `encrypted_content` are preserved because OpenAI
uses them as the stateless/ZDR way to carry reasoning context forward.
- Prior assistant `msg_*` IDs are omitted for `store=False`; the
assistant message is replayed as ordinary assistant text instead of as a
reference to a stored server item.
Dropping `msg_*` IDs in this case should not remove useful user-visible
context: the text content remains in the request. It only removes an
item identity that the server cannot reliably resolve when
`store=False`. Persisted `store=True` Responses flows continue to replay
item IDs as before.
The regression test mirrors the minimal user story: make one
Responses/Codex call, reuse the returned `AIMessage` in a follow-up
request, and verify the next payload keeps the visible assistant message
and encrypted reasoning context while omitting unresolvable bare item
references.
792c1a743e