Codex Desktop heartbeat automation results intermittently disappear from thread UI despite backend persistence

Open 💬 0 comments Opened Jul 5, 2026 by Ray0213

Version: Codex app 26.623.101652 on macOS

Summary:
Thread heartbeat automations attached to existing threads sometimes complete, and the result may briefly appear in the UI, then disappear from the visible thread. In affected cases, backend/thread state and later thread reads indicate the result exists or the work completed, but the desktop UI does not retain the assistant closeout reliably.

What I observed:

  • Several heartbeat automations on 2026-07-04 showed the same failure mode.
  • Some affected turns were marked completed but contained only the injected heartbeat userMessage and no assistant final message.
  • In other cases, a restored or replayed assistant result briefly appeared in the UI for a few seconds and then disappeared again.
  • Using thread read tooling afterwards, the thread data could still be read from the backend, so this does not look like simple data loss in local storage.

Affected heartbeat target threads:

  • 019ea7be-4914-7540-bdf5-aba7245db5c1
  • 019ea402-df4c-7863-85aa-7a7071d0c376
  • 019eff5f-40b8-7bd2-a68e-7353e4409e37
  • 019ec05e-1ea7-7283-bb34-261b322541b8

Relevant log evidence:
In ~/.codex/app-server-daemon/app-server.stderr.log, repeated warnings appear during the same session window:

  • dropping notification from unknown connection: ConnectionId(...)

Examples:

  • 2026-07-05T07:56:56.051380Z dropping notification from unknown connection: ConnectionId(4)
  • 2026-07-05T08:05:20.093894Z dropping notification from unknown connection: ConnectionId(146)
  • 2026-07-05T08:46:20.744630Z dropping notification from unknown connection: ConnectionId(323)

Why this seems app-side or notification-sync related:

  • Official docs say thread automations should return to the same thread on a schedule.
  • Backend thread reads can still retrieve the restored or replayed content.
  • The visible UI is the part that diverges: result appears transiently or not at all.
  • The repeated app-server warning suggests a notification delivery or connection ownership problem between app-server and desktop UI.

Expected behavior:

  • A heartbeat automation result that completes should remain visible in the target thread UI.
  • If the app reconnects or rehydrates thread state, the final assistant closeout should not disappear.
  • Notification delivery failures should not cause UI and backend divergence.

Operational impact:
This breaks recurring production automations because the scheduled result is not reliably visible in the thread, and future automation behavior may depend on that thread history being stably present in the desktop UI.

View original on GitHub ↗