Replacement for #36928, which was accidentally opened through the wrong connected GitHub account. I am the original reporter.
What version of the Codex App are you using?
- ChatGPT iOS app: latest App Store version available on August 4, 2026 (exact build not shown)
- Codex host app:
26.721.81911 (build 5973)
What subscription do you have?
Not supplied.
What platform is your computer?
- Mobile client: iPhone running iOS
26.5.2
- Remote host: macOS
26.5, Apple Silicon
- Surface: ChatGPT iOS Codex remote control connected to a local Mac host
What issue are you seeing?
In the ChatGPT iOS Codex remote-control view, the composer accepts text but the Send arrow remains disabled. The thread appears idle: an assistant response is complete, no active turn or approval is visible, and the composer contains non-whitespace text.
Starting a new thread does not clear the condition. The disabled Send state reappears there as well. The UI gives no explanation for why submission is blocked.
The only recovery observed was force-quitting the ChatGPT iOS app and reopening it. I had to force-quit the app before I could submit this bug report.
This has happened repeatedly.
What steps can reproduce the bug?
- Open the latest ChatGPT iOS app.
- Connect to a local Mac through the Codex remote-control view.
- Open an existing Codex thread after the assistant has completed its response.
- Enter any non-empty text in the composer.
- Observe that the Send arrow remains greyed out and cannot be tapped.
- Start a new thread.
- Enter text in the new thread.
- Observe that the same disabled Send state reappears.
- Force-quit and reopen ChatGPT iOS.
- Observe that submission works again.
What is the expected behavior?
When an idle thread's composer contains text, Send should be enabled.
If submission is intentionally blocked because of connection, host, turn, model, or thread state, the UI should explain the blocking condition and provide a recovery action.
What is the actual behavior?
The composer accepts text, but Send remains disabled without explanation. Creating a new thread does not recover it. Force-quitting the iOS app is required.
Frequency and impact
Recurring. It blocks all prompt submission from the mobile remote-control surface until the entire ChatGPT app is force-quit.
Screenshots
Two screenshots are available:
- The affected Codex remote thread, showing non-empty composer text and a disabled Send arrow.
- The device's iOS version screen showing iOS 26.5.2.
I will attach both screenshots in GitHub.
What version of the Codex App are you using?
26.721.81911(build5973)What subscription do you have?
Not supplied.
What platform is your computer?
26.5.226.5, Apple SiliconWhat issue are you seeing?
In the ChatGPT iOS Codex remote-control view, the composer accepts text but the Send arrow remains disabled. The thread appears idle: an assistant response is complete, no active turn or approval is visible, and the composer contains non-whitespace text.
Starting a new thread does not clear the condition. The disabled Send state reappears there as well. The UI gives no explanation for why submission is blocked.
The only recovery observed was force-quitting the ChatGPT iOS app and reopening it. I had to force-quit the app before I could submit this bug report.
This has happened repeatedly.
What steps can reproduce the bug?
What is the expected behavior?
When an idle thread's composer contains text, Send should be enabled.
If submission is intentionally blocked because of connection, host, turn, model, or thread state, the UI should explain the blocking condition and provide a recovery action.
What is the actual behavior?
The composer accepts text, but Send remains disabled without explanation. Creating a new thread does not recover it. Force-quitting the iOS app is required.
Frequency and impact
Recurring. It blocks all prompt submission from the mobile remote-control surface until the entire ChatGPT app is force-quit.
Screenshots
Two screenshots are available:
I will attach both screenshots in GitHub.