Summary

• Problem: silentReply.direct: "allow" told direct-chat prompts to use NO_REPLY, but empty or reasoning-only direct turns were still treated as failed empty responses.
• Why it matters: operators who explicitly opt direct chats into silence should get the same intentional-silence handling as NO_REPLY, without changing conservative direct-chat defaults.
• What changed: direct/dm runs now pass allowEmptyAssistantReplyAsSilent only when the resolved prompt-policy context is direct and silentReply.direct resolves to allow.
• What did NOT change (scope boundary): group/channel behavior, default direct-chat behavior, silent rewrite behavior, and cross-session native command targeting remain conservative.

AI-assisted: yes. I understand what the code changes do.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes silent-reply detection gated behind isGroupChat — direct chats can't honor silentReplyPolicy="allow" #74409
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the prompt path resolved direct silent-reply policy, but allowEmptyAssistantReplyAsSilent was gated behind isGroupChat only.
• Missing detection / guardrail: coverage checked group empty/reasoning-only silence and direct prompt text, but not direct runner propagation for explicit silentReply.direct: "allow".
• Contributing context (if known): direct chats intentionally default to disallow, so the fix must only apply to explicit direct policy context.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/auto-reply/reply/get-reply-run.media-only.test.ts
• Scenario the test should lock in: direct and dm runs propagate empty-assistant silence only when direct silent replies are explicitly allowed; native commands sent from direct chats do not borrow target-session silence.
• Why this is the smallest reliable guardrail: runPreparedReply is the seam that computes and forwards allowEmptyAssistantReplyAsSilent into the runner.
• Existing test that already covers this (if any): runner behavior for the flag itself is covered in src/agents/pi-embedded-runner/run.incomplete-turn.test.ts.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Operators who explicitly configure silentReply.direct: "allow" can now have clean empty or reasoning-only direct/dm model turns treated as intentional silence. Direct chats still disallow this by default.

Diagram (if applicable)

N/A

Security Impact (required)

• New permissions/capabilities? (Yes/No): No
• Secrets/tokens handling changed? (Yes/No): No
• New/changed network calls? (Yes/No): No
• Command/tool execution surface changed? (Yes/No): No
• Data access scope changed? (Yes/No): No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node/pnpm local checkout
• Model/provider: N/A
• Integration/channel (if any): direct/dm auto-reply runner
• Relevant config (redacted): agents.defaults.silentReply.direct = "allow"

Steps

1. Configure direct silent replies with silentReply.direct: "allow".
2. Run a direct/dm turn where the assistant produces no visible text or only reasoning.
3. Compare with a default direct/dm config and with a native direct command targeting a different session.

Expected

• Explicit direct allow treats clean empty/reasoning-only as intentional silence.
• Default direct config keeps empty-response retry/fallback behavior.
• Targeted native commands do not inherit target-session silence for direct requester delivery.

Actual

• Before this change, direct/dm runs never enabled empty-assistant silence because the flag was gated on isGroupChat.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: explicit direct/dm allow, default direct disallow, targeted native direct command guard, existing runner handling for empty/reasoning-only silence.
• Edge cases checked: group/channel behavior remains routed through resolveGroupSilentReplyBehavior; direct allow requires direct prompt-policy context.
• What you did not verify: live messaging-channel delivery.

Commands run:

pnpm docs:list
pnpm test src/auto-reply/reply/get-reply-run.media-only.test.ts src/agents/pi-embedded-runner/run.incomplete-turn.test.ts
pnpm exec oxfmt --check --threads=1 src/auto-reply/reply/get-reply-run.ts src/auto-reply/reply/get-reply-run.media-only.test.ts CHANGELOG.md docs/channels/groups.md
git diff --check
pnpm changed:lanes --json
pnpm check:changed
/Users/vyctor/.codex/skills/oss-pr-contributions/scripts/public_pr_preflight.sh /Users/vyctor/Documents/Codex/2026-04-29/quero-trabalhar-na-issue-74409-do/openclaw

codex review --base origin/main initially found one P2 around native direct commands targeting another session. That finding was fixed and covered with a regression test. A final retry completed successfully with no remaining findings.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No): Yes
• Config/env changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: direct chats could accidentally suppress empty failed turns.
  • Mitigation: the direct branch requires direct prompt-policy context plus explicit silentReply.direct: "allow"; defaults remain conservative and targeted native commands are covered.