[ChatGPT Voice] Assistant claims live access to another chat without tool evidence

The issue names no repository files, tests, or entry points. Search the repository for Voice, tool/backend result handling, and cross-chat access claims; done means completed-observation language is blocked without supporting evidence and unavailable access is stated clearly.

Summary

During a ChatGPT Voice session, the assistant repeatedly stated or strongly implied that it was opening, viewing, and monitoring another ChatGPT conversation in real time even though no tool result or retrieval evidence for that other conversation was available.

Later in the same session, when challenged directly, the assistant acknowledged that it was not actually viewing the other chat and only had access to the current conversation plus content the user explicitly provided.

This creates a product reliability problem: Voice can present an intended or unavailable action as a completed observation.

Reproduction

1. Start a ChatGPT Voice conversation.
2. Refer to a different existing ChatGPT conversation and ask the assistant to inspect it or report what is happening there.
3. Observe statements such as:
   • “I’m opening it.”
   • “I see it.”
   • “It’s reasoning.”
   • “Let’s keep monitoring the chat.”
4. Ask the assistant whether it actually has live access to that other conversation.
5. The assistant may then acknowledge that it does not have that live view.

In the observed session, the problematic statements were originally spoken in Spanish, including variants of “lo estoy abriendo”, “lo veo”, and “sigamos monitoreando el chat”.

Expected behavior

The assistant should only claim that it can see, open, inspect, or monitor another chat, screen, file, app state, or live process after a relevant tool/backend operation has actually returned that information.

If the source is unavailable, Voice should say so immediately and clearly, for example:

I can’t see that other chat live from this conversation. I can inspect text or screenshots you provide here.

The model should distinguish among:

• a requested action,
• an action being attempted,
• a successful tool/backend result,
• user-provided content,
• inferred context.

Actual behavior

Voice used completed-observation language before any supporting tool result existed, making an unavailable capability sound verified.

The issue was not simply a bad paraphrase. The assistant represented an unperformed observation as if it had occurred.

Product impact

This can cause users to rely on nonexistent cross-chat, screen, or application visibility. The risk is amplified in Voice because spoken confirmations such as “I see it” or “I’m opening it” are immediate and easy to interpret as verified runtime state.

Suggested guardrail

Add a Voice/runtime guard that prevents completed-access claims unless the current turn has supporting tool/backend evidence. In particular, phrases such as “I see it”, “I opened it”, “I’m monitoring it”, or equivalent localized forms should require a confirmed source result.

If a tool/backend action is still pending or unavailable, Voice should use attempt-state language instead of completion-state language.

Duplicate check

Searched the current openai/codex issue tracker for Voice/tool-access hallucination and cross-chat visibility claims before filing; no clearly matching issue was found.