{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicxbyud37yun34ky5fgzdrs3i5msggcih2pq6rmulonn6owxipnwu",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mgkgs6jitbg2"
  },
  "path": "/t/hosted-shell-continuations-require-missing-shell-call-output/1375917#post_4",
  "publishedAt": "2026-03-08T13:19:45.000Z",
  "site": "https://community.openai.com",
  "textContent": "I reproduced a closely related variant locally using the Conversations API instead of previous_response_id, and it shows the same underlying failure mode.\n\nWhat I tried:\n\n  1. Created a new conversation with client.conversations.create()\n  2. Sent a first background response in that conversation using hosted `shell` with `container_auto`.\n  3. Waited until the first response reached `completed`.\n  4. Sent a second response using the same conversation ID, not previous_response_id.\n\n\n\nObserved behavior:\n\n  * The first response completed successfully.\n  * Its returned output contained:\n    * a user message\n    * reasoning items\n    * a `shell_call`\n    * a final assistant message describing the shell result\n  * But the persisted conversation items did not include a corresponding `shell_call_output`.\n  * The second response then failed with the same class of error:\n`No tool output found for shell call call_...`\n\n\n\nSo this does not seem limited to previous_response_id.\nI saw the same issue when continuing from stored conversation state.\n\nWhat fixed it:\n\n  * Before sending the second turn, I deleted the shell-related items from the conversation:\n    * `shell_call`\n    * `shell_call_output`\n    * `local_shell_call`\n    * `local_shell_call_output`\n  * After removing the shell tool artifacts, the second turn succeeded and the conversation still retained the plain user/assistant transcript.\n\n\n\nInterpretation:\n\n  * The hosted shell execution clearly completed.\n  * The assistant message had the shell result.\n  * But the conversation state was left in a form that the next turn could not replay.\n  * That strongly suggests an API/state persistence bug or inconsistent contract around hosted shell tool continuation, rather than simple client misuse.\n\n\n\nIf useful, I can also share the exact repro script and the conversation item shapes I observed before and after cleanup.",
  "title": "Hosted `shell` Continuations Require Missing `shell_call_output`"
}