fix: default unknown tool schemas to open objects#22380
Conversation
celia-oai
changed the title
celia-oai
force-pushed
the
dev/cc/new-default
branch
from
7aefdf6 to
9d3746f
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9d3746f0c5
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| schema_types.push(JsonSchemaPrimitiveType::String); | ||
| // With no schema hints, fall back to an open object so unknown | ||
| // tool argument shapes can still carry arbitrary named fields. | ||
| schema_types.push(JsonSchemaPrimitiveType::Object); |
There was a problem hiding this comment.
does this mean any in JsonSchema speak?
There was a problem hiding this comment.
feels we are changing from one incorrect schema to another
There was a problem hiding this comment.
no, any is any value, and this is any json object (a subset of any value). we don't want to support any value because it will error out for some responses api checks
There was a problem hiding this comment.
I still think the concern stands: for nested property schemas with only metadata, we’re not preserving an unknown shape.. we’re forcing a scalar-looking argument like query into an object
3 participants
Why
Some tool providers, especially MCP servers, can supply input schemas that omit a
typeand do not include enough structural hints for Codex to infer one. Previously,sanitize_json_schematreated those unknown schema nodes as strings. That made the schema valid, but it also degraded permissive or object-like tool contracts into scalar guidance, which can cause the model to lose the real argument shape and produce connector calls that fail later.Responses currently still rejects some malformed function schemas even when
strict: false, so Codex needs a short-term best-effort sanitizer instead of passing every raw provider schema through unchanged. The intended fallback is now an open JSON object: not any JSON value, but an object that can carry arbitrary named fields.What Changed
codex-rs/tools/src/json_schema.rsfromstringto an open object schema.type: "object"with emptypropertiesand explicitadditionalProperties: true, allowing arbitrary named fields when Codex cannot infer a narrower schema.codex-toolsandcodex-coretests for empty schemas, nested empty schemas, dynamic tools, and MCP tool specs so the recursive fallback behavior is explicit.Verification
cargo test -p codex-toolscargo test -p codex-core test_mcp_tool_property_missing_type_defaults_to_open_object