Android Remote cannot open thread while Codex is waiting for a permission approval
Summary
ChatGPT/Codex Remote on Android becomes unable to open a specific Codex thread when that thread is waiting for the user to approve a permission/access request.
Other Remote threads on the same connected host continue to open normally at the same time. The affected thread becomes inaccessible precisely when Remote would be most useful: when Codex needs the user to approve access so work can continue while the user is away from the computer.
This has happened repeatedly, not just with one thread.
Environment
Windows host
- Codex Desktop: 26.818.41509
- Codex Desktop release date: August 21, 2026
- Host OS: Windows 10, version 22H2
Android Remote client
- ChatGPT for Android: 1.2026.223 (20)
- Android: 16
- One UI: 8.5
- Device model code: SM-S928U1
- Android build: BP4A.251205.006.S928U1UES6DZG1
- Android security patch level: July 5, 2026
- Google Play system update: July 1, 2026
The Remote host remains reachable during the failure because other threads on the same host continue to load normally.
The affected thread ID is intentionally omitted from this public report, but can be provided privately if needed for debugging.
Steps to reproduce
- Start or resume a Codex thread on a Remote-enabled Windows desktop host.
- Allow Codex to work normally.
- Confirm from Android that the thread can be opened through Remote.
- Have the thread reach an operation that requires explicit user permission/approval to access something or continue.
- While the desktop thread is sitting at that approval prompt, open the same thread from ChatGPT/Codex Remote on Android.
- Observe that the affected thread fails to load/connect.
- Open other threads on the same Remote host.
- Observe that those other threads still load normally.
This has reproduced repeatedly when a thread is waiting for a permission decision.
Actual behavior
- The specific thread waiting for permission cannot be opened through Remote.
- Other threads on the same host remain connectable.
- Because the affected thread cannot be opened, the user cannot see or respond to the permission prompt remotely.
- Codex remains blocked until the user returns to the desktop or otherwise resolves the prompt locally.
Expected behavior
A thread waiting for a permission/approval decision should remain fully reachable through Remote.
Remote should display the pending approval and allow the user to approve or reject it from the phone, then allow the existing Codex run to continue.
A pending permission request should be a first-class remotely controllable thread state, not a state that makes the thread itself unreachable.
Why this matters
One of the primary reasons to use Remote is not merely to watch Codex work, but to keep long-running work moving while away from the computer.
Permission prompts are exactly the moments when remote interaction is most valuable. If entering an approval state makes that thread inaccessible from Remote, a long-running task can stop indefinitely even though:
- the host is still online,
- Remote itself is still connected,
- other threads remain accessible,
- and only the thread requiring a decision is blocked.
This substantially undermines Remote as a supervision/approval interface for unattended Codex work.
Isolation / useful diagnostic signal
The fact that other threads on the same host continue to load while only the permission-blocked thread fails suggests this is not a general host pairing, network, Android connectivity, or Remote Control outage.
The failure appears tied to the affected thread's pending-approval state or to serialization/reattachment of that state through Remote.
A useful regression test would be:
- Create two remotely visible threads on one host.
- Leave thread A idle or completed.
- Put thread B into a pending permission/approval state.
- Attach to both from Android Remote.
- Assert that both threads load and that thread B exposes an actionable approval UI.
- Approve from Android and assert that thread B continues execution on the host.
Related issues
- #37967 — broader Remote attach failure for live/in-progress sessions.
- #22800 — Android Remote thread/session persistence and permissions UI issues.
This report is narrower: the repeatedly observed trigger is a pending permission/approval prompt, while other threads on the same host remain connectable.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This is not the same failure as #39346. In #39346, Mobile successfully opens the task and shows an “approval waiting” state but lacks actionable controls. Here, the affected thread cannot establish/load the Remote session at all while it is waiting for approval, so the user never reaches the approval UI. Other threads on the same host still open normally.
Hey, I ran a couple quick A/B tests to rule out something on my device.
Both times I force-stopped ChatGPT, cleared logcat, opened a Remote thread that works, waited until it fully loaded, then immediately switched to the affected thread. The working thread connected normally; the affected one just spun even though the Remote service stayed active, networking/DNS remained healthy, and ChatGPT didn’t crash.
One interesting thing: this error only showed up after switching to the failing thread:
Invalid icon type in shortcut codex-remote-avatar. Bitmaps are not allowed in long-lived shortcuts.Not saying that error is necessarily the cause, but it was repeatable and only appeared with the failing thread.
Also, the permission request that originally triggered this has long since been granted and the thread has continued executing additional work, but Remote still cannot open that thread.