Readline Yank Functionality Broken in Claude CLI

[meefs]

Bug Description

Claude CLI Readline Bug Report

Bug Summary

Critical readline functionality broken: CTRL+u (cut-line-backward) works but CTRL+y (yank/paste) does not function, causing potential data loss when users accidentally cut their input.

Environment Information

System Details

• OS: macOS 15.5 (Build: 24F74)
• Architecture: Apple Silicon (arm64)
• Kernel: Darwin 24.5.0
• Terminal: xterm-256color
• Shell: zsh 5.9 (arm64-apple-darwin24.0)

Claude CLI Details

• Version: 1.0.24 (Claude Code)
• Install Method: npm global

Detailed Bug Description

Expected Behavior (Standard Readline)

In standard readline-enabled applications:

1. CTRL+u: Cut text from cursor position to beginning of line
2. CTRL+y: Yank (paste) the previously cut text back into the input

This is fundamental readline functionality present in bash, zsh, emacs, and virtually all CLI tools that implement readline properly.

Actual Behavior in Claude CLI

1. CTRL+u: ✅ Works correctly - cuts text from cursor to beginning of line
2. CTRL+y: ❌ DOES NOT WORK - no text is pasted, cut content is lost

Impact & Severity

• Data Loss Risk: Users who accidentally press CTRL+u lose their entire input with no recovery method
• Workflow Disruption: Standard muscle memory from other CLI tools doesn't work
• Inconsistent UX: Partial readline implementation creates confusion
• Accessibility Issue: Users relying on standard keyboard shortcuts are impacted

Reproduction Steps

1. Open Claude CLI in any terminal
2. Type a long prompt/message (e.g., "This is a test message that I'm typing to demonstrate the bug")
3. Position cursor anywhere in the middle of the text
4. Press CTRL+u (cut-line-backward)
   • Expected: Text from cursor to beginning is cut and stored
   • Actual: ✅ Works - text is cut from input line
5. Press CTRL+y (yank/paste)
   • Expected: Previously cut text should be pasted back
   • Actual: ❌ Nothing happens - text is permanently lost

Additional Readline Issues to Investigate

The following standard readline keybindings should be verified for completeness:

Line Editing

• CTRL+a: Move to beginning of line
• CTRL+e: Move to end of line
• CTRL+f: Move forward one character
• CTRL+b: Move backward one character
• ALT+f: Move forward one word
• ALT+b: Move backward one word

Kill/Yank Operations

• CTRL+k: Kill from cursor to end of line
• CTRL+u: Kill from cursor to beginning of line ✅ (works)
• CTRL+w: Kill word backward
• ALT+d: Kill word forward
• CTRL+y: Yank (paste) killed text ❌ (broken)
• ALT+y: Yank-pop (cycle through kill ring)

History

• CTRL+p / ↑: Previous history item
• CTRL+n / ↓: Next history item
• CTRL+r: Reverse search through history

Technical Considerations

Likely Root Cause

The Claude CLI appears to have:

1. Partial readline implementation - Some keybindings work, others don't
2. Missing kill ring - Cut text isn't being stored for yanking
3. Incomplete keybinding mapping - CTRL+y handler is missing or non-functional

Implementation Suggestions

1. Use standard readline library (e.g., node-readline, blessed, or native readline)
2. Implement proper kill ring to store cut/killed text
3. Add comprehensive keybinding tests to prevent regressions
4. Follow GNU Readline specification for consistency

Workarounds (Current)

• Use system clipboard: CMD+c/CMD+v (but doesn't work with CTRL+u cut text)
• Avoid CTRL+u: Use backspace/delete instead of cut operations
• Type in external editor: Compose in VS Code/TextEdit then copy-paste

Priority Justification

This should be HIGH PRIORITY because:

• Data loss potential: Users can lose work with no recovery
• Standard expectation: Readline is fundamental CLI UX
• Muscle memory: Experienced users expect these shortcuts
• Consistency: Other Anthropic tools likely implement readline correctly

Related Issues to Consider

• Does Claude CLI implement any readline functionality correctly?
• Are there other broken keybindings beyond CTRL+y?
• Is there a kill ring implementation at all?
• How does this interact with terminal emulator keybindings?

Testing Verification

To verify the fix:

1. Test all standard readline keybindings listed above
2. Verify kill ring functionality (multiple CTRL+u operations should accumulate)
3. Test across different terminals (iTerm2, Terminal.app, Kitty, etc.)
4. Test on different platforms (macOS, Linux, Windows)
5. Verify interaction with system clipboard vs readline kill ring

---

This bug represents a significant UX regression that affects basic CLI usability. Standard readline implementation should be a foundational requirement for any professional CLI tool.

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 1.0.24
• Feedback ID: 02c4d0a1-a20f-4c71-99a8-636cec782a78

Errors

Note: Error logs were truncated.

[jackielii]

can't emphasise how important this is . I do this at least once a day where I killed my line with <ctrl+u> but can't get it back. Although I use <ctrl+_> for undo

[keen99]

ug. just got bit by this - either need to block ctrl+u or fix yank.... this is engrained deep in many folk's muscle memory and having only half of it is bad.

[schpet]

lack of ctrl-y this causes me to lose text very often. i frequently revise prompts with

• ctrl-a (move to start of line)
• ctrl-k (kill rest of line)
• add some stuff
• ctrl-y (yank / paste)

i tried to switch to vim mode to avoid this, but yank/paste is broken there too, e.g. in vim normal mode dw → deletes word, p → doesn't bring it back.

[keen99]

downside of CC being closed source, I can't even patch it. I patched codex (and maybe they'll take my PR someday), so I can at least get ^Y working.

[benjaminjackson]

ug. just got bit by this - either need to block ctrl+u or fix yank.... this is engrained deep in many folk's muscle memory and having only half of it is bad.

Cannot stress this enough, it’s like putting a sign that says “cake” on a door that opens onto the side of a 1000-foot cliff

[graemian]

Also frustrating for me. Is there any other keyboard way to cut and paste?

[schpet]

when writing a prompt, use ctrl-g to spawn $EDITOR (e.g. nvim or similar)

[meefs]

How did you figure that out @schpet ? Not documented here https://docs.claude.com/en/docs/claude-code/interactive-mode

[schpet]

@meefs my colleague told me, it's noted here: https://github.com/anthropics/claude-code/blob/71bb75e3b558a1be9f00323ba0a9884a40dc02be/CHANGELOG.md?plain=1#L88

[keen99]

for those who want yank functionality and dont want to keep waiting, I built a tool to (let your llm) patch claude:

https://github.com/BrassTack/claude-yank-patcher

[schpet]

for those who want yank functionality and dont want to keep waiting, I built a tool to (let your llm) patch claude:

https://github.com/BrassTack/claude-yank-patcher

determined! really unfortunate this thing is not open source so you can't keep a normal fork 🙄

[nilbus]

https://github.com/BrassTack/claude-yank-patcher

@keen99 💯 Thank you!! This is brilliant.

I opened some PRs w/ support for Claude Code 2.0.27, ^T transpose support, symlink installation support, and tweaks to more closely align with readline/emacs behavior, all merged into nilbus/claude-yank-patcher.

[github-actions[bot]]

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

[nilbus]

As of v2.0.62, this is partially implemented.

Keys that should insert into the token ring buffer:

• ✅ Ctrl-w - cut a word back
• ✅ Ctrl-u - cut to start of line
• ✅ Ctrl-k - cut to end of line
• ✅ Alt-Backspace - cut a word back
• ❌ Alt-d - cut to the end of the word

[keen99]

yay! does it work with multi-line properly? ....but I'll check out .62!

[nilbus]

Multi-line cut/yank is partially implemented, and I found a bug:

• ✅ Using Ctrl-w repeatedly to cut multiple lines correctly yanks/pastes lines back in the correct order.
• ❌ Using Ctrl-k repeatedly to cut multiple lines incorrectly yanks/pastes lines back in REVERSE order.
• ❌ Using Alt-d doesn't work at all but should also work across multiple lines

[keen99]

yep, confirmed - multi-line tries to work but fails since i ^Y injects the wrong order.

[keen99]

The issue is in the crA function at line 173283. When Q is true (indicating consecutive kills), it prepends the new text to the existing kill ring with A + mrA, which creates the reverse order problem for Ctrl+K.

this is what my patcher tool has found - I'm going to update the patcher for .62>...