Symptom
When running GitHub Copilot CLI inside a psmux session, pressing Ctrl+Shift+V with a screenshot on the clipboard does nothing. The same action works correctly when Copilot CLI runs directly in Windows Terminal without psmux.
Hypothesis
I believe this is an architectural mismatch between how Windows Terminal handles Ctrl+Shift+V and how psmux intermediates it, but I may be missing something — happy to be corrected.
Direct in Windows Terminal (no psmux):
Ctrl+Shift+V is WT's own paste action. Looking at WT's source, clipboard::read() only calls GetClipboardData(CF_UNICODETEXT) and GetClipboardData(CF_HDROP) — no image formats. A screenshot on the clipboard has neither, so text is empty and WT sends nothing to the PTY. My guess is that Copilot CLI intercepts Ctrl+Shift+V before WT's paste handler fires and reads image data directly via Win32, independently of the PTY. This would explain why it works without psmux.
Via psmux:
From what I can tell in src/platform.rs, psmux uses WriteConsoleInputW to inject bracketed paste directly into the child process's console input buffer, bypassing ConPTY. My assumption is that when Ctrl+Shift+V is pressed, WT resolves the clipboard content first (gets empty text for a bitmap image), and psmux ends up injecting nothing or an empty bracketed paste. Copilot CLI never sees the raw Ctrl+Shift+V keypress and therefore never gets the chance to read the clipboard itself.
I may be wrong about the exact mechanism — if there's a different code path I'm missing, I'd appreciate a pointer.
What I've ruled out
paste-detection only intercepts Ctrl+V (ConHost-level), not Ctrl+Shift+V (WT-level) — set -g paste-detection off does not helpset-clipboard on and allow-passthrough all appear to be outbound-only mechanisms, so I don't think they're relevant here
Expected behavior
Ctrl+Shift+V inside psmux should ideally reach the child application as a raw keypress, allowing applications that handle their own clipboard reading to do so.
Workaround
Save the screenshot as a file and paste its path — this puts CF_HDROP on the clipboard, which WT forwards as a file path string that Copilot CLI accepts.
Environment
- Windows Terminal 1.24.11321.0
- GitHub Copilot CLI 1.0.60
- PowerShell 7.6.2
Symptom
When running GitHub Copilot CLI inside a psmux session, pressing Ctrl+Shift+V with a screenshot on the clipboard does nothing. The same action works correctly when Copilot CLI runs directly in Windows Terminal without psmux.
Hypothesis
I believe this is an architectural mismatch between how Windows Terminal handles Ctrl+Shift+V and how psmux intermediates it, but I may be missing something — happy to be corrected.
Direct in Windows Terminal (no psmux):
Ctrl+Shift+V is WT's own paste action. Looking at WT's source,
clipboard::read()only callsGetClipboardData(CF_UNICODETEXT)andGetClipboardData(CF_HDROP)— no image formats. A screenshot on the clipboard has neither, sotextis empty and WT sends nothing to the PTY. My guess is that Copilot CLI intercepts Ctrl+Shift+V before WT's paste handler fires and reads image data directly via Win32, independently of the PTY. This would explain why it works without psmux.Via psmux:
From what I can tell in
src/platform.rs, psmux usesWriteConsoleInputWto inject bracketed paste directly into the child process's console input buffer, bypassing ConPTY. My assumption is that when Ctrl+Shift+V is pressed, WT resolves the clipboard content first (gets empty text for a bitmap image), and psmux ends up injecting nothing or an empty bracketed paste. Copilot CLI never sees the raw Ctrl+Shift+V keypress and therefore never gets the chance to read the clipboard itself.I may be wrong about the exact mechanism — if there's a different code path I'm missing, I'd appreciate a pointer.
What I've ruled out
paste-detectiononly intercepts Ctrl+V (ConHost-level), not Ctrl+Shift+V (WT-level) —set -g paste-detection offdoes not helpset-clipboard onandallow-passthrough allappear to be outbound-only mechanisms, so I don't think they're relevant hereExpected behavior
Ctrl+Shift+V inside psmux should ideally reach the child application as a raw keypress, allowing applications that handle their own clipboard reading to do so.
Workaround
Save the screenshot as a file and paste its path — this puts
CF_HDROPon the clipboard, which WT forwards as a file path string that Copilot CLI accepts.Environment