When Paste Suddenly Stopped Working in tmux on WSL: Notes on the Fix

What this is

Some notes on how I fixed an issue where I couldn’t paste text into tmux on WSL.

What happened

When I tried to paste text copied from Notepad on Windows into tmux on WSL, nothing would paste, no matter what I copied.

Environment

• Windows 11 + WSL2 (Ubuntu 24.04) + tmux
• I was using the VS Code integrated terminal

Cause

The cause turned out to be broken WSL interop.

Investigating the cause

I tried a test where I put a known string on the clipboard and then pasted it.

printf 'PASTE_TEST_OK_123' | clip.exe   # Put a known value on the clipboard
# Press Ctrl+V immediately afterward. If everything is working,
# PASTE_TEST_OK_123 should be pasted.

The result was that something completely different was pasted. From this behavior, I suspected that the problem was with writing to the clipboard, before the paste operation itself.

After some investigation, I found that while this problem was occurring, Windows executables in WSL were all failing like this:

$ powershell.exe
/mnt/c/.../powershell.exe: 1: MZ����: not found
/mnt/c/.../powershell.exe: 9: Syntax error: "(" unexpected

I asked an AI about this, and apparently MZ is the magic number used by Windows executables.An error like MZ����: not found apparently means that the exe file is being interpreted and executed as a shell script. According to the AI, this is a characteristic symptom of the WSL interop execution handler having disappeared.

Apparently, the reason Windows binaries can be launched from within WSL in the first place is that the Linux kernel’s binfmt_misc mechanism has a registration rule that says, roughly, “if the first bytes of a file match this particular magic number, pass it to this particular interpreter.” Normally, when a file starts with MZ, it’s handed to the WSL interop bridge, which starts the process on the Windows side. This time, however, that registration had disappeared, so clip.exe was being interpreted as a shell script, which is why pasting stopped working.

I wasn’t able to determine exactly why the registration disappeared. The registrations under /proc/sys/fs/binfmt_misc/, which are used by binfmt_misc, are not persistent. At least in my environment, I found the following in the logs:

• A Docker Desktop crash followed by the WSL integration distro being unmounted
• Repeated Clock change detected messages, which I assume were traces of the system waking from sleep
• A cannot create /proc/sys/fs/binfmt_misc/WSLInterop: Permission denied message, apparently from a failed registration attempt caused by a conflict

Personally, I suspect the Docker Desktop crash was the cause.

Solution

You can use the following commands to check whether broken WSL interop is really the cause.

# Check whether the registration exists:
# if WSLInterop is listed, it is registered
ls /proc/sys/fs/binfmt_misc/

# Check whether it actually works:
# if interop-alive is printed, everything is working
cmd.exe /c "echo interop-alive"

If the second command fails with an MZ...: not found error, restoring the registration is enough to fix the problem. Since all you’re doing is restoring the registration, pasting starts working again without restarting the shell.

sudo sh -c "echo ':WSLInterop:M::MZ::/init:PF' > /proc/sys/fs/binfmt_misc/register"

By the way, you can combine the check and the fix into a single line like this:

[ -e /proc/sys/fs/binfmt_misc/WSLInterop ] && echo "No repair needed" || sudo sh -c "echo ':WSLInterop:M::MZ::/init:PF' > /proc/sys/fs/binfmt_misc/register"

Wrapping up

Thanks, Claude Code.