Repository navigation
[Dots][macOS] Voice requests for local browser-control tasks return unconfirmed handoffs with no verified task execution #52201
Description
Environment
Observed October 8, 2026 using ChatGPT dot voice with a user's macOS computer. Reported client user agent: Codex Desktop/26.1002.52244 (Mac OS; arm64). Local browser-control runtime and Chrome/extension versions were not independently inspected during this incident.
Observed sequence
- User has the intended signed-in administrator console open in local Chrome and explicitly authorizes inspection and the requested administrative work.
- Voice task requests local-computer execution through the supported dot_voice.notify_parent route.
- Calls repeatedly return
voice_parent_unconfirmed: outcome uncertain, do not send another delegation or use another route. Other calls returnvoice_parent_context_pending: spoken context could not be confirmed yet. - No local browser-read result, input result, or newly created task reference is confirmed back to the voice task. User reports seeing no new browser-control task or interaction.
- User restarts and explicitly asks for a fresh local browser-control chat. Its creation is still not confirmed after the request.
Expected / actual
Expected: an authorized local browser task is visibly created, acquires its supported runtime, and returns a concrete read/action milestone; otherwise a specific actionable failure is returned.
Actual: delegation outcome remains uncertain, with no verified local execution. Repeated status explanations did not deliver the requested work. The user eventually chose manual instructions.
Diagnostic boundaries
This report describes the handoff/task-start observation, not proof that the Chrome extension itself is broken. The local browser runtime was not directly tested here; extension installation, native-host state and runtime attachment have not been independently verified in this incident. A separate simple task reportedly responded, but this does not establish browser control.
No local administrative changes were confirmed. Private user/account identities, URLs, task IDs, transcripts and credentials are omitted.
Related: #51810 reports missing browser/desktop runtime in delegated macOS tasks on the same reported desktop version; #48322 reports Chrome browser route failures. Shared cause is unconfirmed. #52199 concerns a separate Linux cloud text-input failure and should not be merged as the same proven defect.
Please investigate voice-to-main context confirmation, task creation/result correlation, and local runtime attachment, and provide a bounded actionable recovery instead of uncertain handoff loops.
Activity
github-actions commentedon Oct 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
gimperex-cmd commentedon Oct 10, 2026
We are observing the same voice-to-task handoff failure on October 9–10, 2026. During a live Dot call from the ChatGPT Android app, requests to start a harmless task on a connected Mac repeatedly return voice_parent_unconfirmed / UNAVAILABLE, with the message “The outcome is uncertain. Do not send another delegation or use another route to main.” No new task reference or successful launch is confirmed. The user reports that requests entered through the Mac text chat work; opening the desktop apps does not resolve the voice-originated failure.
There is also a potentially separate visibility issue: the live conversation is not updating in the visible chat. An explicit send_text_to_user test returned accepted, and read_messages subsequently retrieved the exact message from the ChatGPT room history, but the user could not see it. This confirms backend recording of that test message, not frontend visibility. A common cause for these two symptoms has not been established.
Environment: ChatGPT Android 1.2026.272, Android 16, Samsung SM-F946B; connected macOS computer (desktop version not verified). Please investigate voice-to-parent handoff confirmation and message visibility/result correlation. No claim that the private MCP tunnel caused the failure, and no verified recovery so far.
Yelsmeky commentedon Oct 12, 2026
Related report: #53445. We’re seeing intermittent voice-to-local-task coordination failures on macOS, including earlier successful handoffs followed by stalled requests. Sometimes the voice assistant continues reporting that it cannot act while the requested task becomes visibly active, acknowledging execution only later; other times no execution is confirmed. Similar user-visible symptoms; a shared root cause is not established.
mauricioharger commentedon Oct 13, 2026
On October 13, 2026, we observed repeated failures during ChatGPT Dot voice calls from iOS when requesting an email send and an Outlook calendar location update. The dot_voice.notify_parent calls returned:
error.code: voice_parent_unconfirmed
error_code: UNAVAILABLE
message: “The outcome is uncertain. Do not send another delegation or use another route to main.”
The voice session received no confirmation that either requested action had executed. Read-only Outlook calendar queries continued to work. The user then submitted the same calendar update through the Dot’s text chat, and a subsequent calendar read confirmed that the location had changed correctly. The email send remained unconfirmed during the call.
Environment: ChatGPT iOS 1.2026.272, iOS 27.0.1. We have not established a root cause. Please investigate voice handoff confirmation and request/result correlation; these observations do not establish an Outlook provider failure.
stewardshipspot-bot commentedon Oct 14, 2026
On October 14, 2026, we encountered repeated voice-to-task handoff failures during a ChatGPT dot call. The requests returned error code voice_parent_unconfirmed, error_code UNAVAILABLE, and “The outcome is uncertain. Do not send another delegation or use another route to main.” No task-start or execution confirmation was received in the voice session.
Read-only connector actions continued working, and creating a OneDrive folder directly succeeded. A later folder listing confirmed it was empty. When the user entered the upload request directly in the dot’s text chat, the main conversation acknowledged receiving it. Upload completion was still pending at the time of this report.
Reported client: ChatGPT iOS 1.2026.272, iOS 27.0.1. We have not established a root cause. These observations do not establish a OneDrive failure or prove that every uncertain handoff was undelivered. Please investigate voice-to-task delivery confirmation and request/result correlation.
keegoid commentedon Oct 16, 2026
Reproduced October 16, 2026 on macOS 27.0.1, after updating the ChatGPT desktop app to version 26.1013.31256 and starting a fresh voice call.
The user reports that the same failure also occurred before either update, on the previous macOS version (recalled as 26.6.2; not independently verified) and the previous ChatGPT desktop version (exact version not verified). The failure therefore predates the current OS and desktop-app updates.
Voice-to-main requests through dot_voice.notify_parent repeatedly return:
error.code: voice_parent_unconfirmed
error_code: UNAVAILABLE
message: “The outcome is uncertain. Do not send another delegation or use another route to main.”
The latest read-only diagnostic handoff returned this error after approximately 17.5 seconds. No request ID was returned. The connected Mac reports connected, attached, and authorized for tasks. In contrast, requests entered in the main text chat successfully created a diagnostic Mac task, executed local shell commands, and resumed an existing task in read-only mode.
The desktop update and fresh voice session did not resolve the failure. This narrows the observed problem to voice handoff confirmation; it does not establish the root cause or prove every uncertain request was undelivered. Please investigate voice-to-main context confirmation and request/result correlation, and provide recovery guidance.
scott-cmd11 commentedon Oct 18, 2026
On October 17, 2026, I encountered another ChatGPT dot voice-to-task handoff failure. The handoff returned voice_parent_unconfirmed / UNAVAILABLE with: “The outcome is uncertain. Do not send another delegation or use another route to main.”
I did not retry the delegation. A subsequent send of written companion text into the dot chat was accepted, but receipt and execution of the uncertain task request remained unconfirmed. Accepted companion text does not establish task execution, and the uncertain error does not prove non-delivery.
The affected voice client, app version and exact failure timestamp in UTC are unavailable from the supported evidence reviewed. The destination task uses a Mac; that does not establish which client originated the voice call.
This disrupts hands-free use and leaves uncertainty about duplicate execution. Could maintainers triage this and provide a supported procedure to reconcile an uncertain request before safely retrying? Please investigate receipt, context transfer, task interruption and response acknowledgment separately. A root cause has not been established.
kobikn commentedon Oct 18, 2026
I'm experiencing the exact same (and some more) since Oct 9th and dot is completely unusable for me since.
Kiwwa commentedon Oct 19, 2026
I’ve encountered similar problems asking my dot by voice to start conversations on connected Macs. Two examples from October 14–15, 2026:
The error wording above comes from the contemporaneous conversation, rather than a captured raw service response. I don’t have verified app build numbers for those incidents.
These comparisons show that local task creation and execution worked through text, while the voice requests did not produce confirmed handoffs or launches. They don’t establish whether the voice requests were never delivered, were delayed, or lost their acknowledgements. I haven’t verified any later duplicate task resulting from those uncertain requests.
This also appears related to #53445. The practical problem is that voice leaves me unable to tell whether work has started or whether retrying could duplicate it.
Is there a recommended way to capture diagnostics for a controlled voice-versus-text comparison, including request receipt, task creation and execution confirmation? Is there a safe way to check the outcome of an unconfirmed voice request before retrying?
eatrhw-commits commentedon Oct 19, 2026
Final revised GitHub comment — NOT POSTED
For: #52201
Still reproducing on October 19, 2026.
Environment (user-confirmed in About This Mac): MacBook Pro, 2022, Apple M2; macOS Golden Gate 27. Desktop app version reported in session: 26.1013.40934.
During a dot voice call, an authorized request to resume an existing website task through dot_voice.notify_parent returned:
error_code: UNAVAILABLE
code: voice_parent_unconfirmed
message: “The outcome is uncertain. Do not send another delegation or use another route to main.”
The error has persisted across voice sessions before and after the app update. Instructions typed directly into the same dot’s chat have successfully started work in earlier tests. Read-only email/chat tools have also worked during voice calls.
Additional delivery/result mismatch observed today:
Thus an error response did not reliably establish nondelivery. This is distinct from the voice-to-task error; we have not established a shared cause or that any uncertain task request executed. Please investigate both delivery confirmation and error/result correlation.
A Desktop Commander ping succeeded in an earlier diagnostic, but that does not prove browser control. Separate browser attempts have encountered ScreenCaptureKit error -3811; no common cause has been established. Failed voice requests themselves do not establish a browser or website failure.
Impact: approved work cannot reliably be initiated through voice, requiring repeated typed instructions. Ambiguous delivery also creates duplicate-action risk. In-app feedback has been submitted.
Please provide a supported way to check receipt/status and safely recover uncertain requests without duplicate execution. Private diagnostic details can be supplied through support if needed.
ericliuzh commentedon Oct 22, 2026
Adding another reproduction of
voice_parent_context_pendingon October 22, 2026, while using ChatGPT dots voice on an iPhone with a connected Apple Silicon Mac mini.Environment
Observed behavior
I asked my dot by voice to run harmless local commands, including
pwdand a Desktop directory listing. Repeated calls to the voice-to-main handoff returned:This workflow had worked for me for roughly one to two weeks before I first encountered this failure today. Updating the Mac app, restarting/reconnecting, and ending and restarting voice calls did not resolve it in the observed attempts.
A separate recovery path did eventually execute
pwdsuccessfully on the Mac, with exit code 0: the coordinating thread read the recent voice transcript and created the local task through its normal task-creation path. However, subsequent direct voice handoff attempts still returned the same error. Successful local execution therefore did not demonstrate that the direct voice handoff had recovered. I did not independently test an equivalent typed request during this incident.Incoming updates could still reach the voice conversation while outgoing handoffs failed. Recovery through transcript reading introduced substantial user-visible delay. A later directory-listing request had no verified execution result at the time of this report.
Expected behavior
An authorized voice request should reach the coordinating thread promptly and produce a clear execution receipt or actionable failure, without requiring the user to repeat the request in text or repeatedly ask whether work actually started.
Please investigate voice-context confirmation and handoff delivery, and provide a supported way to reconcile failed or uncertain requests without duplicate task creation. Is there a known recovery procedure or fix status for this exact error?
This report confirms the same error identifier and message; it does not establish a shared root cause with every report in this issue.