claude-code - 💡(How to fix) Fix Pass suggestion-acceptance provenance to the model

Summary

Claude Code surfaces next-prompt suggestions as ghost text in the input area. When the user accepts one (Tab to fill the prompt, then Enter to send), the resulting message arrives in the model's conversation transcript indistinguishable from a prompt the user typed from scratch. The model then reasons about the suggestion's specific word choices as if the user authored them, biasing interpretation toward the suggestion's framing.

This isn't a bug — the suggest-accept-send loop works as designed. The design flaw is the absence of a provenance signal the model can read.

Concrete example

Mid-session, the assistant ended a turn discussing how to make a behavioural rule stick. Claude Code's UI showed a ghost-text next-prompt suggestion: "update your global instructions to make this clearer". The user pressed Tab to accept it, then Enter to send.

The model then:

1. Treated "global instructions" as the user's settled target and prepared to edit ~/.claude/CLAUDE.md.
2. The user interrupted: that wording wasn't theirs, they accepted a suggestion. They pointed out that a more appropriate target (a team-wide shared memory tier they maintain) had been overlooked because the model anchored on suggestion phrasing.
3. Even after the clarification, the model attributed "your phrasing" back to the user in a later reflection turn — compounding the bias.

The user's actual goal was "make the lesson stick"; the placement decision was downstream and should have been re-derived. The suggestion pre-loaded an answer that bypassed that derivation.

"But the user accepted it — isn't that intent?"

Anticipating the objection: yes, accepting via Tab is an affirmative act, and the user could in theory edit before sending. In practice the review is shallow — the user accepts the gist (which the suggestion is usually right about) without auditing every word choice for downstream interpretive weight. Specific phrasings that turn out to be load-bearing later (target file, scope, framing) aren't obviously load-bearing at accept-time. Once in the input, the suggested text is indistinguishable from typed text both visually (after acceptance) and to the receiving model.

The analogous case is GitHub Copilot inline suggestions: developers Tab-accept code constantly, and we don't treat every accepted token as if it carried the same authorial weight as hand-typed code. The same nuance is missing here, but worse — because the "accepted text" is then interpreted by a language model as evidence about user intent, not just compiled by a deterministic compiler.

Why it matters

• Suggestion phrasing arrives as evidence about user intent when it's actually model output recycled through the UI. This is a feedback loop that can drift a session in directions the user didn't choose.
• Word choices in accepted suggestions are particularly load-bearing — they look like deliberate user signals when in fact they're whatever the suggester happened to pick.
• The user can't easily mitigate without typing every prompt from scratch, which defeats the suggestion feature.
• Personal Claude rules ("don't trust suggestion phrasing") don't fix it — the model can't apply such a rule because it can't identify which prompts were accepted from suggestions.

The mechanism is also opaque to the receiving model: it doesn't know whether suggestions are generated by the same session's queued output, by a separate lightweight inference call, or by some heuristic. Either way the effect is the same.

Proposed fix

Pass a provenance signal the model can read. Options, weakest to strongest:

1. Transcript marker — insert a hidden tag or system-reminder on accepted-suggestion prompts (e.g. <source>suggestion</source> or a one-line "User accepted a Claude-generated suggestion via Tab."). Cheapest to implement; lets the model down-weight the wording without changing UX.
2. Structured metadata field — a source: "suggestion" | "typed" | "mixed" field on the message, accessible alongside existing system-reminder content. ("Mixed" covers the case where the user edits the suggestion before sending.)
3. Distinguishing render + signal — visually distinguish accepted-but-unedited suggestions in the input area so users notice what they've accepted, and pass provenance metadata to the model.

Option 1 is the lowest-friction landing; option 3 is the most user-honest.

Alternatives considered

• Drop suggestions entirely — removes the failure mode but kills a useful feature.
• Train the model to detect accepted prompts heuristically — unreliable; stylistic detection is brittle and would fail on close paraphrases.
• Tell users to retype suggestions in their own words — defeats the suggestion UX.

A provenance signal is cheapest, most reliable, and lets the model handle the bias explicitly rather than relying on stylometric guessing.