fix: persist container_id in codeInterpreterTool history

[vrtnis]

Replaying a full run history with the codeInterpreterTool fails because the API’s container_id stayed in snake_case and never got mapped to providerData.containerId. As such, I've added a small snakeToCamelCase helper so incoming container_id becomes containerId, and we still convert it back when building the next request. Now the container ID survives in history and a second runner.run(...) won’t throw “missing container_id” anymore.

Changes:

• new snakeToCamelCase utility
• apply it in convertToOutputItem
• continue converting back in getInputItems
• unit tests for both directions

With these changes, replaying the full result.history now succeeds on the second runner.run(...) and the container_id is correctly preserved across runs.

Resolves #253

[changeset-bot]

🦋 Changeset detected

Latest commit: 9fdb8d3

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@openai/agents-openai	Patch
@openai/agents	Patch
@openai/agents-extensions	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[seratch]

Hi @vrtnis, thanks for sending this pull request.

If I understand this pull request correctly,

1. This pull request does not bring anything new to codeInterpreterTool history causes container_id exception on reuse #253, the container_id is already available in providerData
2. I was actually going to take the same approach to covert all the property names to camelCase in the initial phase of this SDK development 😄 but our team decided not to do so. The latest consistent rule is to use snake_case ones (=the original key names) in providerData for OpenAI models

For these two reasons, I don't think this change should be merged.

[vrtnis]

Thanks so much for the thoughtful guidance @seratch and context on the camelCase convention 😄! really appreciate you taking the time to clarify.

You are right that the container_id is already available in providerData. This is true at rest, but getInputItems only looks for containerId, so the value is never read and the request is sent without it.

Essentially, after the first run, history holds providerData.container_id (snake_case).
getInputItems, however, destructures providerData.containerId (camelCase) when building the next request. Because that key isn’t present, container_id is left out of the payload, and the second run fails with “missing container_id”.

While keeping everything snake case, i'm thinking that we can patch getInputItems in openaiResponsesModel.ts like so:

const containerId =
  providerData.containerId ?? providerData.container_id;

This keeps the key in snake_case the whole time, avoids any new helpers or conversions, and ensures the replay works as expected.

Would be happy to open a separate (and much slimmer!) PR for this fix if that sounds good. Let me know!

[seratch]

Thanks for pointing the cause out. Definitely, the line https://github.com/openai/openai-agents-js/blob/v0.0.13/packages/agents-openai/src/openaiResponsesModel.ts#L544 is the cause of the issue. No need to consider providerData.containerId here, so can you just change the property name there? providerData is any typed, so this type of bug could happen (although I introduced internal provider data types for casting).

Having the single line of change should resolve the issue. So, including the change and changeset file in this PR would be appreciated.

[vrtnis]

Just pushed an update, thanks again for the helpful feedback! I’ve removed the camelCase handling and made the one-line fix to directly use providerData.container_id, as suggested

[seratch]

Thank you!