Feature Request: Enable agentic workflows to access issue/PR file attachments

[arezero]

Problem

Agentic workflows triggered by issues cannot download file attachments (.docx, .pdf, .xlsx, .pptx, etc.) that users attach to issue bodies or comments. This is a significant limitation for workflows that need to process uploaded documents — for example, triaging issues that include specification documents, reviewing attached reports, or extracting data from uploaded spreadsheets.

Current behavior

When a user attaches a file to a GitHub issue, the file is uploaded to a user-attachments URL such as:

https://github.com/user-attachments/assets/<uuid>/<filename>.docx

The agent cannot access these URLs. Attempts to download them via curl, gh api, or any authenticated HTTP request using GITHUB_TOKEN, fine-grained PATs, or GitHub App tokens all return HTTP 404.

This is a known GitHub platform limitation — the attachments API does not support programmatic download of issue/PR file attachments (see cli/cli#9046, community discussion #162417, community discussion #54551).

Why this matters for agentic workflows

Agentic workflows are uniquely positioned to process unstructured documents attached to issues. Real-world use cases that are currently blocked include:

• Document review workflows: An issue is opened with a .docx spec attached → the agent reads the document, validates it against repo conventions, and comments with feedback.
• Data extraction: A .xlsx or .csv is attached to a bug report → the agent parses the data to reproduce or triage the issue.
• Intake/onboarding automation: Users submit requests by opening an issue with supporting documents attached → the agent processes the attachments and routes the request.
• Compliance and audit: Attached evidence files need to be read, catalogued, or cross-referenced by an automated workflow.

The fact that agents can read issue bodies, comments, labels, and repo files — but not the files users attach — creates a gap in what should be a natural workflow pattern.

Proposed solution

Provide a mechanism for agentic workflows to access file attachments on the triggering issue or PR. Some possible approaches:

Option A: Built-in safe-input or tool (preferred)

Add a built-in tool (e.g., download-attachment) or extend the GitHub MCP server toolset to support downloading attachments from issues/PRs. The agent would call something like:

download_attachment(issue_number, attachment_url) → local file path

This would use the workflow's GITHUB_TOKEN or configured PAT to authenticate and download the file into the agent's workspace.

Option B: Expose attachments via the GitHub MCP server

Extend the issues toolset in the GitHub MCP server to return attachment metadata (filename, URL, size, mime type) alongside issue content, and provide an authenticated download capability. This would fit naturally into the existing github: tools configuration:

tools:
  github:
    toolsets: [issues, attachments]  # new toolset

Option C: Pre-download attachments as a compile-time/runtime step

During workflow setup (before the agent runs), automatically detect attachment URLs in the triggering issue body and download them into the workspace (e.g., /tmp/attachments/). The agent would then access them as local files. This could be configured in frontmatter:

on:
  issues:
    types: [opened]
    attachments: true  # pre-download attachments to workspace

Workarounds (current, all have friction)

Workaround	Limitation
Ask users to commit files to the repo instead of attaching	Changes user behavior; not always practical
Use an orphaned assets branch	Extra setup; requires contributor workflow change
Link to external storage (SharePoint, Drive)	Requires additional MCP server; breaks GitHub-native workflow
Parse issue body and curl the URL	Returns 404 — this is the core problem

Environment

• gh-aw version: 0.58.3
• Repo visibility: Private repos (not tested on public repos)

Additional context

This feature would pair well with existing MCP servers like markitdown (for converting documents to markdown) or custom safe-inputs that process binary files. The missing piece is purely the access — once the file is in the workspace, the ecosystem already has tooling to handle it.

[pelikhan]

@salmanmkc