Reported issues for Clipboard
Pod holds 19 of 26 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to Clipboard.
Most discussed
X11/Wayland PRIMARY selection support
Summary
Expose the X11 PRIMARY selection (the middle-click / select-text-to-copy buffer) as a separate read source. Wayland has an analogous primary selection on most compositors. Today clipboard_paste only reads the CLIPBOARD selection.
Why this is worth building
Power users on Linux rely heavily on PRIMARY for "select-and-paste" workflows — it captures whatever text is currently selected, with no explicit copy step. Tools like Vim, terminal emulators, web browsers, and IDEs all popu
Read the thread · 2026-05-05 · closed · outside contributor · 0 comments
Markdown to rich-text write: paste as formatted in Slack, Gmail, Notion
Summary
Let the model write markdown that pastes as rich text in apps that prefer HTML/RTF (Slack, Gmail, Notion, Word, Google Docs). Closes the read/write asymmetry for formatted text: today we read HTML tables and rich content beautifully but only write plain.
Why this is worth building
The model genuinely cannot do this on its own. Slack/Gmail/etc. promote HTML over plain text when both are on the clipboard, and there is no way to put HTML on the clipboard from the model side without
Read the thread · 2026-05-05 · closed · outside contributor · 0 comments
Image write: put PNG/JPEG on the clipboard
Summary
Add the ability for the model to write an image to the system clipboard. Today clipboard_paste returns images, but the model has no way to put one back. This closes the read/write asymmetry for binary content.
Why this is worth building
This is something the model genuinely cannot do without us:
- The host model can produce or fetch images via other tools, but cannot reach the OS pasteboard.
- A user generating a chart, fetching a remote image, or extracting one from a PDF of
Read the thread · 2026-05-05 · closed · outside contributor · 0 comments
bug: pr-labels-ci.yml contains literal empty ${{ }} in shell comments (parser hazard)
Summary
.github/workflows/pr-labels-ci.yml contains the literal sequence of an empty GitHub Actions expression inside two shell comments. GHA substitutes those expressions inside run: blocks before the shell sees them, including sequences inside shell comments. When the workflow is invoked via workflow_dispatch (or on a fresh-repo registration push-validation path), the queue-time parser treats the empty expression as malformed and returns:
Failed to queue workflow run: Invali
Read the thread · 2026-04-20 · closed · outside contributor · 0 comments
clipboard_copy does not validate mime_type with _MIME_RE
Problem
clipboard_copy (server.py:386-411) lowercases mime_type and checks the binary-prefix list, but does not validate against _MIME_RE. By contrast, clipboard_read_raw (server.py:307-312) does validate. The unvalidated value reaches wl-copy --type <mime> / xclip -target <mime> on Linux backends.
Impact
Not exploitable - asyncio.create_subprocess_exec blocks shell injection. This is a consistency gap and a hygiene issue: the regex exists, the read path uses it, the w
Read the thread · 2026-04-14 · closed · outside contributor · 0 comments
macOS list_formats can return duplicate text/plain entries
Problem
_UTI_TO_MIME maps both public.utf8-plain-text and public.plain-text to text/plain. macOS often has both UTIs on the pasteboard simultaneously after a normal copy. The result list is not deduplicated.
clipboard.py:313
return [_UTI_TO_MIME.get(t, t) for t in native]
Impact
clipboard_list_formats reports inflated counts to the user (e.g., "3 formats" when there are really 2). The downstream image-format scan in clipboard_paste is unaffected.
Read the thread · 2026-04-14 · closed · outside contributor · 0 comments
Slack format description in clipboard_paste.md is stale
Problem
src/mcp_clipboard/instructions/clipboard_paste.md line 32 still describes the slack format as:
bold header + space-aligned data in a monospace code block
PR #50 changed the implementation to put the header inside the code block with a dashed underline (to avoid Slack mrkdwn escaping issues). The instruction file was not updated, so the host LLM sees a stale description.
Suggested fix
Update line 32 to:
"slack": monospace code block with dashed-underline header row (av
Read the thread · 2026-04-14 · closed · outside contributor · 0 comments
Help wanted: Claude Code testers
mcp-clipboard was built for Claude Code — it works around the terminal padding bug that corrupts long commands when you copy them from Claude Code's output. If you use Claude Code, even 10 minutes of testing would be a huge help.
Setup
claude mcp add clipboard -- uvx mcp-clipboard
That's it. Claude Code will discover the tools automatically.
Tests
Clipboard padding workaround
- Ask Claude Code to generate a
Read the thread · 2026-04-04 · open · outside contributor · 4 comments
Most recent
Phase 2: port _windows_read_image and _windows_write_image to pywin32
Tracking issue for the follow-up to PR #146.
PR #146 (the Windows backend pywin32 refactor) is scoped to text formats only -- text/plain, text/html, text/rtf, image/svg+xml, multi-format atomic writes, and list_formats. The image read/write paths (_windows_read_image, _windows_write_image in src/mcp_clipboard/clipboard.py) stay on the PowerShell-subprocess backend in Phase 1 because porting them needs DIB to PNG conversion which is enough additional work to deserve its own PR.
This i
Read the thread · 2026-05-09 · open · outside contributor · 0 comments
clipboard_copy(mime_type=image/svg+xml) silently no-ops on CD/Windows in v2.6.1
Summary
On Claude Desktop for Windows running mcp-clipboard v2.6.1 (confirmed via uvx mcp-clipboard --version), clipboard_copy(content=<svg markup>, mime_type=image/svg+xml) silently fails to write to the clipboard. The clipboard's existing contents are unchanged; subsequent reads via clipboard_paste, clipboard_read_raw image/svg+xml, or clipboard_list_formats show no SVG present, only whatever was on the clipboard before the call.
Environment
- mcp-clipboard: 2.6.1 (PyPI, ser
Read the thread · 2026-05-09 · open · outside contributor · 0 comments
clipboard_copy loses non-ASCII bytes on CD/Windows in v2.6.1
Summary
On Claude Desktop for Windows running mcp-clipboard v2.6.1 (confirmed via uvx mcp-clipboard --version), clipboard_copy(content=..., mime_type=text/plain) loses non-ASCII bytes. Em dash (U+2014), curly quotes (U+2018, U+2019, U+201C, U+201D), ellipsis (U+2026), CJK ideographs, Arabic, and emoji all fail to round-trip; the symptom on read-back is either ASCII normalization or the classic Windows codepage ? substitution.
Environment
- mcp-clipboard: 2.6.1 (PyPI, served via `u
Read the thread · 2026-05-09 · closed · outside contributor · 0 comments
Comprehensive Windows integration test suite (run on real Windows, not Linux mocks)
Context
After #129 (UTF-8 stdin encoding) and #136 (SVG read path) both shipped fixes that escaped Linux-mocked unit tests and only surfaced via QEMU Windows guest testing, it's time to design a comprehensive Windows test suite that runs against a real Windows OS. Current state: tests/test_server.py mocks every Windows code path through unittest.mock.patch on _run / _run_with_stdin, so the actual PowerShell behavior is never exercised in CI. The integration-x11 job runs on Linux an
Read the thread · 2026-05-07 · open · outside contributor · 0 comments
SVG clipboard round-trip fails on Windows: clipboard_paste returns 'Clipboard is empty' after clipboard_copy(mime_type=image/svg+xml)
Repro
On a Windows host (originally reported on a QEMU Windows guest):
clipboard_copy(content=<svg>...</svg>, mime_type="image/svg+xml")— reports success: "Copied 307 characters".clipboard_paste()— returns "Clipboard is empty".
Debug log on the read side shows: DEBUG Image read failed: Unsupported image type: image/svg+xml from server.py.
Why this happens
Three layered gaps in the read path:
_windows_read(clipboard.py:404) — only handlestext/html, `tex
Read the thread · 2026-05-07 · closed · outside contributor · 0 comments
macOS pbcopy text-write paths share the locale-dependent encoding-mismatch class with the fixed Windows bug (#129)
Context
Companion to #129 / #131. While auditing the Windows UTF-8 stdin-encoding fix, the same shape of risk turned up in two macOS write paths. Filing now so it isn't lost; not assigning a priority above low because there's no live repro.
Risk surface
pbcopy reads stdin and converts the byte stream into an NSString to place on NSPasteboard. That conversion uses LC_CTYPE / LANG from the subprocess environment to pick the encoding. If the subprocess inherits a non-UTF-8 lo
Read the thread · 2026-05-07 · open · outside contributor · 0 comments
Install ergonomics: smooth out the uvx install path
Context
While discussing the image-write feature earlier, the maintainer noted that getting mcp-clipboard installed via uvx was painful. This issue captures that as a follow-up so the friction points can be enumerated, prioritized, and addressed.
This is a placeholder to land the conversation; it should be expanded with concrete reproduction steps once someone has the bandwidth to walk through a fresh install on each supported platform.
What to capture
For each of Linux (X11 + Waylan
Read the thread · 2026-05-07 · closed · outside contributor · 0 comments
Windows clipboard_copy corrupts non-ASCII characters (em dash and other UTF-8 multi-byte chars)
Problem
When clipboard_copy writes text containing non-ASCII characters on Windows, the bytes are corrupted by the time they land on the clipboard. Pasting into Notepad shows mojibake instead of the original characters.
Observed: Copying a string containing an em dash (U+2014) followed by space and "C" produced [Cö C (or similar garbled bytes) on paste, instead of — C.
Platform: Windows (verified on a QEMU Windows guest).
Workaround: Stick to ASCII-safe characters (e.g.
Read the thread · 2026-05-07 · closed · outside contributor · 0 comments
Register mcp-clipboard with the MCP Server registry (server.json + publish-registry workflow)
Cross-agent handoff from Dev session (cmeans/mcp-synology side, 2026-05-05).
Why
mcp-clipboard ships to PyPI (mcp-clipboard 2.3.0 published 2026-05-03) but isn't listed in the official MCP Server registry at registry.modelcontextprotocol.io. mcp-synology was registered as part of v0.5.2 on 2026-05-01 and the same pattern can be transplanted here in one PR. The win: discoverability via the MCP registry directory plus the mcp-publisher schema validation gate that catches server.json
Read the thread · 2026-05-06 · closed · outside contributor · 0 comments
macOS osascript -e ARG_MAX hardening across _macos_write_typed and _macos_write_image
Summary
Both _macos_write_typed (text/html, text/rtf, image/svg+xml) and _macos_write_image (PNG/JPEG, #108 / #111) build the AppleScript body in Python and pass it via osascript -e <script>. macOS getconf ARG_MAX is typically 1,048,576 bytes. The chunked-base64 trick keeps each AppleScript line under 4,000 chars (under AppleScript's per-line 32,767-char limit) but it does NOT bound the total argv size — that's still the entire script as one argv element.
For HTML/RTF the practi
Read the thread · 2026-05-06 · closed · outside contributor · 0 comments
SVG clipboard write: typed-text path through clipboard_copy
Summary
Allow clipboard_copy to accept mime_type="image/svg+xml". SVG is text (XML) and the read path already treats it as text-readable, but the write path silently rejects it because image/* is in _BINARY_MIME_PREFIXES. This issue closes the asymmetry.
This is intentionally not a clipboard_copy_image extension. That tool (#108 / #111) is strictly binary bytes with magic-byte validation. SVG doesn't fit that contract — it's text. Two clean contracts is better than overloading
Read the thread · 2026-05-05 · closed · outside contributor · 0 comments
The remaining reports are on the project's issue tracker.