Best possible solution:

Use #95725 as the canonical executor-boundary fix and keep the related issues open until one chosen policy lands.

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

Yes. Source inspection shows current main still routes cron runs to CLI and embedded runners without the silent-empty opt-in, while both runner contracts require the caller flag for empty assistant output.

Is this the best way to solve the issue?

No. Passing the flag at the cron executor boundary is the right layer, but this branch is narrower and weaker than the newer candidate that covers both current runner paths with better proof.

Security review:

Security review cleared: The diff forwards an existing internal boolean and adds tests; it does not touch dependencies, CI, secrets, install scripts, package resolution, or auth boundaries.

AGENTS.md: found and applied where relevant.

What I checked:

• PR diff is narrow and embedded-only: The submitted patch adds allowEmptyAssistantReplyAsSilent to the older cron executor parameter flow and forwards it to the embedded runner, but it does not cover the current CLI cron handoff that also requires the flag. (src/cron/isolated-agent/run-executor.ts:245, c9f6ffe30fc5)
• Current main has two cron runner handoffs: Current main routes isolated cron runs through both runCliAgent and runEmbeddedAgent, and neither current call passes allowEmptyAssistantReplyAsSilent. (src/cron/isolated-agent/run-executor.ts:328, 9d68f877ac3e)
• CLI runner still requires explicit opt-in: The CLI runner throws FailoverError with reason empty_response when assistant text is empty, no messaging tool sent, and the caller did not set allowEmptyAssistantReplyAsSilent. (src/agents/cli-runner.ts:817, 9d68f877ac3e)
• Embedded runner contract is caller-controlled: The embedded runner consumes allowEmptyAssistantReplyAsSilent through shouldTreatEmptyAssistantReplyAsSilent, so the cron caller is the right boundary for the policy. (src/agents/embedded-agent-runner/run.ts:3805, 9d68f877ac3e)
• Canonical replacement is viable: The newer PR is open, mergeable, labeled proof: sufficient, and its diff adds the silent-empty flag to both CLI and embedded cron handoffs. (src/cron/isolated-agent/run-executor.ts:332, 3940d8837b6e)
• Related issue context confirms overlap: The linked older issue tracks the embedded no-delivery variant, while the newer canonical issue tracks the broader cron empty-response regression that the canonical PR addresses.

Likely related people:

• steipete: Recent path history shows work on cron session behavior and prior CLI silent-empty caller behavior that overlaps this policy boundary. (role: recent cron and silent-empty policy contributor; confidence: high; commits: be5906e19dd7, 9ead0ae9219e; files: src/cron/isolated-agent/run-executor.ts, src/cron/isolated-agent/run.ts, src/agents/cli-runner.ts)
• vincentkoc: History shows recent work on the isolated cron executor runtime split and embedded runtime loading around the affected handoff boundary. (role: recent cron executor contributor; confidence: high; commits: 21d850dd6656, 14e448e0e13d; files: src/cron/isolated-agent/run-executor.ts)
• joshavant: Commit history ties the CLI empty_response failure behavior to fix empty cli response handling, which is the runner contract this PR tries to opt into. (role: introduced empty-response guard; confidence: high; commits: 2dc4c8373744; files: src/agents/cli-runner.ts, src/agents/cli-runner.before-agent-reply-cron.test.ts)
• obviyus: Recent GitHub path history shows adjacent cron executor/session-target work near the current run preparation and delivery boundary. (role: recent adjacent cron contributor; confidence: medium; commits: bc7f9a36ec55; files: src/cron/isolated-agent/run.ts, src/cron/isolated-agent/run-executor.ts)

Codex review notes: model internal, reasoning high; reviewed against 9d68f877ac3e.