Summary
In the bundled get-reply-eY9NJdyX.js (source src/auto-reply/.../get-reply.ts), allowEmptyAssistantReplyAsSilent is gated behind isGroupChat &&, which makes it impossible to honor silentReplyPolicy: "allow" on direct (DM) chats. Empty/silent-token replies on direct chats always trigger the empty-response retry → fallback chain, even when configured to be allowed.
Repro
openclaw 2026.4.26. With:
"agents": {
"defaults": {
"silentReply": { "direct": "allow" }
}
}
Send a heartbeat-style ping to a direct DM where the model would correctly respond with NO_REPLY. Observed: harness logs empty response detected → retrying with visible-answer continuation → empty response retries exhausted → incomplete turn detected stopReason=stop payloads=0 → surfacing error to user. Expected: silent absorption, since policy is "allow".
Code reference
plugin-runtime-deps/openclaw-2026.4.26-*/dist/get-reply-eY9NJdyX.js line ~2029:
const allowEmptyAssistantReplyAsSilent = isGroupChat && resolveGroupSilentReplyBehavior({
sessionEntry,
defaultActivation,
silentReplyPolicy: silentReplySettings.policy,
silentReplyRewrite: silentReplySettings.rewrite
}).allowEmptyAssistantReplyAsSilent;
The isGroupChat && short-circuit means direct chats always get false regardless of policy.
Suggested fix
Drop the isGroupChat && guard. The resolveGroupSilentReplyBehavior call's return value already encodes silentReplyPolicy === "allow" correctly (see silent-reply-Btab7kqB.js:618). The function name is a misnomer — it works for any conversation type once you let it run.
const allowEmptyAssistantReplyAsSilent = resolveGroupSilentReplyBehavior({...}).allowEmptyAssistantReplyAsSilent;
(Confirmed locally — patched the bundled JS, silentReply policy is now respected on direct chats.)
Related issues
May share root cause / overlap with:
Summary
In the bundled
get-reply-eY9NJdyX.js(sourcesrc/auto-reply/.../get-reply.ts),allowEmptyAssistantReplyAsSilentis gated behindisGroupChat &&, which makes it impossible to honorsilentReplyPolicy: "allow"on direct (DM) chats. Empty/silent-token replies on direct chats always trigger the empty-response retry → fallback chain, even when configured to be allowed.Repro
openclaw 2026.4.26. With:Send a heartbeat-style ping to a direct DM where the model would correctly respond with
NO_REPLY. Observed: harness logsempty response detected → retrying with visible-answer continuation → empty response retries exhausted → incomplete turn detected stopReason=stop payloads=0 → surfacing error to user. Expected: silent absorption, since policy is"allow".Code reference
plugin-runtime-deps/openclaw-2026.4.26-*/dist/get-reply-eY9NJdyX.jsline ~2029:The
isGroupChat &&short-circuit means direct chats always getfalseregardless of policy.Suggested fix
Drop the
isGroupChat &&guard. TheresolveGroupSilentReplyBehaviorcall's return value already encodessilentReplyPolicy === "allow"correctly (seesilent-reply-Btab7kqB.js:618). The function name is a misnomer — it works for any conversation type once you let it run.(Confirmed locally — patched the bundled JS,
silentReplypolicy is now respected on direct chats.)Related issues
May share root cause / overlap with: