Codex voice scheduling over-blocks on familiar Gmail shorthand and repeats clarification requests

What version of the Codex App are you using (From "About Codex" dialog)?

Desktop app; exact build not independently verified in this report.

What subscription do you have?

Not included in this public report.

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS). Codex desktop voice conversation with browser-assisted scheduling.

What issue are you seeing?

The assistant mishandled ordinary email shorthand during an explicitly authorized calendar-scheduling task and entered an unnecessary clarification loop.

A contact supplied two Gmail addresses written as local-part followed by "@gmail", omitting ".com". The assistant correctly read the text, but treated the familiar provider shorthand as a hard missing-information blocker instead of applying proportionate contextual judgment. It sent an additional clarification message to the contact, created only an internal calendar hold, and repeatedly told the user that external invitations could not be sent until the contact confirmed the endings.

The user had already authorized scheduling and then pointed out that the addresses were intentionally abbreviated Gmail.com addresses. The assistant's repeated procedural responses forced the user to explain an inference a human assistant would normally make immediately.

This is a reasoning, autonomy-calibration, and conversational recovery report, not evidence of a browser extraction failure or a malicious attempt to trick the model.

What steps can reproduce the bug?

Anonymized scenario for evaluation, not a claim of a deterministic fresh-session reproduction:

1. In a browser-assisted scheduling task, provide an existing contact conversation agreeing to a meeting and listing two addresses as "@gmail" and "@gmail". These placeholders are not real recipients.
2. Explicitly authorize sending a calendar invitation to the two contacts and the user's colleague.
3. Observe whether the assistant recognizes the conventional Gmail.com shorthand in context or repeatedly blocks on the missing suffix.
4. Have the user clarify that both are Gmail.com addresses.
5. Verify that the assistant promptly applies that clarification and completes the existing event, rather than asking the same question or sending unnecessary external clarification messages.

Observed in one long-running desktop voice conversation on September 9, 2026. The full private transcript and real addresses are deliberately omitted.

What is the expected behavior?

Recognize common provider shorthand and make a risk-proportionate decision using the explicit user intent and surrounding conversation. Where a recipient identity is genuinely ambiguous, use one concise confirmation rather than a repeated hard-blocker loop. Once the user clarifies the intended Gmail.com normalization, apply it immediately.

Avoid burdening either the user or their contact with repeated clarification of the same obvious detail. Maintain accurate distinctions between an internal calendar hold, an invitation actually sent, and a guest accepting that invitation.

This is not a request to guess arbitrary addresses or weaken recipient-verification safeguards. The defect is failure to distinguish a familiar, high-confidence shorthand case from genuinely uncertain recipient identity.

Additional information

User impact: unnecessary back-and-forth, delayed business scheduling, and a substantial loss of confidence in the assistant's practical judgment.

Please consider this anonymized scenario for a reasoning/agent-workflow regression evaluation or training-feedback triage. No claim is made that filing an issue guarantees inclusion in training.

Public privacy scope: no names, actual email local-parts, organization/customer details, calendar or meeting links, private message screenshots, session identifiers, credentials, or raw logs are included.

A search for related clarification/email reports found adjacent but different failures; a specific search for Gmail shorthand returned no matching issue. Root cause is not established: model behavior, prompting, and orchestration context may all contribute.

No files or tests are named. Start by locating the desktop voice scheduling and recipient-verification workflow, then reproduce the anonymized Gmail shorthand scenario if possible. Done means a high-confidence shorthand case is handled without repeated clarification, while genuinely ambiguous recipients still receive concise confirmation and event state remains accurate.