[Desktop 26.721.4979.0] list_threads schema advertises query but runtime rejects it as unrecognized

Open 💬 2 comments Opened Jul 25, 2026 by aidawilliam41-ops

Environment

Codex Desktop: 26.721.4979.0
Bundled/configured CLI: 0.146.0-alpha.3.1
Windows 11 25H2, build 26200.8037

Summary

The list_threads schema surfaced to the caller advertises an optional query field, but the runtime validator rejects that exact field as unrecognized.

Surfaced schema:

type list_threads = (_: { limit?: number, query?: string }) => any;

The tool description also said:

Use an optional query to find a specific thread before reading or steering it.

Exact sanitized call:

{"limit":20,"query":"<thread-title search>"}

Runtime rejection:

list_threads received invalid arguments: arguments: Unrecognized key: "query".

The occurrence was bounded between 2026-07-25 19:14:14.887 MSK and 19:16:25.125 MSK. The exact tool-call id and separate app-tool wrapper version were not surfaced.

Expected behavior

Either:

query is accepted and filters the result as documented; or
the generated/surfaced schema and description do not advertise it.

Actual behavior and impact

The caller receives a valid-looking field that fails before thread listing begins. This adds a failed tool turn and can break agents or scheduled workflows that trust the surfaced schema.

The bounded workaround is to omit query, use the supported result limit, and filter returned tasks locally. That workaround does not resolve the schema/runtime contract mismatch.

Related issue

#35030 reports list_threads hanging in scheduled runs. It is related to the same tool surface but does not report this deterministic query schema/runtime mismatch.

Suggested fix

Generate the surfaced schema from the same validator used at runtime.
Add a parity test that submits every advertised optional field.
If query is intentionally unsupported, remove it from both the schema and description.
Return a structured capability/version mismatch when a stale wrapper calls a newer validator.

No task titles, thread ids, usernames, local paths, credentials, or private logs are included.

View original on GitHub ↗

2 Comments

aidawilliam41-ops · 22 days ago

Additional schema-bound mismatch: `limit` maximum is not surfaced

A separate deterministic mismatch was observed on the same list_threads tool surface.

The surfaced type allowed an unconstrained number:

type list_threads = (_: { limit?: number, query?: string }) => any;

Exact sanitized call:

{"limit":100}

Runtime rejection:

Too big: expected number to be <=50

Changing only the value to 50 succeeded.

Expected: the surfaced JSON schema includes maximum: 50, or the runtime accepts values allowed by the schema.

Actual impact: a caller that trusts the advertised schema incurs a failed tool turn before correcting to the undocumented bound.

Suggested fix: generate numeric constraints from the same runtime validator and add a parity test for advertised bounds. The exact separate tool-wrapper version for this occurrence was not surfaced.

aidawilliam41-ops · 7 days ago

Still reproducible on Desktop 26.818.2441.0

The same tool-contract mismatch remains present in the current Windows Desktop package.

Current surfaced declaration:

list_threads({ limit?: number, query?: string })

The current description still says that the optional query can find a specific task before reading or steering it.

A bounded read-only probe using a unique nonmatching query:

{"limit":1,"query":"<unique-nonmatching-probe>"}

returns:

list_threads received invalid arguments: arguments: Unrecognized key: "query".

The related numeric constraint also remains absent from the surfaced declaration. A separate read-only call with:

{"limit":100}