← task board · runs · Qwen 3.6 27B · pi + subagents

regex-log — tool call emitted INSIDE thinking in raw chat-template syntax; session ends on an empty message at turn 3

FAIL in fast__qwen3.6-27b__20260708-153432 (56Avdhy, 5m22s agent, reward 0). A canary-grade regression: regex-log passes almost every run (27b solved it in ~10m31s on 07-03 and 6m14s/PASS in the 35b strip-off arm the same day). The task was left UNTOUCHED — /app/regex.txt never written, verifier fails on exists() in 0.04s.

What happened — 3 turns, then a silent quit

  1. ls -la /app/ → empty dir (NORMAL for this task: the Dockerfile is bare ubuntu:24.04, the deliverable is writing /app/regex.txt).
  2. python3 --version → command not found (also normal: ubuntu:24.04 ships no python3).
  3. Final message: stopReason=stop, 38 output tokens, ZERO visible text, ZERO tool calls — but its thinking block contains, verbatim:

<tool_call> <function=bash> <parameter=command> which python || which python3 || ls /usr/bin/python* </parameter> </function> </tool_call>

The model emitted its next tool call in qwen's RAW chat-template syntax inside the thinking channel. The server's template parser never extracted it (it lives in reasoning content), pi received an assistant message with no toolCall and no text, and print mode ended the session. Turn 3, task dead.

Why no mechanism fired

This is the e2e case-stability lesson #4 shape ("fake text tool calls") in a new, WORSE position: not plain text but THINKING, so even a text-based detector would miss it. Nothing in the harness covers an empty final message: the runaway recovery needs >8000 chars of no-toolCall TEXT (this had 0), the loop guard needs repeated calls (none), the write guard needs stopReason=length, and the subagent turn-6 fallback nudge needs 6 assistant turns (died at 3). The 148–162s per trivial turn is just dense-27b thinking (~5k thinking tokens/turn), not a hang.

Proposed fix (ledger item)

Tier-1 detector in the extension's message_end hook, same followUp-nudge pattern as the runaway recovery: assistant message with NO toolCall and (near-)zero visible text ending a session is never a legitimate final answer — nudge once: "your last message contained no answer and no tool call; if you meant to run a command, make a genuine tool call using the tool-call mechanism, not text or markup." A thinking tail containing literal <tool_call> markup is a bonus high-precision trigger, but the empty-message predicate alone would have saved this trial. Cap like the recovery (2/session) so a hopeless case still terminates.

Verdict attribution

Model/template failure (tool-call format degeneration into the reasoning channel), single occurrence so far — but it beached a canary task at turn 3, and the predicate to catch it is cheap and external-ground-truth. Not related to the 2026-07-08 mechanisms: zero subagent calls, zero loop-guard blocks, zero child timeouts, no nudges delivered before death.