Skip to content

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

Open

Description

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

Activity

  1. locked and limited conversation to collaborators on Mar 16, 2026
  2. unlocked this conversation on Mar 16, 2026
  3. pelikhan commented on Apr 10, 2026

    @pelikhan
    Collaborator
  4. pelikhan commented on Oct 7, 2026

    @pelikhan
    Collaborator

    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.

  5. pelikhan commented on Oct 16, 2026

    @pelikhan
    Collaborator

    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.

  6. pelikhan commented on Oct 22, 2026

    @pelikhan
    Collaborator

    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/.xlsx case 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions