[BUG] Windows: Alt+V image paste fails for an entire session ("No image found in clipboard") — only a fresh session recovers; failing session also has a corrupted (Korean) name

Summary

On Windows, Alt+V to paste a clipboard image fails for the entire lifetime of a session with No image found in clipboard. Use alt+v to paste images, even though the same clipboard image pastes correctly in a brand-new session started immediately after. Repeated Alt+V presses inside the failing session never succeed — only quitting and starting a new claude session recovers paste.

A notable correlating symptom: the failing session's auto-generated name was corrupted into Korean text from the very start, and image paste failed on the first attempt and never worked again. This points to a session-level initialization/state corruption rather than a transient clipboard-read issue.

This is distinct from #59161 (where a second Alt+V press in the same session succeeds) and from #56792 / #68021 (where the read fails regardless of session).

Environment

• Claude Code: 2.1.178
• OS: Windows 11 Home China, build 10.0.26200
• Terminal: Windows Terminal (PowerShell profile)
• Installation: global npm (npm i -g @anthropic-ai/claude-code)

Repro

1. Start a claude session (the one that goes bad — see "Smoking gun" below re: the corrupted name).
2. Put an image on the clipboard (e.g. Win+Shift+S screenshot).
3. At the prompt, press Alt+V.

• Result: No image found in clipboard. Use alt+v to paste images. No image attached.

1. Press Alt+V repeatedly — still fails every time.
2. Quit and start a new claude session; press Alt+V with the same clipboard contents.

• Result: Image attaches correctly as [Image #N].

The only recovery is starting a new session. Nothing about the clipboard changes between steps 4 and 5.

Key discriminator vs related issues

• #59161 — first press fails, second press in the same session succeeds. Here, no number of retries in the failing session helps; only a new session works.
• #56792 / #68021 — read fails regardless of session. Here the same clipboard reads fine in a fresh session, so clipboard state/format is not the cause.
• #61883 — failing paste wipes the clipboard. Not observed here; the image remained readable in the new session.

Smoking gun: corrupted session name

The failing session's auto-generated title came out as Korean text (mojibake) from the moment it was created — the session was never "healthy." Image paste failed on the very first attempt and never recovered. The session-name corruption and the broken clipboard read appearing together, from session start, suggests the session was initialized into a bad state (encoding/state corruption) that also disabled image paste for its whole lifetime.

I could not deterministically force a session to corrupt its name on demand, so this is reported as an observed correlation within this session rather than a strict from-scratch repro. Happy to provide the session transcript/ID if useful.

Hypothesis (for triage)

• A session that initializes in a corrupted state (evidenced by the garbled Korean name) may also permanently disable the clipboard-image read path for that session — as if the clipboard reader's per-session state/handle is initialized once and never re-initialized, so once it's bad it stays bad until session restart.
• Worth checking whether session-title generation and the clipboard-image reader share an initialization path (encoding/locale/STA-thread setup) that, when it misfires, breaks both.

Workaround

Start a new claude session. (Or, as in #56792, save the image to disk and paste the file path.)

Related

• #59161 — same symptom, different mechanism (press-twice works in same session)
• #56792 — Bitmap clipboard reported empty (closed/fixed)
• #68021 — PNG+Bitmap present but read still fails
• #61883 — failing paste destroys clipboard (data loss)
• #65154 — paste takes minutes (regression, Windows 11)