[BUG] Passive, auto-drafted feedback box can transmit private session content on a single keystroke — on by default, with no opt-in and no confirmation

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

## Summary

Claude Code ships a feedback mechanism — "Claude-drafted feedback" (the `SendFeedback` tool) — in which the model **silently authors feedback reports about the user's own session and queues them**, then surfaces a box offering to transmit them. This behavior is **on by default**, was introduced **with no opt-in and no announcement** (at least not within the tool where it would be visible), and the transmit action is **bound to a bare number key** (`2 to send`) that collides with ordinary numeric input, with **no meaningful confirmation step anywhere in the flow** — the `1 to review` path is likewise a single keystroke and submits with another, so it interposes no real barrier. The payload is **private session-derived content** — the report body (which in practice quotes the user verbatim and embeds branch/PR/commit identifiers, file paths, and API request IDs) and, per the draft's review-screen choice, the **full session transcript including source code**. Sent reports are **retained for 5 years** and **may be posted as a public GitHub issue**.

Gating an irreversible transmission of private material behind a single mis-hittable keystroke — from a surface the user never asked to appear — is a serious safety-design defect, not a UX rough edge.

## Severity

This is a data-protection failure, not a usability issue. As delivered, Claude Code **enables by default** a mechanism that can transmit a user's private session content off their machine — source code, verbatim conversation, working paths, and API request identifiers — with **5-year retention** and the option of becoming a **public GitHub issue**, and it does so **without the user ever opting in**, behind **collision-prone single keystrokes** rather than any real confirmation. For the large share of users working in confidential or regulated codebases, this is direct exposure of material they are obligated to protect, arising from software behaving exactly as designed.

A defect of this class — private-data egress on by default, no consent, and no meaningful barrier before send — reaching a shipped product is not a missed edge case. It indicates a gap in privacy-by-design and in pre-release review that should have caught it, and it warrants being treated with corresponding seriousness and priority rather than as a UX enhancement request.

## What's wrong, precisely

1. **The mechanism is passive.** Unlike `/feedback`, `/bug`, and `/share`, which the user types deliberately, the Claude-drafted feedback box **appears on its own**. The user performs no act of intent to initiate it. It is the only content-bearing feedback surface that is not opt-in by action.

2. **On by default, no opt-in, no introduction.** Per the [data-usage docs](https://code.claude.com/docs/en/data-usage), the only control is an **opt-out** environment variable (`DISABLE_FEEDBACK_COMMAND=1`). A feature that silently drafts reports about a user's private session, quoting them, should not be enabled until the user has been told it exists and has agreed to it. It was shipped the opposite way.

3. **There is no meaningful confirmation barrier at any step — every action is a single bare-number keystroke.** The box offers `1 to review · 2 to send · 0 to dismiss`; each option is one number key, and those are exactly the keys the user presses to answer Claude's own numbered prompts and to type into the conversation. There are, in effect, **two accidental-submission paths, both on ordinary keystrokes**: `2` commits the send immediately, and `1 to review` leads to a screen from which submission is again only a keystroke away. So this is not even a single-key hazard with one guarded path — it is *two* likely-keystroke routes to transmitting private content, and the `review` option interposes no genuine barrier; it merely adds another single keystroke to the chain. A sequence of consecutive single keystrokes is not a confirmation step — it *raises* the probability that a user fat-fingers the report all the way to transmission. Nowhere between a stray keypress and irreversible transmission of private content is there a real friction step (e.g. an explicit typed confirmation, or a non-numeric affirmative that cannot be hit by accident). (This is the same keybinding-collision class repeatedly reported against the rating widget and closed `not_planned`: #10126, #38833, #64981, #73983, #75193 — here with a private-content payload rather than a rating.)

*(Note: I did not verify the review screen's exact key handling by pressing through it, because doing so risks triggering the very send at issue. This point does not depend on that — it rests on the box's own labeling, where every option including "review" is a single number key, and on the fact that adding more single-keystroke steps is not a barrier.)*

4. **The payload is private and the exposure is durable and potentially public.** Per the docs, a sent report goes "through the same submission path and retention as other `/feedback` reports": conversation history including code, stored in Google Cloud Storage, **retained for 5 years**, and **optionally turned into a public GitHub issue**. Observed locally: queued drafts under `~/.claude/feedback/drafts/` contain the user's verbatim quoted words, working directory, `source_session_id`, API `request_ids`, and a `transcript_ref` pointing at the full session `.jsonl`.

## Why this is dangerous and reckless

- The user is given the *risk* of transmitting private, long-retained, potentially-public data **without ever opting into the feature that creates that risk**.
- The barrier between "nothing sent" and "private content sent, 5-year retention, possibly public" is **one keypress on a key used constantly for other purposes**, with **no confirmation**.
- The population most exposed — people using Claude Code inside real, confidential codebases and infrastructure — is not an edge case; it is the core user base.
- The identical keybinding-collision failure was raised many times on the rating widget and dismissed. Carrying that same design onto a **private-content-bearing, passively-activated** surface converts a dismissible annoyance into a data-exposure hazard.

### What Should Happen?

1. **This must be an explicit, informed opt-in. A confirmation or "friction" step is not an acceptable substitute.** Given the gravity — irreversible transmission of private session content, 5-year retention, possible public GitHub issue — the passive drafting and the armed *send* affordance must not exist unless the user has knowingly turned the feature on. Off by default: **no reports drafted, nothing queued, and no send affordance surfaced at all, until the user opts in.** Layering a confirmation step onto a feature that is on by default and was never agreed to does **not** fix the core defect: the user is exposed to the risk without ever consenting to it. As shipped, this is a footgun regardless of how many keystrokes guard the trigger.
2. **Even after opt-in, do not bind transmission to bare number keys.** As noted above, the box currently exposes *two* accidental-submission paths on ordinary keystrokes (`2` submits immediately; `1` review submits with another keystroke). Any send must require an explicit action that cannot be hit by accident and does not share keybindings with conversation input or numbered prompts. An intermediate single-key "review" screen is not such a barrier.
3. **Disclose at the point of send exactly what will leave the machine** — whether the transcript is included and which sessions, that request IDs are attached, the 5-year retention, and that it may become a public GitHub issue — before anything is transmitted.
4. **Announce the feature and its data behavior** in release notes and first-run, rather than shipping silent drafting on by default.
5. Ensure `DISABLE_FEEDBACK_COMMAND=1` is honored consistently across all surfaces (cf. #91508) — though with opt-in defaults, an opt-out flag should not be the only line of defense.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

1. Use Claude Code normally in a real project.
2. Observe that, without invoking any command, a feedback box appears offering `1 to review · 2 to send · 0 to dismiss`, referencing a report the model drafted about the session.
3. Note there is no prior opt-in for this drafting behavior, and no confirmation step between `2` and transmission.
4. Inspect `~/.claude/feedback/drafts/*.json` to see that queued drafts contain verbatim user content, request IDs, and a pointer to the full session transcript.

### Claude Model

Opus

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

2.1.263 (Claude Code)

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

iTerm2

### Additional Information

## Preflight / prior-art search

Before filing, I searched the tracker specifically for this concern — the *passive, self-appearing* Claude-drafted feedback box and the risk of it transmitting private content on an accidental keypress. **There is no existing issue covering this.** The nearest results are not about it:

- #90261 asks only for hint text on the auto-generated box (a discoverability nicety) — it does not touch private-data exposure or accidental send.
- #90631 is about `SendFeedback` being *absent* in desktop sessions (availability, not risk).
- Every accidental-send report I found (#64465, #10126, #38833, #75193, #73983, #64981) is against the low-stakes **rating widget**, which transmits only a rating and no transcript.
- Every complaint about content-bearing feedback (#89874, #89130, #91508, #92519) is about the **explicitly user-actuated** `/feedback`, `/bug`, `/share` path.

No existing issue sits at the intersection this report is about: **passive activation + private-content exposure + single-keystroke send.**

## References

- Data usage: https://code.claude.com/docs/en/data-usage (feedback path, 5-year retention, Google Cloud Storage, optional public GitHub issue, `DISABLE_FEEDBACK_COMMAND`)
- Related but distinct: #90261, #90631, #89874, #89130, #91508, #92519; keybinding-collision precedents closed `not_planned`: #10126, #38833, #64981, #73983, #75193.

Start by tracing the SendFeedback tool and the auto-appearing feedback box, then inspect the queued drafts under ~/.claude/feedback/drafts/*.json and the DISABLE_FEEDBACK_COMMAND handling. Done means drafting and sending are off until explicit opt-in, bare-number submission is removed, the data sent is disclosed, and the opt-out setting works across all surfaces.

Escrito por el modelo de indexación a partir del texto del issue.