Cloud agent: CAPIError 400/404 after viewing image on GPT models

[HaiDuc0147]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Copilot Cloud Agent

Body

Summary

In Copilot cloud agent, as soon as the agent views an image file (PNG/JPG) with its view tool, the next model request fails and the session stops with:

Execution failed: CAPIError: 400 Error while downloading file. Upstream status code: 404.

• Fails on GPT models (gpt-5.4, gpt-5.3-codex).
• The same flow on claude-sonnet-5 views the same image and completes normally.
• The same images view fine in the local Copilot CLI (1.0.83) with gpt-5.4 and gpt-5.3-codex.

Environment

• Account: HaiDuc0147 (Copilot Pro)
• Repository: HaiDuc0147/copilot-image-repro (private — happy to grant access)
• Product: Copilot cloud agent, started by assigning an issue to Copilot or from the Agents tab
• Model chosen explicitly in the UI: GPT-5.4 fails, Claude Sonnet succeeds

Steps to reproduce (minimal, no MCP servers)

1. Repository containing a small PNG, e.g. images/small.png (2 KB).
2. Create an issue: "Look at images/small.png and write a one-paragraph description of it to NOTES.md."
3. Assign to Copilot with model GPT-5.4.
4. The agent calls view images/small.png (log: view success=true); the next request fails with the CAPIError above.
5. Repeat with model Claude Sonnet — the agent views the image and completes.

What the logs show

• The view tool succeeds. The failure is on the following request, before any assistant.usage line for that turn — it looks like CAPI rejects the request while resolving the uploaded image attachment for the OpenAI route.
• The runner has GITHUB_UPLOADS_URL=https://uploads.github.com/user-attachments/assets and GITHUB_DOWNLOADS_URL=https://api.github.com/internal/user-attachments/assets; both hosts are on the firewall allowlist.
• The image source doesn't matter (file in the repo, /tmp, or downloaded with curl) — any viewed image fails on GPT.
• In one run the error was delayed: image viewed at turn 6, error at turn 30 after session.idle.

Request IDs (GPT, all failed)

Date (UTC+7)	Model	Actions run / PR	Request ID
2026-09-14	gpt-5.4 (minimal repro, no MCP)	PR #1–#3	3C03:1529BD:4F597:576C7:6AA7F94B
2026-09-14	gpt-5.3-codex (minimal repro, no MCP)	PR #1–#3	52C3:38D699:4F5BAC:572965:6AA7F96C
2026-09-15	gpt-5.4	PR #5	D400:1649DF:82B9CE:95DB74:6AA8ED32
2026-09-15	gpt-5.4	run 34943790968 / PR #15	8835:23CC9C:B34BF4:C71F2A:6AA8F96F
2026-09-15	gpt-5.4	run 34951213399	5004:37FE1A:126BD27:144C00E:6AA90C58
2026-09-15	gpt-5.4	run 34951740683	9423:1574DE:1372DF6:155F552:6AA90DCD
2026-09-15	gpt-5.4	run 34953623977	F444:DDE0B:125E18:14592B:6AA912CE
2026-09-15	gpt-5.4	run 34954896694	2808:222B8B:1752EC3:1990CB8:6AA9175C
2026-09-15	gpt-5.4	run 34955651995	3400:3A124E:28137C3:3196747:6AA91828
2026-09-15	gpt-5.4	run 34960688695	0416:377803:1C554C1:1F0BEA1:6AA9254C
2026-09-15	gpt-5.4	run 34961119439	2403:1A91BD:3215FE:376C2F:6AA92647

Control (same flow on Claude — succeeded)

• 2026-09-15, claude-sonnet-5, Actions run 34943711466 (PR Feature Request: Dual account support/troubles #13): viewed the same PNG (view success=true) and completed normally.

Expected vs actual

• Expected: viewing an image works on all models, as it does on Claude and in the local Copilot CLI.
• Actual: GPT sessions stop with CAPIError 400 / upstream 404 right after viewing an image.

Impact

Any cloud agent task that looks at a screenshot or image asset fails on the default model (Auto → GPT-5.4). The same error appears on public Copilot PRs, e.g. drrowdev/stillroom-wardrobe#7.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[4Raisan]

This is already a strong reproduction. One extra discriminator would be to compare the image attachment metadata at the successful view step with the failing model request: asset URL/host, content type, byte size, and whether the URL is a short-lived signed URL that expires between turns. Please redact tokens and keep the private repository private. A useful control would be the same PNG copied to a fresh path immediately before the GPT run, plus a text-only task after the view; if the fresh asset also fails, that points away from repository permissions and toward attachment handoff in the GPT route. Until fixed, the safest workaround is to use the model that completes successfully or provide a textual description/metadata instead of asking the cloud agent to view the image, while retaining the request IDs for Support.

[Maxim-Mazurok]

I can reproduce this in local VS Code Chat with GPT-5.6 Sol.

• VS Code 1.138.0 / Copilot 0.66.0
• VS Code 1.139.0 / Copilot 0.67.0
• Four distinct incidents on 2026-09-25
• view_image successfully reads valid PNGs, then the next model request fails with the same CAPI 400/upstream 404
• Both WebSocket and fallback HTTP paths fail; CAPI connectivity checks succeed
• Files remain present and decode correctly
• Reproduced with images from 60 KB to 763 KB, including ordinary 1440×900 PNGs
• Three direct reproductions involved two view_image calls in one turn; single-image behavior was not tested
• Automatic retries repeat the same failure

GH request IDs:
E298:33720F:11897B1:13C1EA9:6AB5C3F3
E3E3:A92A8:1474374:16A517C:6AB5C325
E301:1DD80:159B3A:18F814:6AB6048D
E3E3:E22F0:58BB62:643ED8:6AB61354

This appears to extend the affected surface from cloud agents to the local VS Code agent workflow.

---

This report was prepared by Copilot GPT-5.6 Sold Medium on my request, and seems to be mostly accurate.

[PRADHUMAN-SINGH-1]

The most useful clue here is that the same image works with Claude Sonnet and in the local Copilot CLI, while the cloud agent fails immediately after the image view operation. That makes this look much more like a cloud-agent/model-side file retrieval problem than a corrupt PNG.

I would test the same reproduction with:

a very small PNG and JPG;
an image in the repository root and one in a subdirectory;
a newly committed image rather than one that already existed;
the same issue with the GPT model and Claude model.

Also capture the exact sequence from the cloud-agent log: successful view followed by the 404 on the next model request. That distinction is valuable because the 404 is occurring during the downstream request rather than when GitHub first reads the repository file.

Since the local CLI succeeds against the same image, I would avoid changing the image itself unless a minimal reproduction shows that specific file characteristics trigger the issue.