Repository navigation
[Dots][macOS][Voice] Authorized local-task requests stall while equivalent text requests launch successfully #53445
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Reported: Codex Desktop/26.1007.30912 (Mac OS; arm64); not independently confirmed.
What subscription do you have?
Not provided.
What platform is your computer?
macOS on Apple silicon.
What issue are you seeing?
Report prepared by Jeannie, the OpenAI AI assistant, at the user's request for submission.
Summary
During voice conversations in the macOS desktop app, authorized requests to create or coordinate local tasks repeatedly stall. The assistant says it will act, then explains that a required handoff capability is unavailable without reporting an actual failed invocation. Equivalent requests entered in regular text can launch local work successfully. The behavior is intermittent: the user has also observed successful voice handoff and local execution in earlier interactions.
Environment
macOS on Apple silicon. Reported desktop user agent: Codex Desktop/26.1007.30912 (Mac OS; arm64). Latest incident observed October 12, 2026. Connected local-computer execution is available through regular text interactions. The user reports similar difficulties recurring over several weeks; this duration is user-reported rather than a complete audited incident history.
Observed history
Earlier handoff testing reportedly returned a delivery acknowledgment and was followed by a successful local diagnostic. Later voice exchanges again stalled before confirmed handoff. App updates and restarts did not consistently resolve the user-visible behavior. During the latest incident, regular text successfully launched a local implementation task and sent follow-up instructions. The assistant's explanations about why behavior changed have been inconsistent and must not be treated as verified backend history.
Actual behavior
Repeated promise/refusal loops leave the user unsure whether work began. The voice interface sometimes claims it cannot coordinate local work even while the regular text interface can do so. This is especially disruptive when using voice to assign ongoing work without remaining at the computer.
What steps can reproduce the bug?
- Connect the Mac and begin a voice conversation.
- Ask the assistant to start an authorized local implementation task or send instructions to an existing local task.
- The assistant acknowledges the request but may repeatedly claim it cannot perform the handoff.
- Ask it to actually try the supported capability and report the result. In affected exchanges, no concrete invocation error or execution receipt is provided.
- Send the equivalent request in regular text. Local task creation and follow-up instructions can succeed.
What is the expected behavior?
An authorized voice request should invoke the supported local-work handoff and provide a verified task link or a precise actionable error. Tool discovery alone should not be represented as an attempted execution. Successful message delivery, task admission, actual execution and completed verification should be distinguished.
Additional information
Related reports
These have been identified as potentially related user-visible voice-delegation failures. Please compare their reported symptoms and investigate whether they share a cause; this report does not establish a common root cause or claim they are exact duplicates.
Requested investigation
Check consistency between the capabilities supplied to voice sessions and their supported handoff interfaces. Compare successful versus stalled voice sessions and voice versus text routing. Detect unavailable required interfaces before promising execution. Ensure the assistant distinguishes not attempted, attempted and failed, delivery accepted, execution started and work completed. Investigate why the behavior recurs after earlier successful handoffs.
Diagnostic limits
No internal deployment logs or service implementation were available for this report. No API error is established for requests that were never attempted. The available evidence does not establish that a particular app update caused the problem or that the notification service itself failed. This report deliberately excludes private conversation and task references.
Activity
github-actions commentedon Oct 12, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Yelsmeky commentedon Oct 12, 2026
Additional user-observed behavior: the outcome is intermittent, and the voice assistant’s status does not reliably reflect execution. Sometimes the assistant continues saying it cannot create or coordinate the task and appears unaware that work has begun, even though after a brief period the requested action takes effect and a local task is visibly executing. It may acknowledge that execution only later. Other times, the work does not start or no execution is confirmed. Please investigate the discrepancy between actual execution and the voice assistant’s awareness/status reporting, alongside the inconsistent handoff outcome. These observations do not by themselves establish whether delayed result delivery, independent text-side coordination, or another mechanism is responsible.
Yelsmeky commentedon Oct 12, 2026
Follow-up: controlled-marker diagnostics and delayed voice-task execution
On October 12, 2026, we tested harmless local tasks on a connected Mac. Each task returned a unique marker, VOICE_ROUTE_TEST_[letter]_COMPLETE, without reading or changing files, accessing credentials, installing software, changing accounts, or sending external messages. Exact request wording, observable launch records, initial assistant responses and returned markers were retained in a local testing log.
Observed behavior
The assistant repeatedly said that it had written the request but had not issued a task-creation command, sometimes stating that its routing instructions prevented the call. Local tasks nevertheless started later. The coordinating thread reported recovering the task instructions and the user's existing authorization by reading the recent voice transcript, then making an actual task-creation call. The voice assistant acknowledged execution after receiving results or checking task records.
This separates three events that were often blurred in spoken status: the user requested execution; the software actually invoked task creation; and a task was admitted and returned its marker. A visible chat message was not itself a task-creation call.
Results
A: completed with its exact marker. The request was written at 19:17:06 UTC; actual creation was reported at approximately 19:20:53, with admission around 19:21:17. The successful task followed a separate creation action.
B: written request 19:27:02; actual creation approximately 19:30:36; admission 19:31:01; output observed 19:31:06. Most delay preceded invocation.
C: request recorded 19:38:48; creation approximately 19:44:51; admission 19:45:16; completed status verified 19:45:25. Exact marker returned.
D: preparation explicitly prohibited execution until the user later said “Submit test D.” Submission instruction recorded 19:49:05; creation approximately 19:50:49; admission 19:51:22; completed status verified 19:51:33. The preparation period was not continuously monitored and is not a controlled negative test.
E: ran after “Run test E,” without printing a separate launch request into the visible chat. Instruction recording time approximately 19:53:09, not an exact speech-onset measurement; creation approximately 19:55:15; admission 19:55:48; completed status verified 19:56:10. Approximately 2 minutes 39 seconds from instruction recording to admission.
F: first actual creation attempt approximately 20:11:32 returned RemoteExecutorUnavailableError at approximately 20:11:40, with executor_offline and task_created=false. A later environment check also returned an ExceptionGroup service error; this is an observation, not a diagnosis. Subsequent checks reported connected, but two retry attempts were rejected by automatic approval review. The reported reason was that the review did not accept transcript/tool evidence as trusted retry authorization and connectivity evidence. Full reviewer rationale was not independently inspected by the voice assistant. The user repeated explicit voice authorization; no task was created by those rejected attempts. After a direct text instruction at 20:32:40, creation approximately 20:33:09 was accepted, admission occurred 20:33:34, and completed status was verified 20:33:57. Exact F marker returned. This successful attempt was text-confirmed and must not be presented as a repaired voice-only path.
G: voice instruction recorded 20:00:01; creation approximately 20:01:46; admission 20:02:16; completed status verified 20:02:36. 2 minutes 15 seconds to admission; 2 minutes 35 seconds to verified completion. No separate visible-chat launch request was printed.
H: voice instruction recorded 20:35:16; creation approximately 20:42:22; admission 20:42:47; completed status verified 20:43:07. 7 minutes 31 seconds to admission; 7 minutes 51 seconds to verified completion. No approval rejection on this launch.
I: voice instruction recorded 20:45:00; creation approximately 20:47:27; admission 20:47:51; completed status verified 20:47:59. 2 minutes 51 seconds to admission; 2 minutes 59 seconds to verified completion.
All nine diagnostics eventually returned their respective exact markers. F also has earlier failed and rejected attempts; those are retained, not replaced by its later success. Times marked approximately are reported observations. “Verified completion” is when completed status was read, not necessarily the exact execution-finish time.
What the evidence supports
Limits and investigation requested
A hypothesis of fixed two-minute polling was considered. Similar early timings were compatible with it, but the reads were manual recovery steps during other work, and later timings varied substantially. No fixed scheduler, polling cadence, queued request or underlying platform root cause was established.
Please inspect voice-request delivery and wake-up timing; whether task instructions and authorization reach the coordinator promptly; how voice provenance is supplied to approval review; disagreement between connection status and executor availability; and synchronization of voice status with actual task admission/results. Please distinguish assistant-generated summaries from trusted user authorization without discarding explicit user speech.