Hosted `shell` Continuations Require Missing `shell_call_output`

I reproduced a closely related variant locally using the Conversations API instead of previous_response_id, and it shows the same underlying failure mode.

What I tried:

1. Created a new conversation with client.conversations.create()
2. Sent a first background response in that conversation using hosted shell with container_auto.
3. Waited until the first response reached completed.
4. Sent a second response using the same conversation ID, not previous_response_id.

Observed behavior:

• The first response completed successfully.
• Its returned output contained:
  • a user message
  • reasoning items
  • a shell_call
  • a final assistant message describing the shell result
• But the persisted conversation items did not include a corresponding shell_call_output.
• The second response then failed with the same class of error: No tool output found for shell call call_...

So this does not seem limited to previous_response_id. I saw the same issue when continuing from stored conversation state.

What fixed it:

• Before sending the second turn, I deleted the shell-related items from the conversation:
  • shell_call
  • shell_call_output
  • local_shell_call
  • local_shell_call_output
• After removing the shell tool artifacts, the second turn succeeded and the conversation still retained the plain user/assistant transcript.

Interpretation:

• The hosted shell execution clearly completed.
• The assistant message had the shell result.
• But the conversation state was left in a form that the next turn could not replay.
• That strongly suggests an API/state persistence bug or inconsistent contract around hosted shell tool continuation, rather than simple client misuse.

If useful, I can also share the exact repro script and the conversation item shapes I observed before and after cleanup.