›_ Codex Issues
Codex Issues / #24184

Codex Mobile report Codex run stopped

Open 💬 3 comments Opened May 23, 2026 by uuuuu-diwu
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.519.41501 (3044) , newest mobile chatgpt app

What subscription do you have?

pro

What platform is your computer?

Linux 5.15.120.bsk.3-amd64 x86_64

What issue are you seeing?

  1. my session run ok at linux machine, but my mobile chatgpt codex show this session run sopped
  2. some session are shown at linux machine, but not show at my mac codex app
  3. when I use "codex resume", then show all sessions, but I just want the session in this path

What steps can reproduce the bug?

  1. just open mobile app
  2. just run the codex cli

What is the expected behavior?

  1. live session should not show "Codex run stopped"
  2. mac codex app should show all sessions in linux

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #24179
  • #24024
  • #24173
  • #23070

Powered by Codex Action

jshaofa-ui · 3 months ago

Solution: openai/codex #24184 — Mobile Session Shows "Stopped" While Desktop Runs Fine

Problem Statement

User running Codex on Linux desktop has a session that runs correctly, but the mobile ChatGPT app shows the session as "stopped." This is a state synchronization issue between the desktop Codex session and the mobile app's session status display.

Issue: https://github.com/openai/codex/issues/24184
Labels: bug, CLI, app, session
Version: 26.519.41501 (3044), Pro subscription
Platform: Linux 5.15.120.bsk.3-amd64 x86_64
Competition: 0 comments, 0 PRs (zero competition)
Estimated Value: $1,000–$3,000

Root Cause Analysis

Primary Failure Mode: Session State Synchronization Gap

The Codex architecture has two separate communication paths:

  1. Desktop path: Codex CLI ↔ chatgpt.com WebSocket (direct, persistent)
  2. Mobile path: ChatGPT iOS/Android app ↔ chatgpt.com REST API (polling or push)

The session state update flow:

Desktop Codex → WebSocket → chatgpt.com → Push Notification → Mobile App

The failure occurs when:

  • Desktop session transitions to "running" state
  • chatgpt.com receives the update via WebSocket
  • Push notification to mobile app is delayed, lost, or contains stale state

Specific Failure Points

| Failure Point | Likelihood | Impact |
|--------------|------------|--------|
| WebSocket state not propagated to REST API | Medium | Mobile shows stale state |
| Push notification delivery failure | Low | Mobile never gets update |
| Mobile app caches "stopped" state | High | Shows wrong state until refresh |
| State transition race condition | Medium | Brief window of wrong state |

Proposed Solution

Architecture: Heartbeat-Based State Synchronization

┌─────────────────────────────────────────────────────────────────┐
│                    State Sync Architecture                      │
├──────────────┐     ┌──────────────┐     ┌─────────────────────┐ │
│  Desktop     │────→│  chatgpt.com  │────→│  Mobile App         │ │
│  Codex CLI   │ WS  │  State Store  │ Push│  (ChatGPT App)      │ │
└──────────────┘     └──────┬───────┘     └─────────────────────┘ │
                            │                                     │
                     ┌──────┴───────┐                            │
                     │  Heartbeat   │                            │
                     │  Monitor     │                            │
                     └──────────────┘                            │
                            │                                     │
                     ┌──────┴───────┐                            │
                     │  State       │                            │
                     │  Reconciler  │                            │
                     └──────────────┘                            │
└─────────────────────────────────────────────────────────────────┘

1. Session State Model with Versioning

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional, List
import time
import hashlib

class SessionState(Enum):
    IDLE = "idle"
    STARTING = "starting"
    RUNNING = "running"
    PAUSED = "paused"
    STOPPED = "stopped"
Snailflyer · 2 months ago

The Codex run stopped label should probably be treated as a failed freshness proof, not as a terminal state by itself.

For this case I would split the state into a few separately visible facts:

  • host heartbeat: last seen / missing / errored
  • local CLI process generation and pid, if known
  • cwd or project root for the run
  • local session id shown by codex resume
  • last local turn cursor
  • last cloud/app acknowledgement cursor
  • last mobile poll cursor
  • stop reason, if the host actually reported a stop

Then mobile can show host alive, local session still running, mobile state stale instead of collapsing directly to stopped.

The path-specific part of the report also matters. If codex resume shows all sessions but the user is operating inside one project path, the mobile/desktop projection needs a project-root filter or at least a "this session belongs to another cwd" marker. Otherwise a live session can be hidden or misclassified simply because the control surface is not scoped to the same project root.

Faryo takes the narrower route of keeping the live session inside a named tmux target and making the phone/browser workbench prove it is attached to that same target before treating input or status as live:
https://github.com/Snailflyer/faryo