app-server: targeted notification fan-out clones the final subscriber payload

Start at send_server_notification_to_connections in codex-rs/app-server/src/outgoing_message.rs:585-620, then read OutgoingMessage in codex-rs/app-server-transport/src/outgoing_message.rs:27-36. Trace the targeted ToConnection send loop and verify that iteration order and delivery are preserved while the final selected connection reuses the owned message instead of receiving another clone.

What variant of Codex are you using?

App Server

What feature would you like to see?

I found a potential performance concern in current source rather than a confirmed user-visible bug. I would like targeted server-notification fan-out to reuse its owned OutgoingMessage for the final selected connection rather than cloning it for every selected connection.

Additional information

Evidence

• send_server_notification_to_connections in codex-rs/app-server/src/outgoing_message.rs:585-620 constructs one owned OutgoingMessage. For a nonempty targeted connection list, the loop sends outgoing_message.clone() in every OutgoingEnvelope::ToConnection; the original is not used after the loop and is dropped.
• OutgoingMessage in codex-rs/app-server-transport/src/outgoing_message.rs:27-36 derives Clone and contains the app-server notification envelope, so this clones the whole owned outgoing notification message.
• Moving the original into the final selected ToConnection would keep the existing iteration/send order and reduce the clone count from the number of selected connections to at most subscriber_count - 1, including zero clones when exactly one connection is selected.

Impact

Not measured. The avoidable clone can copy an entire targeted notification payload, including in the single-subscriber case. The potential allocation and copying cost scales with notification payload size and targeted-notification rate; allocation volume, throughput, and latency have not been measured.

Question

Would it make sense to clone the message for every selected connection except the final one, then move the original OutgoingMessage into that final OutgoingEnvelope::ToConnection?

I checked all relevant issues, comments, pull requests, discussions, and release notes; this report is not a duplicate.

I am reporting this finding only and am not proposing a pull request unless a maintainer invites one.

Disclosure

Investigated thoroughly with GPT-5.6 Sol (runtime-default reasoning effort), using Oh My Pi as the agent framework.

This report is not generic or unreviewed AI-generated output. Its claims were checked against the cited evidence, and it includes the relevant detail intended to help maintainers resolve the issue.

If reports like this are not useful to the project, please let me know and I will refrain from submitting similar ones. My intent is to help without wasting maintainer time or energy or discouraging their work.

Thank you for your work.