Filing a bug report against your coding agent has always been a chore that arrives at the worst possible moment: right after you've lost twenty minutes to something that shouldn't have broken, when the last thing you want is to open a template and reconstruct what happened. On August 27, 2026, @ClaudeDevs — Anthropic's developer-updates account on X — announced that Claude Code now does the reconstruction for you:
"Claude Code can now draft feedback for you. When something fails, when Claude notices it made a mistake, or when you tell it something went wrong, it writes up the report itself. You can review, modify and approve the feedback to send."
The post has drawn over 185,000 views, and the top reply is the only question that really matters to anyone on a usage-capped plan: "Does it drain my rate limit?" The second most common reaction is flat skepticism — "Theyre gonna ignore it anyways so have Claude make it easy for you." Both deserve straight answers.
This post is not a launch recap. It is a walkthrough of what actually happens on your machine when Claude queues a draft: where the file lands, what fields it fills in, what gets transmitted when you press send, and the exact setting that stops it. Everything below is verified against Anthropic's own tools reference and data usage docs, plus a local Claude Code v2.1.247 install on macOS.
TL;DR — the five questions people are actually asking
| Question | Answer |
|---|---|
| Does it send anything automatically? | No. Drafts are written to ~/.claude/feedback/drafts/ on your machine. The card gives you 1 to review, 2 twice to send, 0 to dismiss. Nothing transmits until you act. |
| Does it use my tokens or drain rate limits? | Barely. SendFeedback is a normal in-session tool call — you pay the tool definition plus a few hundred words of draft, capped at three drafts per session. No separate model call; sending runs zero inference. |
| What data is in the report? | Title, area, details, environment info (version, OS, model), recent API request IDs — and the transcript only if you leave Send transcript: yes on the review screen. Card-sends never include the transcript. |
| Can I turn it off? | Yes. /config → Claude-drafted feedback → off, which writes "feedbackDrafts": "off". Or CLAUDE_CODE_SEND_FEEDBACK=0 for one session. "quiet" keeps drafting without cards. |
| Does it work in non-interactive or CI runs? | No. The tool is omitted from -p runs, Agent SDK sessions, Claude Code on the web, and all Bedrock/Vertex/Foundry sessions. |
What the feature is actually called
Anthropic's docs name it Claude-drafted feedback, backed by a tool called SendFeedback. The tools reference gives the version gate precisely:
"Claude-drafted feedback is a feedback report about Claude Code that Claude writes for you. It requires Claude Code v2.1.238 or later. Claude Code saves each draft on your machine under
~/.claude/feedback/drafts/, and nothing reaches Anthropic until you send it."
Version 2.1.238 shipped on August 20, 2026 — a week before the announcement. Worth flagging honestly: the public changelog entries between 2.1.238 and 2.1.247 do not name this feature. The version gate comes from the tools reference page, not a release note, which means the tool was quietly present for several releases before the X post made it visible. That is the same pattern as the Concise output style, which landed in 2.1.237 one release earlier.
Checking a local install confirms it is live. On claude --version reporting 2.1.247, the binary carries the SendFeedback tool name, the feedbackDrafts setting key, the CLAUDE_CODE_SEND_FEEDBACK environment variable, and the feedback/drafts path — but on a machine that has never had a draft queued, ~/.claude/feedback/ does not exist at all. The directory is created on first draft, not at install. If you go looking and find nothing, that is the expected state, not a broken feature.
What triggers a draft
The announcement lists three cases. The tool's own instructions, readable in the shipped binary, expand them into four, and they are more specific than the marketing copy suggests:
| Trigger | What it looks like in practice |
|---|---|
| A tool or command keeps failing | "a reproducible tool or product failure was just resolved or abandoned" — the sandbox-pull loop from the announcement screenshot |
| You express frustration | "the user clearly expressed frustration with Claude Code or with how you handled the task" |
| A capability is missing | "you hit a missing capability that blocked a reasonable request" |
| Claude notices its own mistake | the largest category by far — see below |
That fourth category is the interesting one. Claude Code's tool prompt enumerates the self-reporting cases explicitly: "you gave a confident answer then had to retract it; you stopped short and handed work back when you could have finished; you declined or disputed a reasonable request; you spawned more subagents than the task warranted; your tone was off; you asked more clarifying questions than needed; you expanded scope beyond what was asked."
Read that list again. It is a near-exact catalogue of the complaints that drove why Claude Opus 5 feels worse to work with — over-clarification, premature stopping, scope creep, subagent over-spawning. Anthropic did not build a bug tracker here. It built a telemetry channel for model-behavior regressions, aimed squarely at the failure modes people have been complaining about on X for months but rarely bothered to file.
Two guardrails keep it from becoming spam. The tool is capped at three drafts per session by default (Anthropic can adjust the cap server-side without a release), and the prompt instructs: "Draft only at the natural moments listed above, and at most one draft per distinct issue; never re-draft the same issue in a session." When the cap is hit, the tool returns an error telling Claude not to call it again this session.
There is also a deliberate silence rule. The tool "renders no UI and does not interrupt the conversation, so never announce it or ask the user about it mid-task." Claude will not tell you it filed something. The card above your prompt is the only signal.
What's actually in the report
The announcement screenshot shows a stripped-down card — a title (Sandbox image pull fails behind proxy), a What happened line, and the 1 to review · 2 to send · 0 to dismiss footer. The real structure underneath is considerably more rigid.
The draft body
Claude is instructed to write details as short labeled bullets, in this exact order, one to three lines each, no narrative paragraphs:
| Bullet | What goes in it |
|---|---|
| What happened | Observed behavior vs. expected, with exact error text if short. Facts only. |
| What the user said | Your own words, quoted. If you said nothing, it must write "User didn't comment; observed by the model." |
| Repro | The minimal steps or shape that reproduces it. |
| Evidence | Chaseable identifiers — request IDs, timestamps, file paths, versions. Omitted if there are none. |
| Cause | Optional, and only for a root cause verified in-session. |
That is a better bug-report template than most humans write unprompted, which is precisely the point one reply made: "Good call, logging troubles was not super easy before."
The structured fields
Alongside the prose, each draft carries classification fields that never appear on the card. The report type is one of bug, idea, or missing_capability. The area names the part of Claude Code involved — the prompt's own examples are "hooks config", "/help", "file editing" — and is left blank when there is no clear one.
Then two enums that reveal what Anthropic is actually measuring. failure_mode is used only for model-behavior reports, never product bugs, and its values read like a taxonomy of agent-harness complaints: instruction_following, destructive_actions, code_quality, repetition_and_looping, model_regression, overconfidence_and_hallucination, context_and_memory, overeager, over_correction, stopping_short, dispute_or_decline, subagent_overspawn, tone_or_preachiness, excessive_questions, unwanted_scope, other.
task_category records what you were doing: code_edit, debug, explain, plan, shell, search, review, other.
If you have ever wondered whether "Claude spawned six subagents for a one-file change" is a thing Anthropic tracks — subagent_overspawn is a first-class enum value. So is repetition_and_looping, which is the failure mode that makes unattended Claude Code loops expensive when they go wrong.
What the local draft file holds
The queued draft record on disk carries draft_id, created_at, source_session_id, cwd, model, cli_version, os, and request_ids, plus a pointer to the transcript file. The docs are explicit that the working directory stays local: "Claude Code keeps your working directory in the local draft so it can find the transcript, and doesn't send the directory."
What actually crosses the wire when you send
Per Anthropic's tools reference, a sent report carries:
- Your title, area, and details
- Environment info — Claude Code version, operating system, and model
- The IDs of recent API requests
- The conversation transcript, only when you left Send transcript at
yeson the review screen
The critical asymmetry: "Sending from the card never includes the transcript." Pressing 2 twice is the low-exposure path — report text and environment metadata only. Opening the review queue with /feedback is where transcript sharing becomes possible, and there it defaults to yes when the transcript is still available. If you review drafts but don't want your session going with them, that toggle is the one to change.
Submissions route through the same path as /feedback, /bug, and /share — encrypted in transit, stored in Google Cloud Storage, and retained for five years. That retention window is much longer than the 30-day standard retention for commercial Claude Code data, because feedback is a separate submission path from ordinary session data. Worth internalizing before you send a transcript.
Does it drain my rate limit?
This was the top practical reply on the announcement, and the answer is: not meaningfully, but it is not literally free either.
SendFeedback is an ordinary tool in Claude's tool list, invoked mid-turn like Read or Bash. That means three real costs, all small:
- The tool definition sits in your context for every interactive session where it is enabled — a fixed overhead of a few hundred tokens, cached like the rest of the system prompt.
- The call itself costs output tokens — the draft body is a handful of labeled bullets, roughly the size of one modest file read, plus a tool-result round trip.
- The three-draft-per-session cap bounds the worst case. Even a session that goes badly wrong cannot produce more than three.
What it does not do is spin up a separate model invocation to write the report, and it does not bill against anything outside your normal session. Reviewing a draft in /feedback and sending it runs no inference at all — the review UI is local, and submission is a plain HTTPS upload.
The honest caveat: Anthropic has not published a token figure for the tool definition or a typical draft, so "a few hundred tokens" is an estimate from the observed draft structure, not a documented number. If you are running near your cap on Pro, the tool's context footprint is a rounding error next to your CLAUDE.md, your installed skills, and your MCP server definitions. Turning it off to save tokens is optimizing the wrong thing.
Should you trust it to report on itself?
The skeptical reply — "Theyre gonna ignore it anyways so have Claude make it easy for you" — is worth taking seriously rather than swatting away, because it names two separate doubts and only one of them is well-founded.
Doubt one: will Anthropic act on it? Nobody outside Anthropic can answer that. What is observable is that the feature is instrumented for triage, not for volume: failure_mode and task_category exist so reports can be bucketed and counted, and the whole system is gated to interactive first-party sessions where a human confirmed each one. That is the shape of a channel someone intends to read. It is not proof anyone will fix your issue.
Doubt two: is the model a reliable narrator of its own failure? This is the real problem, and the design concedes it. A model writing up its own mistake is an interested party. It can describe a symptom accurately while misattributing the cause; it can file a bug when the honest label is model_judgment; it can produce a fluent, well-formatted report about something that did not happen the way it says.
Anthropic's tool prompt fights this with hard constraints — "Never fabricate or exaggerate user sentiment; report only what actually happened," and "Everything in the draft must be sourced from the user or the session, never inferred: leave unknown fields blank rather than guess." Those are good rules. They are also instructions to a language model, which is a category of guarantee that has failed before.
The strongest evidence that Anthropic knows this: the submission is tagged with how much you reviewed it. Two distinct provenance strings ship in the binary — "Drafted by Claude via the SendFeedback tool; reviewed and approved by the user before sending" versus "...approved by the user from the above-prompt card without full review." Pressing 2 twice from the card marks your report as unreviewed. Whoever triages it can weight it accordingly.
Practical takeaway: press 1, not 2. A thirty-second read of a report you actually verify is worth more to Anthropic than three unreviewed ones, and it costs you nothing.
The privacy caveat worth knowing
The tool prompt contains a genuinely careful redaction rule:
"Do not include secrets or credentials. Refer to people by role ("a teammate", "the PR reviewer"), never by name, email address, or chat/user ID. This applies inside quoted user words too... Session, request, and run IDs, timestamps, repo/PR numbers, and file paths (written relative to the working directory, or ~-prefixed, not absolute paths under the user's home) remain the right evidence."
That rule exists for a reason. Issue #29121 on the Claude Code tracker, filed in February 2026 and since closed as stale, reported that when asked to draft a bug report for the public issue tracker, Claude Code included private organization names, repository URLs, internal file names, and infrastructure details — and the user had to intervene before submission.
That report predates SendFeedback and describes a different flow, so it is not evidence this feature leaks. But it is the exact failure mode the new prompt's redaction rules are written against, and prompt-level redaction is best-effort, not a filter. If you work in a repo where file paths and PR numbers are themselves sensitive, review before sending — and if your organization is on zero data retention, Claude Code omits the tool entirely.
How to turn it off or change it
Three levels of control, from softest to hardest.
Option 1 — quiet the cards, keep the drafting
The feedbackDrafts setting accepts three values. The shipped binary describes them exactly:
"notify"(default) shows a one-line notice when a draft is queued;"quiet"shows only the footer counter;"off"disables the tool entirely so drafts are never queued.
{
"feedbackDrafts": "quiet"
}
quiet is the setting most people actually want: Claude still writes reports when something breaks, you still find them later with /feedback, but nothing pops above your prompt mid-task. See the Claude Code settings.json reference for which file this belongs in — feedbackDrafts is scoped to user or managed settings, so it goes in ~/.claude/settings.json, not a project file.
Option 2 — turn it off completely
Via the UI, per the docs: "Set Claude-drafted feedback to off in /config." That writes:
{
"feedbackDrafts": "off"
}
For a single session without touching any file:
CLAUDE_CODE_SEND_FEEDBACK=0 claude
Broader switches also disable it as a side effect: DISABLE_FEEDBACK_COMMAND=1, or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC set to any non-empty value, which also kills metrics and session-quality surveys.
Option 3 — organization-wide
Administrators can pin feedbackDrafts in managed settings, which takes precedence over individual choices — the same precedence chain that governs permission modes and auto mode defaults. If you are on a locked-down deployment and the setting won't stick, check managed settings before filing a bug about it.
Working with the queue
/feedback with no argument opens the queue — every draft from every session, including ones whose cards you dismissed or never saw. From there you can edit the title, area, and details, flip Send transcript, then send, discard, or leave it. Pressing w opens the classic write-it-yourself dialog instead, which is also what /bug and /feedback <text> open directly. That is a real behavior change to the /feedback command worth noting if you have it in muscle memory — see the Claude Code commands reference for the rest of the slash-command surface.
Housekeeping rules: the queue holds 10 drafts across all sessions, and an eleventh evicts the oldest. A draft left in the queue expires after 30 days, or sooner if your cleanupPeriodDays is shorter. And if you run /exit with drafts still queued from that session, Claude Code asks whether to review or discard them first.
Where this leaves you
The feature is small, well-scoped, and genuinely useful — the kind of quality-of-life change that shows up in the same batch as the CPU idle fix and the Bun 1.4 runtime migration rather than in a keynote. One community member summed up the sighting well: "First time I see claude code draft its own bug report to anthropic after calling it out on a stupid move."
If you want the shortest possible decision: leave it on, set it to quiet if the cards annoy you, and when you do send one, spend thirty seconds pressing 1 first. The report goes out tagged as reviewed, the transcript question gets a deliberate answer instead of a default, and you have spent less effort than opening the issue template would have cost you.
Related reading
- Claude Code settings.json complete reference guide — where
feedbackDraftsbelongs and how scopes override each other - Claude Code commands complete reference guide — the full slash-command surface, including
/feedbackand/bug - Claude Code's Concise output style — the other
/configtoggle that shipped one release earlier - Why Claude Opus 5 feels worse to work with — the complaints the
failure_modeenum was built to capture - Claude Code permission modes explained — how managed settings override personal ones
- Anthropic's 30-day data retention and enterprise ZDR — why feedback's five-year window is different
- The official guide to Claude Code loops — where
repetition_and_loopingfailures get expensive - Claude Code auto mode becomes the default — the other recent default-behavior change worth auditing
- What are agent skills? Complete guide — the other thing competing for room in your context window
Official sources: Claude Code tools reference — SendFeedback tool behavior, Claude Code data usage, Claude Code settings reference, and @ClaudeDevs on X, August 27, 2026.
Behavior verified against Anthropic's published Claude Code documentation and a local Claude Code v2.1.247 install on macOS as of August 27, 2026. Card limits, draft caps, and the exact wording of settings can change between releases — and Anthropic states it can adjust the per-session card limit server-side without shipping a new version. Check /config and your installed version before relying on any specific number here.
