codex - 💡(How to fix) Fix Android Codex mobile loses Android-started active threads after force quit; permissions UI greyed out as Default only

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

This makes Codex mobile unreliable for starting work away from the computer. A user can start a long-running Codex task from Android, accidentally force close or lose the mobile app, and then have no visible way to return to that thread from Android, even though the host is still running it.

It also makes the mobile permission model confusing. The official docs say mobile remote access uses the connected host's projects, threads, permissions, plugins, and local tools, but Android currently appears to expose only a disabled Default permissions state.

Code Example

approvals_reviewer = "guardian_subagent"
RAW_BUFFERClick to expand / collapse

What version of the Codex App are you using?

Codex App: 26.513.20950
Codex CLI: 0.130.0
Host OS: macOS 26.4.1, Darwin 25.4.0 arm64
Mobile client: ChatGPT Android app with Codex mobile preview, latest available as of 2026-05-15 local test time. Exact Android app version is not visible from the host.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS arm64 Mac host connected to ChatGPT Android through Codex mobile remote access.

What issue are you seeing?

I am seeing two related Codex mobile remote-control issues on Android.

1. Android-started in-progress thread disappears from Android after force-quitting ChatGPT

When a Codex thread is started from the Android ChatGPT app, and the assistant turn is still in progress, force-quitting the Android app causes the thread to disappear from the Android Codex UI after reopening the app.

However, the same thread is still visible and resumable on the macOS Codex App host. So the thread is not lost on the host. It appears to be a mobile listing / restore / session-state sync issue.

Important contrast:

  • If the thread is started from the Android ChatGPT app:

    • Start thread on Android.
    • Assistant turn is still running.
    • Force quit Android ChatGPT.
    • Reopen Android ChatGPT.
    • The thread is not visible on Android.
    • The thread is visible on the macOS Codex App host.
  • If the thread is started from the macOS Codex App:

    • Start thread on Mac.
    • Android can see the thread.
    • Force quit Android ChatGPT.
    • Reopen Android ChatGPT.
    • The thread is still visible on Android.

So the problem seems specific to threads initiated from Android mobile while the turn is active.

2. Android mobile permissions UI is greyed out and only shows Default

In the Android ChatGPT Codex UI, the permission selector appears greyed out and only shows Default. I cannot switch to Auto Review / reviewer-backed approvals or Full Access from Android.

On the Mac host, this same setup is configured with reviewer-backed approvals:

approvals_reviewer = "guardian_subagent"

The active thread on the host also shows an interactive approval mode rather than a purely default/no-review state. But Android only exposes a disabled Default permission state, and it is unclear whether this is an intentional limitation, missing UI support, or a state-sync bug.

What steps can reproduce the bug?

Repro A: Android-started active thread disappears on Android

  1. Connect ChatGPT Android app to a running Codex App on macOS.
  2. From Android ChatGPT > Codex, start a new Codex thread on the connected Mac host.
  3. Send a prompt that causes Codex to keep working for a while.
  4. Before the assistant responds or completes the turn, force quit the Android ChatGPT app.
  5. Reopen Android ChatGPT and go back to Codex.
  6. Observe that the Android-started thread is no longer visible on Android.
  7. Open Codex App on macOS.
  8. Observe that the same thread is still visible on the Mac host.

Repro B: Mac-started thread survives Android force quit

  1. Start a new Codex thread from the macOS Codex App.
  2. Open Android ChatGPT > Codex.
  3. Observe that Android can see the Mac-started thread.
  4. Force quit Android ChatGPT.
  5. Reopen Android ChatGPT.
  6. Observe that the Mac-started thread is still visible on Android.

Repro C: Android permissions are greyed out

  1. Open the same connected host from Android ChatGPT > Codex.
  2. Open the permission selector.
  3. Observe that it only shows Default and is disabled/greyed out.
  4. On the Mac host, verify that reviewer-backed approvals / Auto Review style behavior is configured.
  5. Android does not allow switching to Auto Review or Full Access, and does not clearly explain whether the host permission mode is being inherited read-only.

What is the expected behavior?

For Android-started threads:

  • A thread started from Android should remain visible in Android after the app is force-quit and reopened, especially when the thread still exists and is visible on the connected Mac host.
  • Android and macOS should converge on the same thread list for the connected host.
  • If a thread is still running on the host, Android should be able to reattach to it or at least show it as active/recoverable.

For permissions:

  • Android should either:
    • accurately show the effective host permission / approval mode, including reviewer-backed Auto Review-style approval handling, or
    • clearly state that mobile permission changes are not currently supported and that the setting is inherited from the host.
  • If Full Access or Auto Review cannot be changed from mobile by design, the UI should not look like a broken disabled selector without explanation.

What actually happened?

  • Android-started active threads can disappear from Android after force-quitting and reopening the app.
  • The same thread remains available on macOS, so this does not appear to be host-side data loss.
  • Mac-started threads do not have the same Android persistence problem in my test.
  • Android permissions UI only shows a greyed-out Default value, with no way to select Auto Review / reviewer-backed approvals or Full Access.

Why this matters

This makes Codex mobile unreliable for starting work away from the computer. A user can start a long-running Codex task from Android, accidentally force close or lose the mobile app, and then have no visible way to return to that thread from Android, even though the host is still running it.

It also makes the mobile permission model confusing. The official docs say mobile remote access uses the connected host's projects, threads, permissions, plugins, and local tools, but Android currently appears to expose only a disabled Default permissions state.

Related / possibly adjacent issues

This may be related to existing Codex UI/session restore issues where local session data exists but the UI does not show it correctly:

There are also adjacent permissions UI/runtime mismatch issues:

I do not think this is an exact duplicate of those, because this report is specifically about Android Codex mobile remote access and the difference between Android-started vs Mac-started threads.

Additional information

The tested thread was still present on the macOS host after Android lost visibility of it. This suggests the failure is likely in Android mobile thread listing, remote session restoration, or relay-side mobile-origin thread indexing, rather than actual loss of the Codex thread.

I can provide local thread IDs or redacted host logs privately if useful, but I am not posting private local transcripts in the public issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Android Codex mobile loses Android-started active threads after force quit; permissions UI greyed out as Default only