Desktop delegation report delivered three times after one source emission

What version of the Codex App are you using?

Codex Desktop app: 26.707.30751

Platform

macOS 15.6.1 (24G90), arm64.

What issue are you seeing?

A terminal report from one delegated Codex thread was delivered three times to its coordinator even though the source thread emitted it exactly once.

This is an at-least-once delivery/idempotency problem in delegated task reporting. It is potentially dangerous when a report carries execution or commit authorization: without receiver-side deduplication, the coordinator can repeat work or process the same authority transition more than once.

Evidence

Local rollout evidence was inspected without including conversation content or local paths in this report.

Source rollout:

• the report marker occurs in exactly one final assistant emission;
• no resend, retry, follow-up, or second delegation call exists around that emission.

Coordinator rollout:

• three distinct logical user-message ingress records were created;
• arrival timestamps were:
• 18:57:29.702Z
• 18:57:29.721Z
• 18:57:29.735Z
• each normalized payload was exactly 3,507 bytes;
• all three had the same SHA-256: bd009a00b6e1947d87d648f700b7a79db68f29908d6d2717fbd79df73d0b178a.

The coordinator rollout stores each logical user message as both a response item and an event message, so the six raw matching records represent three deliveries, not six.

The same triple-delivery pattern was observed for reports from multiple independent delegated lanes, which localizes the behavior to shared delegation delivery/coordinator ingress rather than one source agent.

The delivered payload also contained an escaped inner <codex_delegation> wrapper inside the transport-owned outer wrapper. That may be a contributing parser/fan-out condition, but it does not explain why a single source emission was admitted three times without deduplication.

Steps to reproduce

1. Keep one coordinator thread active.
2. Configure a separate delegated thread to report its terminal result to that coordinator.
3. Have the source thread emit one terminal report.
4. Inspect the coordinator rollout.
5. Observe that the same report may appear as three distinct user-message ingresses within a few milliseconds.

This occurred after coordinator thread migration/recovery, so duplicate route/subscription registrations may be relevant.

Expected behavior

A logical delegated report should be admitted exactly once per target thread.

The transport should attach a stable delegation/delivery ID and the coordinator ingress should deduplicate that ID. Retry behavior should reuse the same ID.

At minimum, duplicate payloads with the same:

• source thread ID,
• target thread ID,
• source terminal turn/message ID, and
• normalized payload hash

should not create multiple coordinator user messages.

Current workaround

Receiver-side application logic treats reports as idempotent and processes only the first delivery using a key equivalent to:

source_thread_id + normalized_payload_sha256

Additional operational mitigations:

• emit plain report text from the source; do not place an escaped <codex_delegation> wrapper inside the transport wrapper;
• install one report target once;
• do not resend after a stale-thread/thread not found failure until a fresh renderer has completed thread/resume.

These mitigations reduce risk but do not replace transport-level exactly-once or idempotent delivery.

Related issue

Related lifecycle issue: #30710.

#30710 covers stale renderer resume state and turn/start against a durable-but-unloaded thread. This report is distinct: the source completed normally, but one delegated report was duplicated during relay/ingress. Thread migration/resume may still be a shared contributing condition.

No repository mutation or duplicate execution occurred in this instance because the coordinator manually deduplicated the reports.