fix(claude): re-send a prompt the backend consumed without running it

[saucam]

Closes #326.

The bug

A zero-turn result with no <local-command-stderr> is the unexplained variant: the SDK reports subtype: "success", the model never ran, and nothing says why. The prompt was then simply lost — you retype it.

Error: The agent produced no turn — the prompt was consumed without running.
No cause was reported by the backend (check for a blocked slash-command expansion or rejected input).

Not #233 — and the error text already proves which is which

The provider prints the captured stderr when there is one, and falls back to "No cause was reported by the backend" only when it is null.

	Cause reported?	Handled by
#233 / claude-code#80223	yes — blocked skill-frontmatter expansion	#tryHandleSkillBlock parks for approval
This	no	nothing — prompt dropped

Evidence

Both occurrences in local transcripts share one signature — first prompt after a long idle gap, fresh system:init between prompt and error:

Session	Idle gap	Prompt → error	Between
6f59c413	12h 47m	1.81s	MCP ready, error 2ms later
cfe05fcd	59m 34s	1.99s	same

Reading: the loop went cold during the idle, the next send rebuilt it, and the first prompt into the rebuilt loop was swallowed.

Honest limit: why the loop goes cold is not established. codeoid does not tear it down on idle; the memory-index oscillation path is already fixed via #frozenMemoryIndex; the only systemPromptAppend changed logs on disk are from test runs, since provider lifecycle events go to stdout only. n=2.

Why the fix doesn't need that answer

It keys on num_turns === 0 — a typed field carrying correct data — so it recovers whatever produced the zero turn, and works whether or not #80223 is ever fixed.

Re-sending is safe because it is a zero-turn: no assistant turn ran, so no tool executed and there is no side effect to duplicate. That is exactly what separates this from a normal failed turn, which must never be silently repeated.

Scoped tightly:

• only when no stderr explains it — re-sending a real denial would just be denied again;
• once per turn, reset in runTurn() so each new prompt gets its own attempt rather than one per session;
• a visible info message, so the retry is never silent.

The machinery already existed (#lastPushedContent, #ensureQueryLoop, the re-push from #retryAfterGrant). #translateSDKMessage already intercepted the explained zero-turn; this adds the symmetric branch.

Tests

Five, in provider-claude.test.ts, driven through the existing mocked-SDK harness:

1. re-sends instead of surfacing an error
2. gives up after one attempt — a second zero-turn is a real error
3. leaves a normal multi-turn result alone
4. a zero-turn with a cause still surfaces that cause (not silently retried)
5. each new prompt gets its own single attempt

Confirmed to catch the regression — disabling the branch fails 3 of the 5.

Full suite: 2453 pass / 0 fail; typecheck and biome clean. One run showed 1 fail / 5 errors, which is a bun runner race (Cannot call describe() after the test run has completed) with the same signature as a baseline run taken before this change — not attributable here, and clean on re-run.

Follow-up (not in this PR)

Provider lifecycle events (rebuilding query loop, etc.) are stdout-only. Persisting them into the transcript would let the next occurrence diagnose itself instead of requiring transcript archaeology.

🤖 Generated with Claude Code

[highflame-oracle]

🔮 Oracle Review

🎯 Start Here

src/daemon/providers/claude/index.ts (~15 min) — Logic changes in index.ts

---

📋 PR Summary

What this PR does: fix(claude): re-send a prompt the backend consumed without running it

---

🔍 Code Review

Review completed.

Review Stats:

---

Generated by Oracle - Highflame's AI Code Reviewer