Connected-app writes need definitive recovery after transport errors

Summary

A connected-app write can begin dispatch and then return an MCP transport/send
error without an object identifier. The action can remain present in the tool
catalog, but the write outcome is unknown. Later negative search or listing
results are not definitive proof that the write did not commit, so safely
retrying may create a duplicate.

Sanitized reproduction

1. Start a fresh Codex task and confirm the connected-app read and write actions

are registered and callable.

1. Complete multiple read/write cycles with normal results.
2. Invoke another write action.
3. Observe an MCP transport/send error after dispatch begins, with no returned

object identifier or operation identifier.

1. Confirm the action remains registered. Do not retry the write.

The local MCP call item can report a failed call, but that is not a definitive
status for the external write. Search/list absence may lag and names need not be
unique.

Requested recovery contract

Please support exactly one of these contracts for connected-app writes:

1. A connector-persisted caller idempotency key whose replay returns the

original object identifier and result; or

1. A stable operation identifier plus a definitive committed/not-committed

lookup that returns the object identifier when committed.

Either contract would let fail-closed workflows recover from a lost response
without risking a duplicate. A catalog refresh or fresh task alone does not
resolve the unknown outcome.

Environment

• Codex CLI: 0.144.4
• Surface: Codex desktop on macOS
• Connected app: official Codex connected-app action

No retry or alternate write path was attempted.