Task Guard’s NO_REPLY Bug Shows Why Agent Safety Instructions Need Exit Conditions

The uncomfortable thing about prompt-based safety is that the model keeps reading the prompt after the moment you meant it to apply. OpenClaw issue #95773 is a clean example: Task Guard tells the model that the final reply for the turn “must be and can only be NO_REPLY,” then later allows the task to proceed. Some models keep obeying the earlier instruction anyway. That is not model misbehavior. That is a state machine without an exit transition.

The issue reports that Task Guard’s pre_tool_silence mechanism injects an unconditional system-context mandate: The final reply for this turn must be and can only be NO_REPLY. The guard later calls task_guard_decide. If the decision is allow — the reported return is TASK_GUARD_DECISION_ALLOW: continue normally — the runtime stops injecting the silence instruction on later calls. But the original instruction is still visible in conversation history. Instruction-literal models may continue to follow it, produce reasoning-only turns, exhaust retries, and eventually hit 6902 unknown-empty-llm.

This is the sort of bug that looks narrow until you realize how many agent safety systems are built from sticky natural-language instructions.

Safety instructions need lifetimes

“Say NO_REPLY” is not inherently wrong. It is a reasonable tactic when a guard intercepts a tool call and the platform wants to suppress user-visible output until a policy decision is made. The problem is that the instruction has to say when it starts, what condition keeps it active, and what event cancels it. Without that lifecycle, silence becomes policy residue.

The proposed fix in #95773 is appropriately specific. First, make NO_REPLY conditional only when the tool call is actually intercepted or the tool result contains TASK_GUARD_INTERCEPTED / NO_REPLY. Second, append a lift marker to every allow path: [SILENCE_LIFTED] The pre-tool silence restriction has ended. You MUST now produce user-visible text. NO_REPLY is no longer required. That is not weakening the guardrail. It is completing it.

The reproduction described in the issue is telling: enable Task Guard with an instruction-compliant model, send a directory-wide scan request, observe task_guard_decide return allow, then watch the second LLM call produce reasoning-only output until retry exhaustion. The reporter verified the failure with a Xiaomi-hosted model and suggests DeepSeek, Qwen, and other strict-compliance models are likely exposed to the same pattern. Frontier models may infer the intended state shift. Literal models may not. A safety system that depends on inference is not portable.

This is where agent vendors need to be more honest about model diversity. Many runtimes are tuned against a small set of models that are forgiving, context-savvy, and trained to smooth over ambiguous developer intent. Then the same prompts get routed to regional providers, local models, open-weight models, enterprise-hosted variants, or cheaper fallback lanes. The safety prompt that “works fine” on Claude or GPT can deadlock on a model that follows the earlier instruction more literally. That is not an edge case anymore. It is the market.

Approval gates are state machines, not vibes

Task Guard sits in the broader category of approval and tool-boundary systems. These are becoming central to “safe coding agent workflow” claims: ask before destructive actions, intercept suspicious tool use, suppress output while a decision is pending, then resume or stop based on policy. The category is necessary. It is also easy to implement as a pile of English instructions and hope.

Hope does not scale across turns. Agents operate over multiple model calls, tool calls, retries, compactions, and sometimes child tasks. A policy instruction that is correct at call one can become wrong at call two. A denial instruction should not leak into an allow path. A silence instruction should not survive the moment it is lifted. An approval decision should carry at least as much prompt force as the restriction it supersedes. Otherwise, the system accumulates stale policy text until the model has to guess which sentence still wins.

Practitioners should audit their own guardrails with that lens. For every approval, silence, intercept, redirect, or deny instruction, ask four questions. What activates this instruction? What exact tool result or decision deactivates it? Is the deactivation visible to the model in the same context as the old restriction? Does the release instruction use clear, imperative language, or does it merely imply that normal behavior may resume? If the answers are not explicit, strict models will eventually turn ambiguity into a production bug.

The same-day OpenClaw safety work around outbound sanitization reinforces the point. PR #95774 adds Telegram outbound sanitization for internal tool-trace failure lines, following Google Chat PR #95084. PR #94545 fixes trusted policy lookup across composed hook registries. These are different surfaces — outbound messages, policy registry composition, pre-tool silence — but they all belong to the same control plane. Agent safety is not one refusal prompt. It is a set of scoped, ordered, inspectable runtime contracts.

What engineers should do now

If you operate OpenClaw with Task Guard, test allow-path behavior on the models you actually route to, not only on the default frontier model. Use tasks that trigger pre-tool review but should be allowed. Watch for empty replies, reasoning-only loops, retry exhaustion, or unexplained NO_REPLY outputs. If you use Qwen, DeepSeek, GLM, Xiaomi-hosted models, Ollama, or enterprise-hosted models with strict instruction following, prioritize this test.

If you build agent platforms, write guardrail tests like protocol tests. The system should prove that after allow, the model receives a clear resume instruction; after deny, it stops; after intercept, it does not leak visible output; after silence is lifted, it must produce user-visible text. Test with at least one instruction-literal model. If your safety design only passes on models that generously infer your intent, the design is under-specified.

The editorial read is simple: a NO_REPLY mandate without a cancellation path is not safer. It is a deadlock wearing a guardrail costume. Agent safety prompts need the same thing every state machine needs: transitions.

Sources: OpenClaw issue #95773, OpenClaw PR #94545, OpenClaw PR #95084, OpenClaw PR #95774