fix(chat): suppress reserved SILENT control turns at ingress

[allenliang2022]

Problem

Cron agents use the exact final response [SILENT] as a delivery-suppression sentinel. The scheduler correctly recognizes it and logs agent returned [SILENT] — skipping delivery.

However, if an external wake relay accidentally POSTs that sentinel to /api/chat/start, WebUI currently treats it as ordinary conversation content. If 8701 restarts while that turn is pending, session recovery materializes the pending value as:

{"role": "user", "content": "[SILENT]", "_recovered": true}

That creates a visible user turn. Because the value also lives in pending_user_message, later restarts can recover it again, producing repeated [SILENT] user/assistant pairs even though the cron scheduler itself suppressed delivery correctly.

I confirmed the provenance in a real affected sidecar: the leaked rows carry _recovered: true, while the sidecar retains pending_user_message: "[SILENT]". The cron log for the same job says skipping delivery, ruling out the scheduler's normal delivery path.

Fix

Treat the exact normalized sentinel as a successful no-op at both server-side turn entry points:

• HTTP /api/chat/start (_handle_chat_start)
• in-process start_session_turn

Both checks run before session lookup, runtime barriers, or any pending/session mutation. They return status 200 with:

{"status": "suppressed", "reason": "silent_control_message"}

Matching is deliberately exact and case-sensitive. Only [SILENT] (allowing surrounding whitespace) is suppressed; [silent], prose containing [SILENT], and ordinary user messages remain untouched.

Verification

Added tests/test_silent_control_suppression.py covering:

1. HTTP chat-start returns 200 without session lookup.
2. In-process start returns 200 without session lookup.
3. Whitespace normalization.
4. Negative cases for lowercase, prose containing the token, empty text, and None.

The new suite fails 3/3 before the fix. After the fix, the new tests plus neighboring chat-start/runtime-adapter and compression-recovery suites pass:

21 passed in 7.95s

I also rebased the branch onto current origin/master after initially discovering that my local worktree was based on an unrelated rolling branch; the final PR diff contains only api/routes.py and the new regression test.

Scope

This prevents future sentinel turns at ingress. It intentionally does not rewrite already-persisted transcript history; existing recovered rows remain historical evidence rather than being destructively removed during an upgrade.

[greptile-apps]

Greptile Summary

The PR prevents the exact normalized [SILENT] control value from becoming a persisted conversation turn.

• Adds early suppression to HTTP and in-process chat-start entry points.
• Returns an explicit successful no-op response without session lookup or mutation.
• Adds regression coverage for normalization and nonmatching values.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
api/routes.py	Adds exact, case-sensitive sentinel recognition and early successful suppression at both targeted turn-entry functions.
tests/test_silent_control_suppression.py	Verifies both suppression paths, whitespace normalization, response shapes, and representative negative cases.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Incoming chat-start message] --> B{Exact normalized SILENT sentinel?}
  B -->|Yes| C[Return 200 suppressed]
  C --> D[No session lookup or mutation]
  B -->|No| E[Continue normal turn admission]

Loading

_{Reviews (2): Last reviewed commit: "Merge branch 'master' into fix/suppress-..." | Re-trigger Greptile}

[nesquena-hermes]

Gate-clean. Suppresses the reserved [SILENT] cron delivery-suppression sentinel at both chat-ingress entry points (start_session_turn + _handle_chat_start) before session lookup/pending-state mutation, so an errant wake relay POSTing [SILENT] can't materialize a phantom recovered user turn on restart. Codex SAFE TO SHIP (verified: both guards pre-mutation, exact whitespace-normalized case-sensitive match so normal messages unaffected, both response conventions terminate without double-write, cron.scheduler.SILENT_MARKER='[SILENT]' confirms the literal). Local full suite 14540/0 + 9 focused ingress tests. Non-blocking follow-up: /api/goal (routes.py:22640) has the same pre-existing exposure — will file a follow-up for class-wide suppression (out of scope for this relay-path fix). Shipping to experimental.

[nesquena-hermes]

Shipped in exp-v0.52.222. Thanks @allenliang2022 — clean, well-scoped fix. Verified via the full Codex gate (both guards suppress before session lookup / pending-state mutation, matching is exact + whitespace-normalized + case-sensitive so ordinary messages are unaffected, both response conventions terminate without double-write, and cron.scheduler.SILENT_MARKER='[SILENT]' confirms the literal) and the full test suite. Filed #7019 as a follow-up to extend the same guard to the /api/goal ingress path (a pre-existing sibling exposure the gate surfaced — out of scope for this relay-path fix).