›_ Codex Issues
Codex Issues / #38787

thread/resume is effectively quadratic on large active threads, blocking Remote steering

Open 💬 5 comments Opened Aug 15, 2026 by Luzivog

Summary

Opening or steering a very large active Codex thread from iOS Remote can time out even though pairing, authentication, transport, and the host app-server are healthy.

The same failure occurs through a client that sends a follow-up to an existing thread: the client first performs thread/resume, app-server parses the rollout successfully, then remains CPU-bound while composing the resume response. The follow-up is never submitted.

For the affected thread, using the already-loaded Codex Desktop composer bypassed thread/resume and delivered the steer immediately.

Environment

  • Codex CLI / app-server: 0.147.0
  • Codex Desktop: 26.810.50856
  • iOS Remote client: 1.2026.209
  • Host: Linux x86_64 (6.17.0-14-generic)
  • Rollout size when reproduced: 22,617 records, dominated by one long active turn with many tool and subagent items

Observed behavior

Each Remote attempt completed rollout parsing quickly:

Resumed rollout with 22617 items, parse errors: 0

It then stopped making progress at:

composing running thread resume response ... active_turn_present=true ... active_turn_status=InProgress

During the stall:

  • app-server consumed approximately one CPU core continuously;
  • RSS was approximately 1.1 GB;
  • the client eventually surfaced a generic failure;
  • the user prompt was absent from the target rollout, confirming that steering never began;
  • repeated iOS retries opened additional connections that all stalled at the same reconstruction point.

There were no concurrent 401, 403, duplicate-owner 409, pairing, or websocket-connectivity failures.

Reproduction

  1. Create or retain an active thread with a very large rollout, particularly one long turn containing thousands of tool/subagent items.
  2. Connect to the host through iOS Remote.
  3. Open that thread or send a prompt while its turn is active.
  4. Observe that the client initiates thread/resume with turn history included.
  5. Rollout parsing completes, but the resume response does not return in practical time and the steer is never submitted.
  6. Open the same already-loaded thread in Codex Desktop and use its composer/Steer control; the message is recorded and handled immediately.

The failure also reproduced through the Codex thread-management follow-up path because it performs the same full thread/resume before steering.

Root cause

In app-server/src/request_processors/thread_lifecycle.rs, the loaded-thread resume path calls populate_thread_turns_from_history whenever pending.include_turns is true:

https://github.com/openai/codex/blob/rust-v0.147.0/codex-rs/app-server/src/request_processors/thread_lifecycle.rs#L528-L567

That builds legacy API turns from every rollout item. During reconstruction, upsert_turn_item searches the growing item vector linearly for every incoming item:

https://github.com/openai/codex/blob/rust-v0.147.0/codex-rs/app-server-protocol/src/protocol/thread_history.rs#L1547-L1559

if let Some(existing_item_index) = items
    .iter()
    .position(|existing_item| existing_item.id() == item.id())

For a turn with thousands of items, repeated linear scans make reconstruction effectively quadratic. The stall begins after parsing and exactly where the logs say app-server is composing the running-thread response. The process behavior is consistent with CPU-bound reconstruction rather than a dead connection or authentication failure.

The same linear upsert was still present on main when checked on 2026-08-15.

Expected behavior

A Remote client should be able to open and steer a known active thread without material latency proportional to the square of its retained turn-item count. A failure should also be bounded and retryable rather than accumulating more expensive resume jobs.

Suggested fixes

Two complementary changes would address this:

  1. Metadata-only steering path: when the client already knows the thread and only needs its active turn ID, call thread/resume with excludeTurns: true, then submit turn/steer with expectedTurnId. Do not serialize full history merely to steer an active thread.
  2. Linear history reconstruction: maintain an item-ID-to-index map while building a turn, or otherwise avoid items.iter().position(...) for every item. Pagination/bounds would provide additional protection for unusually large histories.

It would also help to coalesce or reject duplicate in-flight resumes for the same thread so repeated mobile retries do not amplify the CPU queue.

Workaround

Use the already-loaded Codex Desktop composer and explicitly select Steer. This bypassed full history reconstruction and delivered the prompt immediately. Avoid repeated Remote retries on the affected thread.

Privacy note

This report intentionally omits the thread ID and full rollout because the rollout contains private project conversation and tool output. The two sanitized log lines above identify the failing stage without including that content. I can provide narrower diagnostics if maintainers specify what is needed.

Related but not exact duplicates

  • #37047: thread/resume hangs on a stale active listener with no running turn. Here the turn is genuinely in progress and app-server is CPU-bound reconstructing 22k+ history items.
  • #36831: mobile prompt remains stuck in Status Sending; adjacent symptom, but this report identifies the preceding resume-reconstruction bottleneck.
  • #36416: Remote thread/list scans many rollout files. Similar principle—Remote blocking on unnecessary history work—but a different method and data structure.

View original on GitHub ↗

5 Comments

shleder · 11 days ago

The 22k-item active-thread case is a useful scalability/control target for codex-rescue. It won’t fix app-server’s quadratic thread/resume reconstruction or Remote steering; I’m testing whether local session discovery/diagnosis can inspect the same large rollout in a bounded way without needing to hydrate the full UI history.

If you still have the affected local thread, could you try:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

Please start with diagnosis only. I’m interested in runtime, exit code, and whether the tool can classify the persisted state without mutating the rollout or triggering the expensive Remote resume path. A healthy result is valid evidence here too.

Sanitized output only, please—no raw rollout/SQLite, prompts, thread IDs, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue

mrcoinzzz · 11 days ago

I can reproduce what looks like a related large-thread Remote failure, with a particularly strong iPad/iPhone comparison.

Environment:

  • ChatGPT mobile app on iPad and iPhone 15 Pro Max
  • Same ChatGPT account
  • Same Wi-Fi/LAN
  • Same MacBook running the Codex host
  • Same Codex project and same Remote thread

Observed behavior on iPad:

  1. ChatGPT works normally before opening Remote.
  2. Remote project list loads normally.
  3. Opening a short/new thread within the project usually works.
  4. Opening a long-established Remote thread is much more likely to freeze the entire ChatGPT iPad app, sometimes immediately.
  5. Once frozen, I cannot even switch to a normal non-Remote ChatGPT conversation in the app.
  6. If I background ChatGPT for ~10 seconds and bring it back, Face ID appears and the app then closes/terminates with no visible error.

Important A/B control:

  • While the iPad is frozen on that long Remote thread, I can open the exact same Remote thread on my iPhone 15 Pro Max and continue using it normally.
  • If I create a brand-new chat inside the exact same Codex project, the iPad can use that new thread without crashing.

This makes the failure appear strongly correlated with individual thread length/history/state rather than the project, Mac host, network, or Remote pairing itself.

It may be the same underlying large-thread resume/history reconstruction problem described in this issue, but on iPad the symptom is severe enough to freeze the entire ChatGPT app and then terminate it on foreground restore.

Happy to provide iPad model, iPadOS version, ChatGPT app version, or any diagnostics/crash logs if useful.

mrcoinzzz · 11 days ago

Follow-up after testing with a fresh thread this morning:

Thread size is clearly a strong aggravating factor, but it does not appear to be the sole trigger.

  • A brand-new/fresh Remote thread on the iPad can also occasionally freeze the ChatGPT app, although much less frequently.
  • Long-established threads freeze substantially more often.
  • Very large threads can freeze immediately on selection, sometimes before the thread contents are even displayed.
  • The same Remote threads continue to work normally on my iPhone 15 Pro Max.

So creating a fresh thread greatly improves reliability on the iPad, but does not eliminate the underlying Remote freeze. The fact that very large threads can trigger the freeze before their contents render may be useful diagnostically - it suggests the large-thread failure can occur during loading/hydration/resume rather than only while rendering an already-loaded conversation.

This may therefore be an underlying iPad Remote instability that is significantly amplified by large thread history, rather than thread size being the only cause.

mrcoinzzz · 9 days ago

Practical workaround update, in case it helps other iPad Remote users while this is being investigated:

I have now changed my long-running Codex workflows to use fresh threads regularly. For my daily helpdesk workflow, I start a new thread each morning rather than continuing the very large historical thread.

To preserve continuity, the new thread receives only a small handover/bootstrap prompt. That prompt tells Codex to read a small project file, which in turn points it to the other persistent instructions/resources it needs. Codex can then reconstruct the working context from the project itself rather than requiring the previous conversation history.

Result on my iPad:

  • Using the old very large Remote threads would reliably freeze the ChatGPT app within moments, sometimes before the thread even displayed, making Remote effectively unusable.
  • Using fresh threads with this lightweight handover/bootstrap approach makes iPad Remote usable again.
  • It does still freeze occasionally, so this is not a fix for the underlying iPad Remote issue, but the failure frequency is dramatically lower.

For workflows where the durable state already lives in project files, a ticket system, repository, etc., this seems to be a useful temporary workaround: keep Remote threads relatively short and bootstrap each fresh thread from persistent project resources rather than carrying a huge conversation indefinitely.

shleder · 1 day ago

Practical sizing tip for the fresh-thread rotation workaround above: per-session rollout size is a decent proxy for when rotation is due. vetto rescue --json scan reports bytes per session read-only, so you can rotate on measured growth instead of guessing.