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

File tree "Copy Path" has no clipboard fallback and shows the success toast even when the write fails

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

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
react, typescript
Domain
developer-experience, frontend

Research direction

Find the file tree context menu’s Copy Path handler and the existing copyText helper used by the settings copy buttons. Read how the helper reports failure, then update the handler to use it and show only the toast matching the result. Verify by testing a successful copy and a rejected clipboard write; success should copy the path, and failure should show only the error toast.

Written by the indexing model from the issue text.

Description

Summary

In the file tree context menu, Copy Path calls navigator.clipboard.writeText() directly. When the browser rejects the write, nothing is copied, and the UI shows both an error toast ("Failed to copy path") and a success toast ("Path copied to clipboard").

Environment

  • CloudCLI UI 1.37.5
  • Android 12, Chrome 114.0.5735.196 (mobile)
  • HTTPS + valid certificate, so this is a secure context (navigator.clipboard exists — the handler throws a rejected promise, not a TypeError)

Steps to reproduce

  1. Open a project's file tree in a mobile browser.
  2. Long-press (or right-click) a file → Copy Path.
  3. Paste elsewhere: clipboard is unchanged. An error toast appears, together with the success toast.

Root cause

From the shipped bundle (dist/assets/index-*.js):

N = useCallback(H => {
  navigator.clipboard.writeText(H.path).catch(() => {
    n(r("fileTree.toast.copyFailed", "Failed to copy path"), "error")
  }),
  n(r("fileTree.toast.pathCopied", "Path copied to clipboard"), "success")
}, [n, r])
  • No fallback to document.execCommand("copy"), even though the app already ships a copyText helper with a textarea + execCommand fallback (the one used by the settings copy buttons). So the codebase already assumes the Clipboard API is not universally available.
  • The success toast runs unconditionally, so it is shown even when the write rejected.
  • The rejection reason is swallowed (catch(() => ...)), which makes this hard to diagnose remotely.

Suggested fix

  1. Reuse the existing copyText helper (Clipboard API → execCommand("copy") fallback) in handleCopyPath.
  2. Show success/error based on the actual result instead of always showing success.
  3. Optionally include err.name / err.message in the console output for diagnostics.

Workaround

A page-level shim that wraps Clipboard.prototype.writeText and falls back to document.execCommand("copy") fixes every copy entry point without touching the bundle.

Dominant language
TypeScript
Stars
13.9k
Forks
2k
Avg merge
2d 19h
Merged PRs (30d)
28

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: 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 siteboon/claudecodeui

All issues in siteboon/claudecodeui

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.