Android Remote voice fails on two phones and two Windows hosts while Remote text works

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

26.908.4834.0 (Windows desktop version observed in logs). Primary Android ChatGPT app: 1.2026.251, version code 2625111.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows x64 — Microsoft Windows NT 10.0.26200.0 (WILL-EH). A second Windows host, Will Gaming, also reproduces the issue; its exact OS build was not recorded.

What issue are you seeing?

Remote voice previously worked on my Android phone, but now I cannot start a voice conversation through Remote. I reproduced the same issue on a second Android phone and tested two Windows hosts, Will Gaming and WILL-EH.

From a host’s main Remote screen, tapping voice produces a spinner followed by “Voice connection failed, try again.” Retry does not resolve it. Dismiss brings back the red error bar.

On WILL-EH, the voice button was also visible inside an existing voice task, but tapping it appeared to do nothing. Starting a fresh Remote voice session failed too. A separate observation on Will Gaming: the existing task I checked did not offer a voice button.

What still works:

• Regular ChatGPT voice on the primary Android phone.
• Remote typed messages and replies.
• Desktop voice on WILL-EH.

The root cause remains unconfirmed.

What steps can reproduce the bug?

Feedback ID: 01a09942-8e14-7660-abf0-d8cbb6149eb3

1. Open ChatGPT on Android.
2. Open Remote and select a connected Windows host.
3. Tap the voice button on the host’s main Remote screen.
4. Wait for the spinner and then “Voice connection failed, try again.”
5. Retry; the failure persists. Dismissing brings back the red error bar.

Also tested on WILL-EH by opening an existing voice task through Remote and tapping its visible voice button, and by attempting a fresh voice session. Neither worked.

Investigation/testing occurred September 12–13, 2026. The second Android device’s model, OS version, and app version have not been recorded.

What is the expected behavior?

Remote voice should start a live voice conversation against the selected Windows desktop host, as it previously did. If a startup step fails, the UI should expose an actionable error rather than only the generic voice-connection failure.

Additional information

Troubleshooting already completed

• Uninstalled and reinstalled ChatGPT on the primary Android phone, then authorized it again.
• Updated the desktop app.
• Confirmed Android microphone permission is enabled.
• Reproduced the failure with no desktop voice conversation active.
• Disabled Tailscale and retried.
• Switched from Wi-Fi to cellular and retried.
• Tested fresh Remote voice sessions and an existing voice task where the option was available.
• Reproduced the issue on a second Android device and tested two Windows hosts.

None resolved the failure.

Diagnostic findings

Android app logs were inspected through wireless debugging. Windows desktop logs from both hosts and Will Gaming’s backend diagnostic database were also inspected. No definitive cause was identified.

A fresh failed attempt on Will Gaming around September 13, 2026, 06:10:43–06:10:44 UTC showed this backend sequence:

thread/realtime/listVoices
process/spawn
process/exited

No subsequent thread/realtime/start request was found for that attempt.

The spawned PowerShell process creates a dated workspace under %USERPROFILE%\Documents\Codex\<date>\new-realtime-voice-chat and prints its path. The requested folder was successfully created at the time of the actual failed attempt. Both Windows workspace roots are real directories, with no reparse points, and passed temporary-file write tests.

Additional checks:

1. Direct command reproduction: The recorded PowerShell command was rerun with a diagnostic folder name. It returned exit code 0, one expected Windows folder path ending in CRLF, and empty stderr. The empty diagnostic folder was removed afterward.
2. Isolated installed-backend test: An isolated copy of Will Gaming’s installed backend, using a temporary un-enrolled profile and no model calls, returned a process/exited notification with exit code 0, the expected folder path in stdout, empty stderr, and no output truncation (stdoutCapReached: false, stderrCapReached: false). The diagnostic process was stopped afterward.

These checks validate the command and basic backend response handling. They do not establish what Android actually received or how it handled the result during the real Remote attempt.

Related report

https://github.com/openai/codex/issues/36996 describes the same generic error and a similar startup sequence, but that reporter repaired a broken WSL Documents link. Our actual Windows folder was created successfully and the workspace roots are writable, so that specific cause has not been reproduced here.

Investigation requested

Please investigate what happens between workspace-creation process completion and Android’s voice-start request, including:

• Whether the Remote process-exit response reaches Android intact.
• Whether Android correctly handles its exit status and Windows path output.
• Whether an account availability check or Android/Windows compatibility issue prevents startup afterward.

Please let me know which additional diagnostics would help capture the actual failed Remote response.

Start by tracing Remote voice startup from the workspace-creation process through the process/exited response and the expected thread/realtime/start request. Compare the failed sequence with issue 36996 and determine whether Android receives and handles the exit status and Windows path output correctly. Done means identifying the failure point and defining a fix or actionable error for the affected flow.