/feedback missed a queued draft on first invocation and the draft was lost (a later invocation worked)

Corrected 2026-09-03, shortly after filing. The original report claimed /feedback does not find queued drafts and deletes them. That was generalized from a single observation and is too strong. A later /feedback in the same session did display a queued draft and handled it correctly. The real behavior is intermittent, and is described accurately below. See the correction comment for what changed.

Environment

• Claude Code 2.1.258, linux x64
• First-party OAuth (claudeAiOauth in ~/.claude/.credentials.json). No custom gateway: ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_API_KEY, CLAUDE_CODE_USE_BEDROCK and CLAUDE_CODE_USE_VERTEX all unset; every settings.json has an empty env block.

Related but distinct: #89973 covers drafts being un-sendable under custom-gateway auth, where the client legitimately lacks first-party credentials. This is first-party auth, /feedback works on a later invocation, and a draft was lost.

What happened

Timestamps are from the filesystem, single session:

| Time | Event | Observed |
|---|---|---|
| 02:22:43 | SendFeedback call #1 | ~/.claude/feedback/ created; draft written |
| ~02:28 | /feedback run #1 | reported no feedback queued, printed no content — and the draft file was gone afterward (drafts dir empty, mtime 02:28) |
| 02:30:08 | SendFeedback call #2 | draft written; confirmed present on disk immediately after, "status": "queued" |
| 02:35:12 | /feedback run #2 | worked — draft displayed; user discarded it; file removed, which is correct |

So SendFeedback writes drafts correctly every time, and /feedback displays them sometimes. The failing case is the first invocation, and it cost a draft.

The draft JSON is complete when written — "status": "queued" plus request_ids, transcript_ref, cli_version, source_session_id, message_count. Nothing about the file explains why the first read missed it.

The part that matters

Whatever causes the first invocation to miss the draft, the draft should not be removed by a read that reported finding nothing. A draft that was never displayed to the user, never sent, and never explicitly dismissed was deleted. That is the difference between "retry the command" and "the content is gone."

Speculation, clearly labeled

I only have timestamps, not internals. One shape that would fit: the drafts list is snapshotted at session start, so a draft created mid-session isn't visible to the first /feedback in that session; the empty list is then written back, removing the file; and the second draft is visible because the first invocation refreshed the list. I have not verified any of that and it may be entirely wrong.

Reproduce

Uncertain, since it did not reproduce on the second attempt. What I can state:

1. Fresh session, first-party auth. Get the model to call SendFeedback.
2. ls -la ~/.claude/feedback/drafts/ — JSON file present, "status": "queued".
3. Run /feedback for the first time in that session.
4. In this instance: reported nothing queued, and step 2's file was gone afterward. A second SendFeedback + /feedback in the same session then behaved correctly.

If the first-invocation-in-a-session detail is the trigger, that would explain why this is easy to miss.

Expected

1. /feedback finds drafts that exist on disk, on the first invocation as on any other.
2. Failing that, never delete a draft that was not displayed, sent, or dismissed by the user.

Why this is worth fixing beyond the lost file

SendFeedback returns "the user can review and send it with /feedback." When that path silently fails, the model tells the user the report is filed, the user sees an empty queue, and the draft is destroyed — so the model states something untrue in good faith and nothing reaches Anthropic. That is exactly what happened here: the underlying browser-automation report had to be recovered by reading the JSON off disk and was ultimately filed by hand as a comment on #77670.