Codex App: expose acknowledgment and follow-up acceptance for task-to-dot handoffs #50138

What variant of Codex are you using?

Codex App on macOS: a local task used native Codex app thread tools to message an existing hosted dot. The exact desktop build was not collected. Standalone Codex CLI 0.160.0 was used only as the text-only feedback transport.

What feature would you like to see?

Expose a per-message handoff receipt that distinguishes delivery, recipient acknowledgment, and acceptance of follow-up responsibility. Make it available to the sending task and visible to the user, with pending, accepted, declined, or deferred states correlated to the original message.

Observed sequence

Observed October 1, 2026, America/New_York, in one handoff:

1. The user authorized a local task to send a summary to their existing dot so it could follow up if needed.
2. The task called native send_message_to_thread once. It succeeded and returned the destination thread ID.
3. A separate read_thread check confirmed the exact message in the destination history and a processing turn with a background-agent event.
4. Subsequent inspected history and a later idle snapshot did not show an explicit acknowledgment or acceptance of the follow-up responsibility.
5. The user had to ask whether the handoff was acknowledged.

Delivery succeeded. The missing evidence was recipient acknowledgment and accepted ownership of the follow-up.

User impact and requested behavior

A successful send leaves the user uncertain whether the recipient accepted responsibility. Additional history inspection is needed, and resending could create duplicate work.

Please provide a lightweight handoff record or equivalent receipt with acknowledgment and follow-up acceptance status. Receipt inspection should not itself resend a message or wake the recipient. Preserve authorization and privacy boundaries.

Additional information

This is an enhancement request based on one observed handoff. It does not establish lost messages, a broken transport, lost context, permanent failure to follow up, or a specific internal cause.

The official dot getting-started documentation and dot controls documentation describe follow-up and Activity review; they do not promise immediate acknowledgment.

Related issues reviewed

• Follow-up: typed, evidence-aware CrossThreadEvent contract for safe peer-thread orchestration #36843 proposes typed cross-thread event contracts and disposition auditing. This request focuses on a sender/user-visible receipt for an existing task-to-dot message, including acceptance of follow-up responsibility.
• Improve discovery and wrong-route diagnostics for dot continuation of local Codex chats #49482 concerns route discovery and wrong-route diagnostics. The observed delivery here succeeded.
• [Dots][macOS][Pro] Delegated work stalls after task completion or approval blocker; repeated reminders needed #49883 concerns delegated-work follow-through after completion or approval blockers. This observation concerns acknowledgment of an incoming summary, and does not establish the same failure.

OpenAI feedback was submitted first and its receipt verified:
no-active-thread-01a0fa36-8183-74e2-a63a-ffafa58dd03e.

Logs, traces, screenshots, private conversations, original task identifiers, legal material, and attachments: NONE.