Repository navigation
Feature Request: Enable agentic workflows to access issue/PR file attachments #21242
Description
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
.docxspec attached → the agent reads the document, validates it against repo conventions, and comments with feedback. - Data extraction: A
.xlsxor.csvis 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 toolsetOption 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 workspaceWorkarounds (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.
Activity
pelikhan commentedon Apr 10, 2026
@salmanmkc
pelikhan commentedon Oct 7, 2026
Status (2026-10-07; Needs progress check): The March 16 request reports HTTP 404 responses when workflows try to download issue attachments, and the April 10 comment contains only a mention, not an implementation update. The issue is open and needs a progress check on whether a supported attachment-access mechanism exists before choosing a gh-aw integration.
pelikhan commentedon Oct 16, 2026
Current-state refresher (2026-10-16): still relevant; private file-attachment access remains unverified rather than solved by existing upload features. The upstream CLI request cli/cli#9046 is still open. In current gh-aw, the safe-output surface includes uploading assets/artifacts and Azure DevOps work-item attachments; these are different operations and do not provide the requested GitHub issue/PR file-attachment download path.
The report was specifically about private repositories. This pass did not attempt an authenticated download of its private attachment or verify current GitHub backend behavior, so the original blanket claim about all token types returning 404 should not be treated as newly reproduced evidence. Public/image access is also not sufficient evidence that private
.docx/.pdf/spreadsheet attachments work.Remaining work is a verified, supported access/authentication mechanism for private GitHub attachments, then a bounded download integration; document conversion tools only help after that access step succeeds. No live workflow was triggered.
pelikhan commentedon Oct 22, 2026
2026-10-22 assessment: keep open; private document downloads need a verified workflow-authentication path.
There is useful evidence beyond the earlier blanket “all tokens return 404” premise: merged drogers0/gh-image#46 implements attachment downloads and reports private-repository testing with bearer authentication. Its protocol notes describe authenticated redirect resolution followed by an unauthenticated presigned fetch. This is a concrete investigation lead, not proof that Actions
GITHUB_TOKEN, installation tokens, or the affected private document attachments work. The extension also has browser-session fallback; that must not be silently adopted as workflow credential behavior.cli/cli#9046 remains open. Current gh-aw upload/ADO attachment outputs and asset/artifact uploads are different operations.
Next action / evidence needed: provide a sanitized private
.docx/.pdf/.xlsxcase with URL shape, token class/permissions, initial status/redirect category, and successful final byte/type verification (never publish tokens or signed URLs). Confirm the supported platform authentication contract, then design bounded download/provenance/redirect handling without forwarding credentials to storage. No private attachment was downloaded in this review, so neither universal failure nor resolution is newly reproduced.