[BUG] DX regression: Declining edit clears proposed patch and shows “(No changes)”

Environment

• Platform (select one):
• [ ] Anthropic API
• [ ] AWS Bedrock
• [ ] Google Vertex AI
• [x] Other: Claude CLI “code” local edit flow (filesystem edits in terminal)
• Claude CLI version: 1.0.96 (Claude Code)
• Operating System: Ubuntu 20.04
• Terminal: zsh

Bug Description

Selecting “No, and tell Claude what to do differently (esc)” at the interactive “Do you want to make this edit?” prompt causes the CLI to discard the proposed patch content from the terminal output and replace it with the literal string “(No changes)” in the update summary. This is a DX regression: previous behavior left the full proposed diff/code visible so engineers could annotate specific lines and give actionable feedback without accepting the edit.

This change makes it hard to reference the proposal, compare alternatives, or copy parts of it into a revised instruction. It forces devs to “remember” the patch or to accept/undo just to see it again.

Steps to Reproduce

1. Use Claude CLI to request an edit that produces a patch (e.g., modify duplicate-detection-modal.component.ts and related template).
2. When prompted:

Do you want to make this edit to <file>?

1. Yes
2. Yes, allow all edits during this session (shift+tab)
3. No, and tell Claude what to do differently (esc)

choose 3. No, and tell Claude what to do differently (esc).

1. Observe the CLI output for the file update summary.

Expected Behavior

• The proposed patch/diff remains visible in the terminal (or is otherwise accessible) after selecting No, so the engineer can:
• Quote exact lines in follow-up instructions,
• Copy/paste snippets,
• Point to specific hunks when explaining what should change,
• Compare with local code before approving.

Actual Behavior

• The proposal content is cleared and the update summary shows only:

Update(path/to/file)
└ (No changes)

• The developer loses access to the proposed code/diff unless they re-prompt Claude to regenerate or accept the edit and then undo in VCS.

Additional Context

• Regression: This behavior differs from earlier versions where the CLI preserved the full proposed code after a No response, enabling precise, line-level feedback.
• Impact on DX:
• Increases cognitive load (engineers must recall changes from memory).
• Encourages risky workflows (accepting edits just to view them, then reverting).
• Slows iteration; makes it harder to give concrete, line-referenced guidance.
• Suggested Fixes (any would restore UX):

1. Keep the proposed diff printed below the prompt even when No is selected. (best option, imho)
2. Add a --persist-proposals flag or default that writes the last proposal to a temp file.
3. If proposals are large, collapse by default but allow expand-on-demand after No.

Severity: Medium (workflow friction, repeated across all file edits)
Frequency: 100% reproducible in my environment