[BUG] Dispatch agent outputs plain text instead of calling SendUserMessage — responses invisible to user

Description

Dispatch agent consistently outputs plain text responses instead of calling SendUserMessage, making all responses invisible to the user. The Dispatch UI shows "Read" but no reply appears.

The system prompt explicitly states: "The ONLY way to communicate with the user is the SendUserMessage tool. Plain text assistant replies are not rendered." Despite this, the model generates plain text and calls end_turn without ever invoking SendUserMessage.

Environment

• OS: Windows 11 Home 10.0.26200
• Claude Desktop: 1.1.9310.0 (MSIX/Microsoft Store)
• Claude Code SDK: 2.1.85
• Plan: Max (Claude Opus 4.6, 1M context)

Evidence from logs

Audit log shows text output, not SendUserMessage

{
  "type": "result",
  "subtype": "success",
  "is_error": false,
  "duration_ms": 3758,
  "num_turns": 1,
  "result": "\n\nHey! Anything I can help with today?",
  "stop_reason": "end_turn",
  "output_tokens": 15
}

The agent generated 15 tokens of plain text and stopped. It never attempted to call SendUserMessage. The user sees "Read" with no visible reply.

Statistics across 25 turns

• SendUserMessage called: 6 times (24%)
• Plain text responses (invisible): 38 times (76%)
• The agent does real work (runs PowerShell, starts PM2 processes) but reports results via invisible text

VM log confirms successful spawn

Spawn succeeded in 68ms
...kill called with signal: SIGTERM
Exited, code=0, signal=null, duration=917ms

The VM starts, the agent runs, but outputs text instead of SendUserMessage.

Additional issue: CoworkVMService crashes repeatedly

The CoworkVMService Windows service crashes after agent turns complete, leaving stale Hyper-V containers (HCS error 0xC0370103 — HCS_E_SYSTEM_ALREADY_EXISTS) that block subsequent VM startups. The service reports as "Running" but the VM fails with "VM service not running. The service failed to start."

Steps to reproduce

1. Open Claude Desktop on Windows (1.1.9310.0)
2. Go to Code tab > Dispatch
3. Send "hello"
4. Observe: message shows "Read" but no reply appears
5. Check audit.jsonl: agent responded with plain text, not SendUserMessage

What was tried (none fixed it)

• SDK rollback from 2.1.85 to 2.1.78 (same behavior)
• Deleting conversation JSONL (fresh start, same behavior)
• Adding memory files instructing agent to use SendUserMessage (ignored)
• Adding CLAUDE.md files (not mounted inside VM)
• Generating fake conversation history with SendUserMessage examples (works for ~1 turn then degrades)
• Background JSONL cleaner daemon converting text to SendUserMessage (only affects disk, not in-memory conversation)
• Restarting CoworkVMService and vmcompute (temporarily fixes VM crashes but they recur)

System prompt analysis

The Dispatch system prompt (extracted from app.asar) contains clear instructions:

"You are the Dispatch orchestrator. The ONLY way to communicate with the user is the SendUserMessage tool. Plain text assistant replies are not rendered — the user will never see them. Everything you want the user to read (greetings, acknowledgments, clarifying questions, status updates, results, errors) MUST be a SendUserMessage call. If you are about to emit plain text, stop and call SendUserMessage instead."

The model ignores this instruction approximately 76% of the time.

Suggested fix

Consider enforcing SendUserMessage via tool_choice at the API level rather than relying on system prompt instructions. The model clearly understands the tool exists (it calls it 24% of the time) but defaults to text output for simple responses.