Gmail connector schema/runtime mismatch on Windows causes attachment_files calls to fail during argument binding

Start by tracing the Gmail connector's discovery and action-binding paths, then compare the advertised legacy flat schema with the runtime's newer message schema and rollout/version handling. Reproduce the Windows attachment case and add regression coverage for absolute paths, multiple attachment counts, and common or binary extensions; done means discovery and binding accept the same schema and report missing arguments precisely.

Summary

On Codex Desktop for Windows, the Gmail _send_email tool advertised a legacy flat argument schema containing to, subject, body, and attachment_files: string[]. Calls conforming to that advertised schema then failed before Gmail send execution with:

• InvalidActionArgumentsError
• error_code: INVALID_ARGUMENT
• reason: missing_required_argument
• failure_stage: argument_binding

Shortly afterward, the same Gmail connector exposed a different schema that requires a top-level message object with a MIME payload tree and no longer includes attachment_files or the legacy flat fields.

This strongly suggests a schema-discovery/runtime-binder version mismatch during a connector rollout: clients were given the old attachment_files contract while the action binder was already validating against the newer message contract.

Environment

• Windows, Codex Desktop
• Codex CLI/runtime: 0.144.6
• Gmail plugin: 0.1.5
• Gmail connector ID: connector_2128aebfecb84f64a069897515042a44
• Observed: 2026-07-25, Asia/Shanghai

Timeline

• 08:20: An attachment send using the legacy flat schema succeeded.
• 08:56 and 08:57: Two calls with three attachments failed at argument_binding.
• 09:31: Tool discovery still advertised the legacy attachment_files schema; required fields were only to and subject.
• 09:32: A conforming call with four attachments failed with the same structured error.
• During subsequent diagnostics, tool discovery returned the newer schema requiring top-level message and a MIME payload tree.

Validation performed

No test email was sent during diagnosis.

• All failing attachment_files values were absolute Windows paths and were inside the active cwd/workspace.
• Paths contained no spaces, non-ASCII characters, invalid Windows characters, or trailing spaces/dots, and were below 260 characters.
• The attachment arrays were preserved exactly from the model-generated function call through the MCP invocation; no slash conversion, truncation, or JSON escaping corruption occurred.
• The same legacy contract had previously succeeded with multiple attachment counts and common file extensions, including the same extensions used in the first failures.
• Gmail search/read operations remained healthy, and the authenticated Gmail web UI successfully sent the same files, so this was not an OAuth or Gmail account failure.
• The error was returned during connector argument binding, before Gmail send execution.

Expected behavior

Tool discovery and the runtime action binder should expose and validate the same schema version. A call valid under the advertised schema should not fail because the runtime is expecting an undisclosed required field.

Suggested fixes

1. Switch connector discovery schema and runtime action versions atomically.
2. During migration, retain a compatibility adapter from legacy flat fields and attachment_files to the new message.payload MIME tree.
3. Include the exact missing argument name (likely message in this case) in missing_required_argument error data.
4. Add Windows regression coverage for absolute paths, multiple attachment counts, and common/binary extensions.

Privacy

This report intentionally excludes email addresses, subjects, message bodies, filenames, local paths, attachment contents, OAuth data, and raw logs.