›_ Codex Issues
Codex Issues / #22800

Android Codex mobile loses Android-started active threads after force quit; permissions UI greyed out as Default only

Open 💬 6 comments Opened May 15, 2026 by gydx6

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.

View original on GitHub ↗

6 Comments

STSNaive · 2 months ago

Additional repro data point: in the same Codex conversation connected to the same Mac host, a message sent from the desktop ran with sandbox_mode=danger-full-access / network enabled, but a message sent from ChatGPT Android mobile in the same thread ran with sandbox_mode=workspace-write / network restricted. The Android UI showed greyed-out Default permissions. This suggests the mobile path is not just displaying an unclear label; it may be starting turns with a different permission envelope than the desktop/host.

shiftybitshiftr · 2 months ago

+1 to both issues. I was able to reproduce this as well.

On my Mac laptop, the conversation has Full Access enabled. However, when I open the same thread in the Android app, it falls back to Default access and requires approvals again, even though the thread was originally started with Full Access on desktop.

I also ran into the thread disappearing issue while on an airplane with unstable Wi-Fi. I tried force-stopping the app, clearing the cache, logging out and back in, and then reconnecting later on stable internet, but the thread still never reappeared.

Interestingly, I was able to ask the assistant about other conversations in the same project directory, and it seemed able to look up those chat transcripts and resume the work from there. So the underlying project context may still have been accessible, but the specific thread was no longer visible in the app.

One other data point: after force-stopping the Android app, all of my queued prompts appeared to be lost as well.

P.S. This feature is amazing and I've been looking forward to it for ages!

hekunwang · 2 months ago

Same here on Android Remote Control.

On my setup, the Android permission selector is disabled / greyed out and only shows Default. I cannot change it from the mobile UI to another permission mode such as Full Access / Auto Review.

Environment where I saw this:

  • Host: macOS Codex Desktop 26.513.20950
  • Bundled CLI: codex-cli 0.131.0-alpha.9
  • Client: ChatGPT Android Codex Remote Control

This is alongside the mobile remote conversation-list issue I reported separately in #22762: Android can create/start remote conversations, but the mobile UI does not maintain a stable list of those conversations across switching/reconnects.

marcoshernanz · 1 month ago

Any updates?

JonSpeare · 1 month ago

Same issue. I'm noting that both Android and iOS both start with the same set of old sessions after I force quit the application on both devices. Flow like so.

  1. Open ChatGPT and navigate to Codex.
  2. See same snapshot of old sessions from one week ago or something like that.
  3. Both Android and iOS app start loading, probably trying to synchronize against the desktop application.

Then the behavior diverges:
The iOS app spends a while doing it, then correctly pulls in all the active sessions from the desktop, while the Android app shows a quick loading spinner before stopping and not receiving anything new.

Note. I tried uninstalling and reinstalling the Android app, revoking all Android entries on desktop, and reinitializing through the QR flow from the desktop app, and removed all data/cache on Android. No effect.

<img width="2024" height="2168" alt="Image" src="https://github.com/user-attachments/assets/c15c8656-6484-45ac-9f78-b25f4505c1b9" />

m13v · 1 month ago

the part that bites here isn't mobile sync, it's that the thread list gets reconstructed from client-side events instead of read back from the host's session store. force-quit mid-turn and the Android client never persisted its own record, so on reopen it has nothing to show, while the Mac host still owns the session because that's where the ACP connection lives. mac-started threads survive because the host wrote them first. the fix that holds is making the client's list a projection of host session state on reconnect, not an independent log you can lose.