Codex Desktop: background turn reported completed/interrupted while JSONL continues without final_answer or task_complete

Summary

Codex Desktop/app-server can report a background-created turn as completed/interrupted while the underlying rollout JSONL is still receiving events and has no final_answer or task_complete.

This appears to affect threads created through app-server thread/start + turn/start, where the external orchestrator only receives acceptance, not final completion.

Environment

Codex Desktop release observed in logs: 26.810.41047
app-server version observed in logs: 0.148.0-alpha.9
session cli_version: 0.146.0
Host: local macOS
Model provider: codex_local_access
Timezone used below: Asia/Shanghai, UTC+8

Evidence

Example B, no compaction/handoff case:

Thread: 01a00ee4-6014-7632-ae22-0aef4775476d
Turn: 01a00ee4-68c7-7492-9f8f-31fcd00750ae
Local JSONL: $HOME/.codex/sessions/2026/08/17/rollout-2026-08-17T16-44-02-01a00ee4-6014-7632-ae22-0aef4775476d.jsonl
At 2026-08-17 16:52:07 UTC+8, the JSONL had 224 lines, latest event timestamp 2026-08-17T08:52:07.812Z.
The JSONL contained no final_answer and no task_complete.
read_thread returned the turn as status="interrupted", error=null, completedAt=null.
wait_threads(timeoutMs=0/5000) woke with reason="turnCompleted", but the same response still had latestTurn.status="interrupted" and completedAt=null.
During polling, the JSONL kept growing, e.g. 206 -> 216 -> 224 lines, showing events were still being appended after the turn was treated as completed/interrupted.
Desktop log around 2026-08-17T08:46:50.390Z showed maybe_resume_success ... latestTurnStatus=interrupted ... markedStreaming=true; the JSONL continued appending after that.

Example A, compaction/handoff-adjacent case:

Thread: 01a00ec3-e645-7822-91db-1257005fd4c4
A phase="final_answer" handoff summary appeared mid-turn at 2026-08-17 16:12:41 UTC+8.
The actual same-turn task_complete was later at 2026-08-17 16:17:19 UTC+8.
Desktop appeared to treat the turn as completed before the real task_complete.

Expected Behavior

wait_threads should not wake with reason="turnCompleted" unless the turn has a real terminal state.
read_thread and Desktop should not present a turn as completed/interrupted while the same turn is still receiving JSONL events.
A mid-turn phase="final_answer" should not be treated as task completion without task_complete.

Actual Behavior

wait_threads can wake as turnCompleted while the latest turn is still interrupted with completedAt=null.
Desktop/read model can diverge from the underlying rollout JSONL stream.
Users see background Codex tasks as if they stopped or completed halfway.

Impact

External orchestrators that create Codex tasks through app-server cannot reliably tell whether a turn genuinely finished. Desktop UI also makes background tasks look like they stopped or completed halfway.

Suspected Area

Codex Desktop/app-server read model or wait semantics for background-created turns. This is not limited to context compaction: compaction/handoff final_answer is one trigger shape, but the second example reproduces without final_answer or task_complete.

Diagnostics Snippets

Minimal excerpts only; full logs/JSONL may contain local paths, prompts, project names, message content, and tool outputs.

wait_threads contradiction

{
  "wake": {
    "reason": "turnCompleted",
    "turnId": "01a00ee4-68c7-7492-9f8f-31fcd00750ae",
    "threadId": "01a00ee4-6014-7632-ae22-0aef4775476d"
  },
  "latestTurn": {
    "id": "01a00ee4-68c7-7492-9f8f-31fcd00750ae",
    "status": "interrupted",
    "error": null,
    "completedAt": null,
    "durationMs": null
  }
}

JSONL terminal-event check

{
  "line_count": 224,
  "last_timestamp": "2026-08-17T08:52:07.812Z",
  "finalLines": [],
  "completeLines": []
}

Desktop resume log summary

At 2026-08-17T08:46:50.390Z, Desktop logged a successful resume for the same thread with:

maybe_resume_success ... latestTurnId=01a00ee4-68c7-7492-9f8f-31fcd00750ae latestTurnStatus=interrupted markedStreaming=true ... turnCount=1

The rollout JSONL continued appending after this log line.

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

[Windows App] Repeated stream disconnected before completion during long-running tool operations while work continues #37647

Powered by Codex Action

A second live reproduction on Codex Desktop 26.820.7780.0 (Windows ARM64, local CLI 0.149.1) shows a stronger form of the same background-turn projection failure when the target runs on a Linux Remote SSH host.

At one instant, the first-party task tools returned these conflicting views for the same target thread and turn:

read_thread: thread active, latest turn inProgress, completedAt=null.
wait_threads(timeoutMs=0): thread active, the same latest turn interrupted, completedAt=null.
The wait snapshot exposed an early commentary message and an early completed tool marker as the latest visible progress.
The read projection contained later tool activity from the same turn.
Additional send_message_to_thread calls succeeded and their inputs appeared in that existing turn, but no separate new turn was created.

This caused the orchestrating task to conclude that the target thread was corrupted and needed replacement, although the target was still executing and receiving follow-ups. The failure therefore affects both lifecycle control and model decisions, not only the UI.

Minimal reproduction shape:

Start a long background turn on a Remote SSH task.
Send several follow-ups from another task with send_message_to_thread.
While the target is still active, query it with both read_thread and wait_threads(timeoutMs=0).
Observe that the same turn can be inProgress in one projection and interrupted in the other, while the aggregate thread remains active.
Continue sending follow-ups. They are accepted into the existing turn, but the sender cannot reliably determine whether it steered a live turn, resumed an interrupted turn, or started a new one.

Expected behavior:

All first-party task APIs must derive one authoritative lifecycle state for a turn.
wait_threads must not expose interrupted while later activity from that same turn is visible through read_thread.
A successful cross-thread send should make its effect explicit: queued, steered into the active turn, or started as a new turn.
Stale progress markers must not override newer persisted activity.

I did not inspect or modify the remote JSONL or database for this reproduction. The evidence above comes only from live, read-only Codex task APIs. No task IDs, prompts, project names, hostnames, addresses, paths, or account data are included.

Fresh sanitized cross-API snapshot from Codex Desktop 26.820.7780.0 with CLI 0.149.1 and a task on a Linux Remote SSH host.

At the same instant, first-party task APIs returned mutually incompatible lifecycle views:

wait_threads(timeoutMs=0): aggregate thread active, revision unchanged, latest turn completed, final response present.
read_thread: aggregate thread active, but an older turn projected as inProgress with completedAt=null.
Cross-thread follow-up messages were accepted and advanced the thread update timestamp, but no new latest turn appeared and the wait revision did not change.

The orchestrating task interpreted the aggregate active state as evidence that new work had started, then entered repeated 60-second waits. In reality, the only authoritative latest turn exposed by wait_threads was already terminal.

This strengthens the lifecycle impact: the disagreement can cause an orchestrator to make incorrect control decisions and spend additional model turns waiting for work that was never started.

Expected behavior:

read_thread, wait_threads, and cross-thread send must share one authoritative latest-turn projection.
An accepted follow-up must explicitly report whether it was queued, steered into a live turn, or started a new turn.
Aggregate active must not coexist indefinitely with only a terminal latest turn unless the API exposes the distinct activity that keeps the thread active.

No prompts, task IDs, project or repository names, paths, hostnames, addresses, account data, or credentials are included.

A fresh reproduction adds a recovery/control failure to the lifecycle projection problem.

Environment:

Codex Desktop package 26.820.7780.0 on Windows ARM64.
Target task runs through Linux Remote SSH with codex-cli 0.149.1.
Evidence comes only from the first-party task APIs. No rollout or database was inspected.

Observed behavior:

The target remained aggregate active with the same turn reported inProgress, completedAt=null, for more than 24 hours. The latest visible tool marker was already completed, and no newer assistant progress was exposed.
A cross-thread send_message_to_thread call returned success and advanced the task's updatedAt.
Despite that accepted send, the wait revision remained 1, the same old turn remained latest, and no new turn appeared.
wait_threads(timeoutMs=0) and read_thread continued to expose the same stale commentary/tool boundary. Neither API indicated whether the accepted message was queued, steered into the ghost turn, or discarded.
A full Desktop process restart restored the Remote SSH transport and native task reads, but did not recover or terminate the ghost turn.
The first-party task surface exposes no bounded interrupt/cancel operation for an ordinary task. The only reliable recovery is a manual UI Stop. handoff_thread is not a safe substitute because it also moves execution placement and associated Git state.

Impact:

An orchestrator cannot recover a stale remote turn without user interaction.
Successful message acceptance is not proof that work started.
Repeated waits or scheduled checks can consume model turns while the target revision and visible work remain unchanged.
Using handoff as an interrupt risks unrelated checkout/worktree side effects.

Expected behavior:

Expose a first-party interrupt/cancel operation keyed by host and task identity, without migration or Git side effects.
Make send_message_to_thread return an explicit disposition: queued, steered into a live turn, started a new turn, or rejected.
Advance the revision when accepted work becomes observable.
Detect and recover an aggregate active task whose latest turn has made no observable progress after its last completed tool.
Keep read_thread, wait_threads, aggregate status, and send disposition on one authoritative lifecycle state.

This appears to be the same underlying projection defect as the issue, with an additional missing recovery primitive rather than a separate duplicate.

A fresh Remote SSH reproduction adds a four-way lifecycle disagreement plus a missing paginated-history projection for a structurally valid, actively growing thread.

Environment:

Codex Desktop: 26.820.9563.0 on Windows ARM64.
Remote Codex CLI/app-server: 0.149.1 on Linux.
Affected thread ID: 019ee6ac-9514-7a21-b8fe-913884f7b98d.

At the same time, first-party surfaces reported incompatible states for the same thread and current turn:

Native wait_threads: aggregate thread active, current turn inProgress, with fresh progress.
A fresh app-server thread/turns/list: the same current turn was interrupted.
A fresh app-server metadata-only thread/read: thread status notLoaded and a stale updatedAt.
Desktop task inventory: thread active.

The fresh thread/turns/list request returned in about 2.6 seconds, so this snapshot was not a generic transport timeout.

Storage evidence:

The exact rollout existed, continued to grow, and a full snapshot contained about 380 MB and 98,239 valid JSONL records with zero parse failures.
The remote thread-store row contained the correct rollout reference and current metadata.
The paginated history database had no projection state row, zero projected turns, and zero projected items for this thread.
The active writer retained the rollout and continued normal work.

User-visible impact:

Desktop first showed a false no rollout found error, then remained on “Loading task…”.
VS Code refused the same thread as open in another application.
The native task APIs could still observe the live turn, so orchestration and UI clients made decisions from mutually incompatible projections.

Expected behavior:

thread/read, thread/turns/list, Desktop inventory, and native task APIs must use one authoritative latest-turn lifecycle.
A live turn must not simultaneously project as inProgress, interrupted, notLoaded, and aggregate active.
If the paginated projection is absent while the rollout and thread-store row are valid, app-server should rebuild it or fall back to bounded rollout reading.
The renderer should surface a specific projection/ownership error instead of presenting missing history or spinning indefinitely.

No repository name, project title, username, hostname, address, filesystem path, prompt content, or raw log is included.

Document ranked GitHub issues for lifecycle disagreement

Fresh sanitized reproduction on macOS with codex-cli 0.152.0 confirms the same false-terminal read/wait projection on a newer build.

Observed sequence for one background app-server turn:

External orchestration started the turn normally and received ongoing exact same-turn activity/usage updates.
read_thread / wait subsequently projected the turn as status="interrupted" with completedAt=null.
At that moment the owning Python/App Server process group was still mechanically live.
No exact-turn turn/interrupt, Op::Interrupt, cancel, abort, provider limit/error, reset event, or persisted turn_aborted was found.
The underlying rollout JSONL continued appending same-turn tool completions, reasoning/message events, and token-count updates after the false interrupted observation.
The same rollout later persisted a genuine task_complete for that turn.
No compaction/context-error event was present in this reproduction.

This caused the external Supervisor/orchestrator to stop the work early because it treated the read/wait projection as an authoritative terminal state, even though the owned rollout was still progressing and eventually completed normally.

This appears to be a direct match for the issue's original failure mode rather than a separate cancellation path.

Suggested invariant for app-server consumers: a reconstructed/read-model interrupted with completedAt=null should not be considered authoritative terminal evidence while the same owned turn is still producing persisted activity and no true terminal/abort event exists.

No prompts, task/thread IDs, repository/project names, local paths, account data, credentials, or user content are included here. Full local forensic evidence was preserved privately if maintainers need additional sanitized fields.

Navigation Menu

Repository navigation

Codex Desktop: background turn reported completed/interrupted while JSONL continues without final_answer or task_complete #38972

Summary

Environment

Evidence

Expected Behavior

Actual Behavior

Impact

Suspected Area

Diagnostics Snippets

wait_threads contradiction

JSONL terminal-event check

Desktop resume log summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codex Desktop: background turn reported completed/interrupted while JSONL continues without final_answer or task_complete #38972

Description

Summary

Environment

Evidence

Expected Behavior

Actual Behavior

Impact

Suspected Area

Diagnostics Snippets

wait_threads contradiction

JSONL terminal-event check

Desktop resume log summary

Activity

github-actions commented on Aug 17, 2026

nos1609 commented on Aug 26, 2026

nos1609 commented on Aug 26, 2026

nos1609 commented on Aug 26, 2026

nos1609 commented on Aug 27, 2026

randzzD89 commented on Sep 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions