[FEATURE] Make "Attach selection as context" display configurable (inline vs chip) — counter to #60035

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

A recent update to the Claude Code desktop app changed how the right-click action "Attach selection as context" renders attached text. The selected content used to appear as inline quoted text in the message input box. It is now collapsed into a small badge/chip (a quote-mark icon) that hides the actual content until clicked.

This change appears to be a response to #60035, which asked for a discrete context block (primarily to fix a duplication bug where text was pasted twice, and to reduce visual clutter from inline > quoted lines). However, the resulting chip-only rendering appears to have overshot that request: a commenter on #60035 itself notes "they finally fixed it yesterday, but then they made it worse today because now it creates a link to the quote, so now I have to add verbal context to which quote I'm referencing" — confirming the chip-only display is unsatisfactory even for users who supported the original change. The underlying ask in #60035 was separation of prompt from attachment, not minimization of the attachment to a near-invisible icon.

With the previous inline rendering I could:

Verify what I attached at a glance, alongside the prompt I was typing
Edit the attached snippet inline before sending (trim irrelevant lines, reformat, annotate)
Scan multiple attachments quickly without clicking into each one
With the new chip rendering, none of the above is possible. To inspect content I must click each chip; to edit, I must re-attach from a fresh selection. For users who attach short code/log/document excerpts frequently, this is a meaningful loss in interaction speed.

The core gap is that both rendering styles have valid use cases and users currently have no way to choose. Even within #60035's own thread, the chip-only outcome is regarded as a step too far.

Related: #61861 accepts the chip rendering as the model but flags that individual chips cannot be removed — suggesting the chip implementation itself still needs UX work regardless of which rendering is the default.

<img width="245" height="156" alt="Image" src="https://github.com/user-attachments/assets/06c0d8c8-ed42-4ce7-b823-38274823a6f1" />

Proposed Solution

Make the attachment rendering style user-configurable so both #60035's preference and the prior inline behavior are supported. Options, in order of preference:

Add an explicit setting (e.g., contextAttachmentDisplay: "inline" | "chip") in settings.json or the desktop app's preferences pane. Default to "chip" if Anthropic prefers the new behavior — users who want the old one can opt in with one line of config.
Length-based auto-switch: render inline for selections under ~500 characters (where the content fits comfortably in the input box) and as a chip for longer selections. Satisfies most cases of both preferences with no setting required.
Show a text preview adjacent to the chip: at minimum, display the first ~80 characters of the attached selection next to the chip icon, so the attachment is identifiable without clicking.
Any one of these would unblock the regressed workflow. Option 1 is cleanest because it preserves both behaviors as first-class choices and resolves the underlying #60035 vs. this-request conflict via configuration rather than by toggling the default.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

_No response_