Summary
I want to describe a broader workflow failure in Android Codex Remote, not just one isolated bug.
My main workflow is using ChatGPT on Android to control Codex tasks running on my computer. This is especially important when I am away from the desktop: I can dictate a long technical prompt, send it to the active Codex thread, monitor the task, and later return to the result.
Right now, this workflow breaks in several connected places.
1. Voice Assistant could be a great feature, but it currently opens without the current Codex thread context
The idea of Voice Assistant is good. It would be very useful to open voice mode directly from an active Codex thread, talk through the task, clarify details, and then send the result back into that same work thread.
But right now, when Voice Assistant is opened from a Codex chat, it behaves like a separate chat. It does not seem to know the current Codex thread: what project this is, what task is running, what has already been done, what context exists in the conversation, which model is selected, or where the result should be sent.
As a result, instead of useful voice control for the current Codex task, it becomes a separate voice intermediary with no working context. That breaks the workflow.
Expected behavior:
- If Voice Assistant is opened from a Codex thread, it should know the context of that thread.
- It should understand the current task and conversation history.
- It should help formulate a prompt or command for that same Codex thread.
- The user should be able to review the generated text and send it back into the same active thread.
- Normal direct dictation into the input box should also remain available.
Related issue: #36536.
2. Typed input can periodically degrade, and current dictated text can be lost after connection problems
Normal ChatGPT chats on Android handle temporary connection loss better: drafts are usually preserved and there is a clearer retry/reconnect path.
In Codex Remote, temporary network problems can affect the current input flow. Sometimes the keyboard input degrades: fast typing becomes unreliable, characters can be replaced incorrectly, and the cursor can jump around. When this happens, the only usable workaround is to type extremely slowly, roughly one character at a time.
This keyboard/input degradation is intermittent. It may already be fixed in some builds, or it may still occur under certain conditions, but it has happened often enough to be part of the Android Remote reliability problem.
A connection interruption can also cause the current dictated text or long voice prompt to be lost if it has not been sent yet. The existing chat history may remain intact, but the current voice input work is gone.
Sometimes reconnecting or restarting the app may be needed before input starts working correctly again, because Remote does not always recover cleanly by itself after an internet interruption.
This is critical for mobile usage because weak signal, network switching, elevators, and app background/foreground transitions are normal phone conditions.
Related issue: #36537.
3. Old Codex chats no longer open on Android
Old or long-inactive Codex chats used to open slowly on Android, but they eventually opened. Now they can stay loading indefinitely and never become usable.
This breaks access to task history. When I am away from the computer and trying to work from my phone, I cannot simply open the needed Codex thread. I cannot check what is happening with the task, understand the current status, or correct Codex while it is working.
The result is that I am tied back to the desktop again. If I am away from the computer, I can no longer reliably supervise or unblock running Codex tasks from Android.
Related issue: #37126.
4. The user needs to understand which model is actually working
I intentionally select 5.5 High because, for my real Codex tasks, it used to be faster, more reliable, and better at finishing work.
5.6 Sol / 5.6 Sol Max may be newer or more powerful on paper, but in my workflow it often behaves worse: it works longer, goes in circles, follows instructions less reliably, and can spend many hours without completing the task.
This changed noticeably around August 5-6, 2026. Before that, selected 5.5 High behaved like the model I intentionally chose: faster, more direct, and better at finishing Codex tasks. Around August 5-6, the same selected 5.5 High started to feel like a different model, similar to 5.6 Sol Max: slower, more circular, and much less reliable at completing tasks.
I am not claiming I can prove a model substitution. But if a user selects a specific model, the interface should clearly show which model is actually performing the work.
If the system changes the model or work mode for any reason, that should be understandable to the user.
Related issues: #36538, #37170.
Overall problem
All of these bugs together break Android Codex Remote as a working tool.
A user can:
- open Voice Assistant from a work chat but get a separate voice chat that does not know the current task;
- see keyboard input degrade so badly that fast typing becomes unreliable;
- dictate a long prompt and lose the current unsent voice text;
- fail to recover input cleanly after a connection interruption;
- fail to open an old work thread from Android;
- be forced back to the desktop to supervise or unblock Codex work;
- not understand which model is actually executing the task.
These are not small isolated inconveniences. Together, they form one Android Codex Remote reliability problem.
Expected behavior
- If Voice Assistant is opened from a Codex thread, it should know the context of that thread.
- Voice Assistant should help with the current Codex task, not open a separate empty context.
- After a voice discussion, the user should be able to send the result back into the same active Codex thread.
- Direct microphone dictation into the input box of the current Codex thread should also remain available.
- Keyboard input should remain stable and support normal typing speed, without cursor jumps or incorrect character replacement.
- Typed and recognized voice text should be preserved locally until it is successfully sent.
- Temporary connection loss should not destroy the current input or dictated text.
- There should be a clear reconnect/retry path without requiring a full app restart.
- Old/inactive Codex chats should open on Android, or show a clear recoverable retry/error state.
- The interface should clearly show which model is actually working in the current Codex thread.
- If the system changes the model or work mode, that should be visible to the user.
I am willing to help reproduce this
I suspect this workflow may be under-tested: Android phone + Windows desktop + Codex Remote + long-running tasks + voice dictation + unstable mobile network.
Maybe this works better on macOS/iPhone. But on Android + Windows, the workflow is currently breaking in multiple places.
I am not filing this only to complain. I am willing to help the team reproduce the problem and verify fixes.
I can provide:
- Android app and Codex Desktop versions;
- Windows environment details;
- redacted thread/session IDs;
- screen recordings;
- redacted logs;
- step-by-step reproductions;
- testing on future builds or candidate fixes.
I want Android Codex Remote to become a reliable work tool. Right now it too often loses state, context, or user trust.
If you can reproduce this
If you are also seeing this Android Codex Remote workflow break, please consider adding a 👍 reaction to this issue and leaving a short comment with:
- Android app version;
- Android device / OS version;
- Codex Desktop version;
- host OS, especially Windows vs macOS;
- which part you can reproduce: Voice Assistant context, dictation, keyboard/input degradation, reconnect, old chats not opening, or model identity;
- whether the issue is intermittent or consistent.
Concrete reproduction details are more useful than “same here” comments.
Summary
I want to describe a broader workflow failure in Android Codex Remote, not just one isolated bug.
My main workflow is using ChatGPT on Android to control Codex tasks running on my computer. This is especially important when I am away from the desktop: I can dictate a long technical prompt, send it to the active Codex thread, monitor the task, and later return to the result.
Right now, this workflow breaks in several connected places.
1. Voice Assistant could be a great feature, but it currently opens without the current Codex thread context
The idea of Voice Assistant is good. It would be very useful to open voice mode directly from an active Codex thread, talk through the task, clarify details, and then send the result back into that same work thread.
But right now, when Voice Assistant is opened from a Codex chat, it behaves like a separate chat. It does not seem to know the current Codex thread: what project this is, what task is running, what has already been done, what context exists in the conversation, which model is selected, or where the result should be sent.
As a result, instead of useful voice control for the current Codex task, it becomes a separate voice intermediary with no working context. That breaks the workflow.
Expected behavior:
Related issue: #36536.
2. Typed input can periodically degrade, and current dictated text can be lost after connection problems
Normal ChatGPT chats on Android handle temporary connection loss better: drafts are usually preserved and there is a clearer retry/reconnect path.
In Codex Remote, temporary network problems can affect the current input flow. Sometimes the keyboard input degrades: fast typing becomes unreliable, characters can be replaced incorrectly, and the cursor can jump around. When this happens, the only usable workaround is to type extremely slowly, roughly one character at a time.
This keyboard/input degradation is intermittent. It may already be fixed in some builds, or it may still occur under certain conditions, but it has happened often enough to be part of the Android Remote reliability problem.
A connection interruption can also cause the current dictated text or long voice prompt to be lost if it has not been sent yet. The existing chat history may remain intact, but the current voice input work is gone.
Sometimes reconnecting or restarting the app may be needed before input starts working correctly again, because Remote does not always recover cleanly by itself after an internet interruption.
This is critical for mobile usage because weak signal, network switching, elevators, and app background/foreground transitions are normal phone conditions.
Related issue: #36537.
3. Old Codex chats no longer open on Android
Old or long-inactive Codex chats used to open slowly on Android, but they eventually opened. Now they can stay loading indefinitely and never become usable.
This breaks access to task history. When I am away from the computer and trying to work from my phone, I cannot simply open the needed Codex thread. I cannot check what is happening with the task, understand the current status, or correct Codex while it is working.
The result is that I am tied back to the desktop again. If I am away from the computer, I can no longer reliably supervise or unblock running Codex tasks from Android.
Related issue: #37126.
4. The user needs to understand which model is actually working
I intentionally select 5.5 High because, for my real Codex tasks, it used to be faster, more reliable, and better at finishing work.
5.6 Sol / 5.6 Sol Max may be newer or more powerful on paper, but in my workflow it often behaves worse: it works longer, goes in circles, follows instructions less reliably, and can spend many hours without completing the task.
This changed noticeably around August 5-6, 2026. Before that, selected 5.5 High behaved like the model I intentionally chose: faster, more direct, and better at finishing Codex tasks. Around August 5-6, the same selected 5.5 High started to feel like a different model, similar to 5.6 Sol Max: slower, more circular, and much less reliable at completing tasks.
I am not claiming I can prove a model substitution. But if a user selects a specific model, the interface should clearly show which model is actually performing the work.
If the system changes the model or work mode for any reason, that should be understandable to the user.
Related issues: #36538, #37170.
Overall problem
All of these bugs together break Android Codex Remote as a working tool.
A user can:
These are not small isolated inconveniences. Together, they form one Android Codex Remote reliability problem.
Expected behavior
I am willing to help reproduce this
I suspect this workflow may be under-tested: Android phone + Windows desktop + Codex Remote + long-running tasks + voice dictation + unstable mobile network.
Maybe this works better on macOS/iPhone. But on Android + Windows, the workflow is currently breaking in multiple places.
I am not filing this only to complain. I am willing to help the team reproduce the problem and verify fixes.
I can provide:
I want Android Codex Remote to become a reliable work tool. Right now it too often loses state, context, or user trust.
If you can reproduce this
If you are also seeing this Android Codex Remote workflow break, please consider adding a 👍 reaction to this issue and leaving a short comment with:
Concrete reproduction details are more useful than “same here” comments.