release: 2.32.0

[stainless-app]

Automated Release PR

2.32.0 (2026-04-11)

Full Changelog: v2.31.0...v2.32.0

Features

• api: Add detail to InputFileContent (60de21d)
• api: add OAuthErrorCode type (0c8d2c3)
• client: add event handler implementation for websockets (0280d05)
• client: support reconnection in websockets (eb72a95)

Bug Fixes

• ensure file data are only sent as 1 parameter (c0c2ecd)

Documentation

• improve examples (84712fa)

---

This pull request is managed by Stainless's GitHub App.

The semver version number is based on included commit messages. Alternatively, you can manually set the version number in the title of this pull request.

For a better experience, it is recommended to use either rebase-merge or squash-merge when merging this pull request.

🔗 Stainless website
📚 Read the docs
🙋 Reach out for help or questions

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eccb932db2

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Allow reconnect attempts without requiring a callback

The reconnect path is effectively disabled unless on_reconnecting is provided: _reconnect() returns immediately when _on_reconnecting is None, so callers that set max_retries/delays but omit the callback will never retry and will still fail on the first disconnect. This makes the new retry parameters inert in the default usage path and prevents the advertised websocket reconnection behavior for most clients.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Route recoverable "OK" closes through reconnect logic

The iterator returns immediately on ConnectionClosedOK, so close code 1001 (explicitly marked recoverable in types/websocket_reconnection.py) never reaches _reconnect(). In practice, transient server "going away" closures will terminate iteration instead of retrying, despite being classified as recoverable.

Useful? React with 👍 / 👎.