Windows exec_command: oversized PowerShell cmd fails before launch with os error 206

Codex tool declaration and Windows command transport failures

Sanitized maintainer report. Observations below were collected on September 13, 2026; this submission does not claim a newer-build reproduction.

This report focuses on the measured oversized PowerShell command passed to exec_command. Related reports: #9688 (large apply_patch input), #38985 (sandbox setup payload). The numeric-bound observation below corroborates the existing #40232 and is included for context; it is not presented as a new discovery.

Environment

Windows; Codex Desktop registered package 26.908.4834.0. Embedded package.json version 26.908.40834. Observed September 13, 2026. The two versions are separate observed metadata, not assumed equivalent to an upstream Git revision.

1. Numeric constraints missing from model-visible tool declaration

The installed list_threads JSON schema includes integer minimum 1 and maximum 50. Runtime validation independently enforces both. The model-visible declaration reduces this to optional number, with a description that does not state either bound.

Reproduction: call list_threads with limit 100. Actual: tool error, 'list_threads received invalid arguments: limit: Too big: expected number to be <=50.' Calling with 50 succeeds. The exposed tool also has no cursor, so repeated calls cannot be assumed to paginate beyond the recent results.

Observed mismatch: validation enforces a contract that the model-facing description does not fully communicate. This report does not identify which schema/declaration conversion component removes the constraints. Please investigate that conversion boundary.

Installed source: app.asar member webview/assets/app-initial-d9bed9d614d8.js; JSON schema line 2541, validator/dispatch line 2662, listing line 2645. Member SHA256 7c3a89e7e224f76031b45a88f72af8cd60f0c3d47aac9ca34b2c70e11dfe9867.

2. Bulk evidence placed into Windows process arguments

A historical call constructed a PowerShell script by embedding serialized tool responses in quoted WriteAllText calls. The JavaScript input was 11,352 UTF-16 units; its expanded cmd was 36,972, independently measurable from original saved records. The documentation response alone contributed 23,675 serialized units. No shell injection or broken quoting is asserted.

Actual: process creation failed with 'The filename or extension is too long. (os error 206)'. Windows CreateProcessW limits the command line to 32,767 characters including the terminating null. The script alone exceeded that limit, without counting the executable name or quoting overhead. The rejected process did not start.

The observed recovery used direct file editing and a shorter verification command. This demonstrates recovery, not automatic prevention. The original oversized command was not relaunched during investigation. The measurement was made with its shell invocation removed.

Please investigate where Windows command-size compatibility is validated before process creation and how an oversized call can give an actionable error without confusing command size with a filesystem-path error. This is a bug report, not approval of a replacement transport architecture.

Official boundary: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw

Limits

No patch, full preventive regression suite, or permanent resolution is claimed. The inspected installed archive was a built vendor package; its inspected archive inventory did not include the referenced development source/build inputs or source map. This is a bounded package observation, not an estate-wide absence claim. No vendor binary or installed archive was modified.

Start with the inspected app.asar member webview/assets/app-initial-d9bed9d614d8.js, especially JSON schema line 2541, validator/dispatch line 2662, and listing line 2645. Trace the model-facing schema conversion and the Windows process-launch boundary, using the list_threads limit mismatch and os error 206 observations as reproduction context. Done means the relevant validation or error-reporting behavior is identified and covered by an appropriate regression check.