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

Mon, 07 Sep 2026 23:03:16 +0900

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.

Commands for diagnosing 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.

Command to write the registration back

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

If you run this command when everything is working normally, it will fail with an echo: I/O error. This is because writing to the register rejects a duplicate entry with the same name, so the error does not indicate that anything is wrong.

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.

Terminal on NakuRei's Notes