Remote/mobile attach unusable with large session stores: thread/list full-scans rollouts, attach re-resumes entire thread, no pagination or device cache

Summary

With a large local session store (~5,300 rollout files, long-lived threads by design), remote/mobile attach to Codex desktop is effectively unusable: the phone shows "Connecting…" forever and eventually "Failed to connect to ChatGPT desktop", while the desktop is healthy and reachable.

Environment

• Windows 11 Pro (26200), Codex desktop MSIX 26.820.7780.0, bundled codex-cli 0.150.0-alpha.8
• Android ChatGPT app 1.2026.230
• ~/.codex/sessions: ~5,300 rollout .jsonl files; individual threads range up to 146k rollout items (long-running threads are intentional in this workflow)

What we measured

1. Remote thread/list scans every rollout file instead of using the state db. Driving codex app-server directly over stdio, thread/list took 21–40 s to return a 2-thread, 2,383-byte response, warm or cold cache, idle or busy. After reducing the scan tree from 5,297 to 915 files (moving old months out), it returns fast. The local desktop UI path logs state db list_threads and answers in <1 s. The mobile client times out at ~30 s and retries on a new connection forever — each retry re-runs the full scan.

1. Every mobile attach triggers a full fresh thread resume. Logs show back-to-back Resumed rollout with 12,752 / 12,764 items, parse errors: 0 — ~37 s each under load — even when the same thread is already resumed and live in the desktop app. There appears to be no warm-session attach, so on any sizable thread the mobile timeout always wins.

1. The mobile app refetches sessions/threads on every app open — no on-device cache, so every reconnect pays the full cost again.

Requested fixes / design suggestions

• Serve remote thread/list from the state db (as the local path does), or paginate it; never full-scan the rollout store per request.
• Paginate thread history for mobile clients rather than shipping/resuming entire threads.
• Attach remote clients to already-warm sessions instead of spawning a fresh full resume per attempt.
• Cache thread state on the device and have the phone submit only new user input; keep the harness-side thread as the sole source of truth. This avoids the tampering concern with client-held history while eliminating the refetch latency.