What shipped
Claude Code v2.1.247, released 26 August 2026, added a SendFeedback tool. Per Anthropic's own tools reference, when something goes wrong in a session, Claude can now draft a feedback report on its own, for you to review and send from /feedback, rather than you having to notice the problem, remember it, and manually write up a bug report afterward. A new feedbackDrafts setting controls how visible that drafting process is, down to turning it off entirely.
This is a small addition next to the same release's larger reliability fixes, but it changes something real about the feedback loop between users and Claude Code's own team: the report gets written closest to the moment the problem actually happened, by the model that was there when it happened.
Claude Code ships fast enough that this loop matters. Between v2.1.237 on 20 August 2026 and v2.1.247 on 26 August 2026, a single week, Anthropic shipped nine point releases carrying well over a hundred individually listed fixes between them, many of them the kind of narrow, session-specific bug a user would otherwise have to notice, remember, and separately go write up. SendFeedback is aimed squarely at that gap.
When Claude decides to draft feedback
Anthropic names four triggers explicitly:
- A tool or command keeps failing. Repeated failures on the same action are the clearest signal something is broken rather than a one-off.
- Claude cannot help with something you asked for. A capability gap it recognises in the moment.
- You point out a mistake it made, or it notices one itself. Either direction counts, being told, or catching its own error mid-task.
- You ask it to file feedback. The direct route, no different from asking for anything else.
None of these force a report to be sent. Drafting queues it for your review; nothing leaves your machine until you act on the draft.
What actually goes into a draft
A submitted report carries:
- Your title, area and details, whatever Claude wrote to describe the issue
- Environment info: your Claude Code version, operating system, and the model in use
- The IDs of recent API requests
- The conversation transcript, but only conditionally
The transcript is the one piece worth being precise about. It is included only if you leave Send transcript at yes on the review screen before sending. Sending directly from the card, without opening the full review screen, never includes it. Claude Code does keep your working directory in the local draft, purely so it can locate the transcript file if you do choose to send it, but the working directory path itself is never sent as part of the report.
Reviewing drafts through /feedback
/feedback opens the same dialog as /bug, with the same consent step, sending rules and mid-turn behaviour (running it while Claude is still responding opens the dialog immediately, a fix from v2.1.232). What differs is what happens when you run it with no argument in a session where Claude has already drafted something:
- With no argument, and a draft queued:
/feedbackopens the drafts queue instead of a blank dialog. From there you review, edit, send, or discard each drafted report, with an option to write a brand-new one from scratch if none of the drafts match what you want to report. - With an argument, or
/bugin any form: the dialog opens directly, as it always has.
Nothing is sent automatically. A draft is inert until you act on it from the queue.
How this differs from just running /bug yourself
/bug or /feedback <argument> | SendFeedback draft | |
|---|---|---|
| Who notices the problem | You | Claude, based on the four triggers above |
| When the report gets written | Whenever you remember to file it | The moment the trigger happens, while the details are fresh |
| What you do | Write the report from scratch | Review, edit, send, or discard what Claude already wrote |
| Where it appears | Opens the dialog immediately | Queues as a card, or a count in the footer under quiet |
The practical difference is timing. A report written by you after the fact depends on you remembering exactly what happened: the command that failed, the flags involved, what you expected instead. A drafted report captures that context at the moment Claude hit it, which matters most for the kind of narrow, easy-to-forget bug that shows up in Claude Code's own release notes: an escape sequence inserted into the prompt when a mouse report arrives split across reads, or a keybinding that stops working only under one terminal's specific keyboard protocol. Those are precisely the reports that are hardest to reconstruct from memory five minutes later, and easiest for Claude to describe accurately while it is still looking at the failure.
Controlling how visible drafting is: feedbackDrafts
The feedbackDrafts setting has three effective states:
| Value | Behaviour |
|---|---|
| Default (unset) | You see at most three review cards per session. Past that, only a running count of queued drafts appears in the prompt footer. |
quiet | Claude keeps drafting, but no cards appear at all, only the count in the footer. |
off | Drafting is disabled entirely. Set Claude-drafted feedback to off under /config. |
An equivalent environment variable turns it off without touching /config:
export CLAUDE_CODE_SEND_FEEDBACK=0
Administrators can set feedbackDrafts in managed settings, which takes precedence over whatever an individual sets for themselves. If your organisation wants this off across the board, that is the mechanism, not asking everyone to change their own /config.
Data retention
Feedback sent through SendFeedback follows the same retention policy as any report submitted through the ordinary /feedback dialog: Anthropic's data usage documentation states that transcripts shared this way may be used to improve Claude Code and are retained for five years. Nothing about the drafting mechanism changes that policy, it governs what you send once you send it, not how the draft was produced.
Where it does not work at all
SendFeedback is unavailable in several session types, and Claude Code does not fall back to a degraded version, the tool simply is not offered:
- Non-interactive
-pruns and Agent SDK sessions. There is no screen to review a queue. - Cloud sessions, including Claude Code on the web. The queue lives on your machine, and a cloud session cannot write to it.
- Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, or Microsoft Foundry.
- Sessions where
CLAUDE_CODE_SEND_FEEDBACK=0orDISABLE_FEEDBACK_COMMAND=1is set. - Sessions where
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICis set to any non-empty value. - Sessions with feature-flag fetching disabled.
- Organisations with Zero Data Retention policies.
If you have deliberately disabled telemetry or non-essential traffic for compliance reasons, this list is worth checking before assuming a missing SendFeedback card is a bug in itself, it is very likely one of these settings doing exactly what you asked it to.
A worked example
Say a Bash command keeps failing against a flaky internal service, and Claude has retried it three times without success. Instead of you having to stop, switch context, and manually describe what happened afterward, Claude may queue a draft on its own. At the end of the turn, if you are under the default three-card session limit, a review card appears summarising the failure. From there:
/feedback
with no argument opens the queue if more than one draft has accumulated, or the review screen directly if only one is pending. You can edit the title or details Claude wrote, decide whether to include the transcript, and send, or discard it if it turns out not to be worth reporting.
For teams and organisations
An administrator can set feedbackDrafts in managed settings, and that value takes precedence over anything a developer sets in their own /config or environment. This matters for two opposite reasons. An organisation that wants more visibility into what its developers are hitting might leave drafting on everywhere rather than relying on individuals to remember to file reports. An organisation with stricter data-handling requirements, one that has already turned off telemetry broadly, might want feedback drafting off across the fleet rather than trusting each developer's own /config state.
Either way, the setting is centrally enforceable the same way most other Claude Code behaviour is: through the same managed settings file that already controls permissions, autoMode, and the rest of a deployed configuration, rather than a separate feedback-specific admin surface.
Troubleshooting
I never see any feedback cards, even after obvious failures. Check /config for Claude-drafted feedback. If it reads off, or your organisation has set feedbackDrafts in managed settings, no drafting happens regardless of what triggers you hit. Also check for CLAUDE_CODE_SEND_FEEDBACK=0 in your environment.
Cards stopped appearing partway through a long session. That is expected under the default setting, which caps cards at three per session. Later drafts still queue, they just show only as a count in the prompt footer. Run /feedback with no argument to see everything that has accumulated.
I want drafting to keep happening but stop interrupting me with cards. Set feedbackDrafts to quiet. Claude keeps queuing drafts in the background, and you review them on your own schedule through /feedback.
SendFeedback is not available and I am not sure why. Check the session type first, it is not available in -p, SDK, or cloud sessions, or on Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, or Microsoft Foundry regardless of any setting. If none of those apply, check for CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC or a disabled feature-flag fetch, both of which turn it off silently.
I sent a report and I am not sure whether the transcript went with it. Check whether you sent it from the review screen with Send transcript left at yes, or directly from the card. Only the review-screen path with that option left on includes the transcript; sending from the card never does.
Why drafting is opt-out rather than opt-in
It is worth noting what Anthropic chose as the default here: drafting is on by default, capped at three visible cards per session, rather than off until you turn it on. That is a deliberate bet that most users would rather see an occasional review card for a real failure than have to remember feedbackDrafts exists before Claude can ever help file a report. If that default does not suit your workflow, particularly in a shared or observed environment where an unexpected review card mid-demo would be awkward, quiet mode keeps the underlying behaviour while removing the interruption, and off removes it entirely.
Where to go next
For the broader settings surface this sits inside, see Anthropic's own settings reference, and for what Claude Code sends and retains more generally, data usage. If you are weighing this alongside other ways Claude Code surfaces what happened in a session without you watching directly, what Claude Code's Monitor tool does covers reacting to external events, and get notified when another session goes idle covers reacting to another of your own sessions. Browse the current Claude Code catalogue at getclaudeskills.com/platforms/claude-code, or everything indexed at getclaudeskills.com/skills.
Verified 27 August 2026 directly against Claude Code's own tools reference at code.claude.com/docs/en/tools-reference, the commands reference for /feedback and /bug, and the v2.1.247 changelog entry at code.claude.com/docs/en/changelog.
