Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭 适合新手
  • 哪里不对？
#313 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
72/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
linux, lua, neovim
领域
desktop-dev, tooling

调研方向

从复制 URL 时使用的链接复制处理程序入手，追踪它是直接调用 wl-copy，还是使用 vim.fn.setreg("+", url)。使用 wl-paste -l 和 Firefox 或 Chromium 验证修复；当剪贴板公开 text/plain，并且 URL 可以粘贴到 Wayland GUI 应用程序中时，即表示完成。

由索引模型根据 Issue 内容生成。

描述

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).

主要语言
Lua
星标
3.1k
派生
219
30 天内没有已合并 PR

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

coder/claudecode.nvim 的其他 Issue

查看 coder/claudecode.nvim 的全部 Issue

相似的 Issue

更多 Lua Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。