Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[BUG] Link click-to-copy sets clipboard as application/octet-stream, breaking paste in browsers (missing wl-copy --type on Wayland)

Open Beginner friendly
  • Is something wrong?
#313 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
linux, lua, neovim
Domain
desktop-dev, tooling

Research direction

Start at the link-copy handler used when a URL is copied from :ClaudeCode, and trace whether it invokes wl-copy directly or uses vim.fn.setreg("+", url). Verify the fix with wl-paste -l and Firefox or Chromium; done means the clipboard exposes text/plain and the URL pastes in Wayland GUI applications.

Written by the indexing model from the issue text.

Description

bug needs-triage

Description

Clicking a link in the Claude terminal (opened via :ClaudeCode) copies it to
the clipboard with a notification confirming success, but the copied content
cannot be pasted into Firefox or Chromium on Wayland. Pasting into terminal
tools (wl-paste) works fine — only GUI applications using the standard
wl_data_device_manager protocol fail to read it.

Environment

  • OS: Kicksecure (Debian 13/trixie)
  • Compositor: labwc 0.8.3 (wlroots-based)
  • Terminal: kitty 0.41.1
  • Terminal provider: snacks (terminal.provider = "snacks")
  • wl-clipboard installed and confirmed working correctly for manual
    wl-copy --type text/plain calls

Steps to reproduce

  1. Open :ClaudeCode, get Claude to output a URL
  2. Double-click the link to copy it (plugin shows a "copied" notification)
  3. Try to paste (Ctrl+V) into Firefox's address bar, or Chromium's
  4. Nothing pastes; the field remains empty or unchanged

Diagnosis

Running wl-paste -l immediately after step 2 shows only:
application/octet-stream

By contrast:

  • wl-copy --type text/plain "url" followed by wl-paste -l correctly
    shows text/plain, text/plain;charset=utf-8, UTF8_STRING, etc., and
    pastes into Firefox/Chromium without issue.

  • A manual OSC 52 sequence sent directly to kitty (printf '\033]52;c;...')
    is also correctly typed as text/plain by kitty itself — so kitty's own
    OSC 52 → Wayland clipboard bridge is not at fault.

  • Plain echo "text" | wl-copy (no --type) also produces
    application/octet-stream on this system, matching wl-clipboard's
    documented limitation:

    wl-clipboard is not always able to detect that a MIME type is textual,
    which may break pasting into clients that expect textual formats, not
    application/something. The workaround […] is to specify the desired
    MIME type explicitly, such as wl-copy --type text/plain.
    — wl-copy(1) manpage, BUGS section

This strongly suggests the link-copy code path shells out to wl-copy
without an explicit --type, hitting this known/documented wl-clipboard
limitation, rather than going through Neovim's own clipboard provider
(vim.fn.setreg("+", url)), which I confirmed produces correctly-typed
text/plain clipboard content on the same system (tested via "+yy on a
normal buffer, checked with wl-paste -l).

Suggested fix

If the link-copy handler invokes wl-copy directly, adding --type text/plain (as documented as the standard workaround for this exact
wl-clipboard limitation) should resolve it. Alternatively, routing the copy
through Neovim's vim.fn.setreg("+", url) instead of a raw external
wl-copy call would also sidestep the issue, since that path is confirmed
to type the content correctly on this system.

Happy to test a fix if useful — this was fully reproducible and isolated
step by step (system Wayland clipboard, kitty's native OSC 52 handling, and
Neovim's own clipboard provider were all individually verified to work
correctly, narrowing the issue down to this specific code path).

Dominant language
Lua
Stars
3.1k
Forks
217
No merged PRs in 30d

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from coder/claudecode.nvim

All issues in coder/claudecode.nvim

Similar issues

More Lua issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.