Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Desktop app: support drag-and-drop / attachment of PDF, DOCX, and Markdown files (parity with CLI) [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49112•Fetched 2026-04-17 08:50:32
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
Anusree-JAnusree-J
Participants
Anusree-JAnusree-Jgithub-actions[bot]github-actions[bot]
Timeline (top)
labeled ×3closed ×1commented ×1

The Claude Code CLI supports drag-and-drop of arbitrary file types — including .pdf, .docx, .md, and other document formats — directly into the prompt, and they are read/processed as input.

The Claude Code desktop app does not appear to support attaching these same file types. Only a limited set (e.g. images) seems to be accepted, and dragging in a PDF / DOCX / Markdown file either does nothing or is rejected.

This creates an inconsistent experience between the two surfaces and forces desktop users to fall back to the CLI for any workflow involving document input.

Error Message

If there is a security / sandboxing reason certain file types are gated in the desktop app, it would help to either (a) surface a clear error message explaining this, or (b) expose a setting to allow-list additional file types.

Root Cause

  • Workflow parity: users shouldn't have to switch to the CLI just to share a design doc, spec, RFC, or README with Claude.
  • Common real-world inputs: PDFs (papers, specs), DOCX (requirements docs), and Markdown (READMEs, ADRs, design docs) are the most common document formats engineers want to hand to Claude Code.
  • Discoverability: desktop users reasonably expect drag-and-drop to "just work" the way it does in the CLI and in the claude.ai web app.
RAW_BUFFERClick to expand / collapse

Summary

The Claude Code CLI supports drag-and-drop of arbitrary file types — including .pdf, .docx, .md, and other document formats — directly into the prompt, and they are read/processed as input.

The Claude Code desktop app does not appear to support attaching these same file types. Only a limited set (e.g. images) seems to be accepted, and dragging in a PDF / DOCX / Markdown file either does nothing or is rejected.

This creates an inconsistent experience between the two surfaces and forces desktop users to fall back to the CLI for any workflow involving document input.

Steps to reproduce

  1. Open the Claude Code desktop app.
  2. Try to drag a .pdf, .docx, or .md file into the prompt area (or use any "attach file" affordance if present).
  3. Observe that the file is not accepted / not attached.
  4. In the CLI (claude), drag the same file into the terminal prompt — it is accepted and its contents are made available to the model.

Expected behavior

The desktop app should support attaching / drag-and-drop of the same file types the CLI supports, at minimum:

  • .pdf
  • .docx (and ideally .doc, .odt)
  • .md / .markdown
  • .txt and other common plain-text formats
  • Ideally: any file type the CLI currently accepts, for full parity

Why this matters

  • Workflow parity: users shouldn't have to switch to the CLI just to share a design doc, spec, RFC, or README with Claude.
  • Common real-world inputs: PDFs (papers, specs), DOCX (requirements docs), and Markdown (READMEs, ADRs, design docs) are the most common document formats engineers want to hand to Claude Code.
  • Discoverability: desktop users reasonably expect drag-and-drop to "just work" the way it does in the CLI and in the claude.ai web app.

Environment

  • Claude Code desktop app (macOS)
  • Compared against Claude Code CLI on the same machine

Additional notes

If there is a security / sandboxing reason certain file types are gated in the desktop app, it would help to either (a) surface a clear error message explaining this, or (b) expose a setting to allow-list additional file types.

extent analysis

TL;DR

The desktop app likely needs to be updated to support drag-and-drop of additional file types, such as .pdf, .docx, and .md, to match the CLI's functionality.

Guidance

  • Review the desktop app's file type handling code to identify the specific restrictions or limitations that are preventing the acceptance of certain file types.
  • Compare the file type handling logic between the desktop app and the CLI to ensure consistency and identify potential discrepancies.
  • Consider adding a setting to allow users to specify additional file types that should be accepted by the desktop app, or provide a clear error message explaining why certain file types are not supported.
  • Investigate potential security or sandboxing reasons that may be contributing to the file type restrictions in the desktop app.

Example

No specific code example can be provided without more information about the desktop app's implementation, but a potential solution might involve updating the app's file type filtering logic to include the desired file extensions.

Notes

The solution may require updates to the desktop app's codebase, and careful consideration should be given to any security or sandboxing implications of allowing additional file types.

Recommendation

Apply a workaround by using the CLI for workflows involving document input until the desktop app can be updated to support the necessary file types, as this will provide the most consistent user experience.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The desktop app should support attaching / drag-and-drop of the same file types the CLI supports, at minimum:

  • .pdf
  • .docx (and ideally .doc, .odt)
  • .md / .markdown
  • .txt and other common plain-text formats
  • Ideally: any file type the CLI currently accepts, for full parity
#memory management#API rate limit#retriever error#indexing error#inference speed

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING