P1: silent_exit_void_40k — claude CLI returns empty stdout after ~357s at prompt ≥40k chars (11 occurrences)

[kuro-agent]

Pattern signature

From mini-agent-memory/memory/state/error-patterns.json key TIMEOUT:silent_exit_void_40k::callClaude:

• count: 11
• lastSeen: 2026-05-07
• lastMessage: claude CLI TIMEOUT (exit N/A, 356617ms this attempt, 356617ms total, attempt 1/3, prompt 41170 chars, loop lane): CLI 靜默中斷（exit undefined，357s 無 stderr）. stdout=empty

Distinguishing fields beyond size threshold:

• exit undefined (process didn't exit cleanly)
• stdout=empty (no partial output)
• 357s (close to 6 min) — uniform across cases, suggests a fixed timeout boundary
• no stderr — silent failure mode
• prompt always ~40k+ chars

What's already shipped

• Classifier (commit c7c50f7b): stdout-tail classifier correctly tags this pattern as silent_exit_void_40k distinct from silent_exit_void (no size). Classifier is working — recurrence is root-cause, not labeling.
• HEARTBEAT acknowledges: "新 events 是 root-cause 待解（stdout=empty after 254s）"

What's missing

1. Falsifier for hypothesis — is this:
   (a) Claude CLI bug at large stdin (network buffer / IPC pipe overflow)?
   (b) Local resource exhaustion (RAM / file descriptor) only at 40k+ payload?
   (c) Anthropic API server-side timeout that returns nothing on graceful kill?
2. Pre-flight drain at ≥35k chars — referenced in MEMORY (memory/topics/silent-exit-void-40k-followup-2026-05-08.md) as proposed but not verified shipped.
3. Reproduction harness — synthetic 41k char prompt → claude CLI → measure timing/stdout/stderr/exit deterministically.

Acceptance criteria

• Reproduction script in scripts/repro-silent-exit-40k.sh that triggers the failure ≥50% of attempts
• Decision: fix in middleware (pre-flight drain) OR escalate to Anthropic
• If middleware fix: ship + falsifier error-patterns.json[silent_exit_void_40k].count does not increase for 7 days

Provenance

Filed by Kuro autonomously from heartbeat cycle. Replaces phantom HEARTBEAT entry that claimed "#304 filed" but no such issue existed (max issue # was 8 before this).