Best possible solution:

Land the narrow pending-status guard with regression coverage after adding or explicitly folding the user-facing duplicate-media-fallback note into the existing Unreleased media changelog entries.

Do we have a high-confidence way to reproduce the issue?

Yes by source inspection. On current main, a direct announce response shaped like { status: "accepted" } has no result, so the existing fallback check treats it as fallback-worthy and can send the raw generated-media completion while the announce run is still pending.

Is this the best way to solve the issue?

Yes for the code path. Recognizing accepted, started, and in_flight as pending before fallback matches the gateway contract and is the narrowest maintainable runtime fix; the remaining issue is the required changelog handling.

Full review comments:

• [P3] Add the changelog entry — src/agents/subagent-announce-delivery.ts:1055
  This is a user-facing fix for duplicate generated-media completion messages, but the PR only changes runtime code and tests. Repo policy requires a CHANGELOG.md entry for user-facing fixes before merge, unless maintainers explicitly fold this into an existing media entry.
  Confidence: 0.78

Overall correctness: patch is correct
Overall confidence: 0.84

Acceptance criteria:

• git diff --check
• pnpm test src/agents/subagent-announce-delivery.test.ts

What I checked:

• Current fallback path: On current main, shouldSendCompletionFallback returns true when an announce response has no visible gateway agent payload, which includes a pending ack with no result. (src/agents/subagent-announce-delivery.ts:667, 9c4a335007d7)
• Pending agent response contract: The gateway agent method sends an immediate { status: "accepted" } response before the final response, and dedupe code treats accepted, started, and in_flight as non-terminal. (src/gateway/server-methods/agent.ts:1286, 9c4a335007d7)
• Non-terminal status evidence: readTerminalSnapshotFromDedupeEntry returns null for accepted, started, and in_flight, matching the PR's pending-status set. (src/gateway/server-methods/agent-wait-dedupe.ts:93, 9c4a335007d7)
• Media delivery contract: The media docs say async tools wake the agent with generated media paths and only send the generated media fallback directly when message-tool delivery evidence is missing after a completion attempt. Public docs: docs/tools/media-overview.md. (docs/tools/media-overview.md:91, 9c4a335007d7)
• Relevant history: Commit 6c8974f recently hardened async media completion delivery and touched the same implementation and test files. (src/agents/subagent-announce-delivery.ts, 6c8974f3f5a9)

Likely related people:

• steipete: The directly relevant async media completion delivery hardening appears in current-main history at commit 6c8974f, authored and committed by Peter Steinberger, touching the same runtime, test, and changelog surface. (role: recent maintainer and behavior author; confidence: high; commits: 6c8974f3f5a9; files: src/agents/subagent-announce-delivery.ts, src/agents/subagent-announce-delivery.test.ts, CHANGELOG.md)
• vincentkoc: Local file history also shows Vincent Koc touching the same central files in commit a52010b, and adjacent Unreleased Agents/media and Agents/subagents changelog entries credit related work to @vincentkoc. (role: adjacent recent maintainer; confidence: medium; commits: a52010be7d2d; files: src/agents/subagent-announce-delivery.ts, src/agents/subagent-announce-delivery.test.ts, CHANGELOG.md)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 9c4a335007d7.