## Summary After a Codex runtime stream disconnect during compact (chatgpt.com), the affected session stops dispatching new messages entirely — inbox accumulates pending items but no new Codex process is spawned. ## Environment - duoduo version: 0.5.4-pre.1 - channel: feishu (channel-feishu 0.5.2-pre.6) - runtime: codex ## Reproduction 1. A Codex job or session is running and hits a network disconnect during compact: ``` Error running remote compact task: stream disconnected before co

Codex runtime: session stops dispatching after stream compact disconnect

Status Fixed / completed

Maintainer reply None cached

Activity 3 comments · opened May 27, 2026 · closed May 27, 2026

Summary

After a Codex runtime stream disconnect during compact (chatgpt.com), the affected session stops dispatching new messages entirely — inbox accumulates pending items but no new Codex process is spawned.

Environment

duoduo version: 0.5.4-pre.1
channel: feishu (channel-feishu 0.5.2-pre.6)
runtime: codex

Reproduction

A Codex job or session is running and hits a network disconnect during compact:

``Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)``

After disconnect, the session state shows last_event_at updated on new ingress events, but no new streaming-card started log appears.
Session inbox accumulates .pending files indefinitely.
Subsequent messages from the user get no response.

Observed behavior

From feishu channel logs:

[INFO] [bot] ingress {"msgId":"om_x100b6e44275d2ca8c21994025c002d5", "sessionKey":"lark:oc_473ab07146f5702cfcefea0d63f1a9cd:...", "textLen":6}

— no streaming-card started follows. Three consecutive messages (file attachment, @mention, text) all ingressed but none dispatched.

Session inbox:

2026-05-27T14-57-09-050Z_i6wnj7yu6aj.pending
2026-05-27T14-58-31-457Z_dw84zcdc25c.pending

Root cause (observed)

The stale codex app-server processes (spawned by duoduo at 4:20PM, 5:30PM, 5:52PM) appear to hold dead connections. Killing all three duoduo-managed codex app-server PIDs (22579/22580, 30557/30558, 37887/37888) clears the block. However, duoduo does not auto-restart these processes after kill — next dispatch requires a new message trigger.

Also affected

Same root cause caused daily-tod-noon-scan-1230 job failure:

last_error: "Error running remote compact task: stream disconnected before completion: 
error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)"

Expected behavior

After a compact stream disconnect, the session should retry or spawn a fresh Codex process for pending inbox items.
Alternatively, the dispatcher should detect stale Codex app-server processes and restart them automatically.

View original on GitHub ↗

3 Comments

winfred5432 · 4 months ago

Follow-up: killing codex app-server processes is insufficient

After killing the three stale codex app-server PIDs, the session did NOT recover. The dispatcher still failed to spawn new Codex processes for pending inbox items.

A full daemon restart (duoduo daemon restart) is required to clear the stuck state.

This means the block is not just at the process level — the daemon itself holds state (likely an in-memory session lock or dispatcher reference) that survives the subprocess kill. Only a daemon restart fully clears it.

Updated remediation steps

kill <codex app-server PIDs> — insufficient alone
duoduo daemon restart — required to restore dispatch
User must re-send their message to trigger a fresh Codex session

Impact

Any user messages received during the stuck window are lost from the dispatch queue — they remain as .pending files in the session inbox but may not be automatically replayed after daemon restart. Manual replay or user re-send is needed.