Skip to content

fix: preserve PDF filenames from tool output - #42401

Closed
slarson-redo wants to merge 1 commit into
anomalyco:devfrom
redoapp:unsupported-attachments
Closed

fix: preserve PDF filenames from tool output#42401
slarson-redo wants to merge 1 commit into
anomalyco:devfrom
redoapp:unsupported-attachments

Conversation

@slarson-redo

Copy link
Copy Markdown

Prevent PDF tool results from poisoning sessions on OpenAI-compatible provider transports.

The AI SDK turns media embedded in a tool result into an input_file with a fallback filename when the stored attachment filename is unavailable. Providers that validate the filename reject that replay, and every later request in the session fails on the same history. OpenCode now moves PDFs into a normal user message, where it preserves the filename and applies the existing model capability guard.

Changes

  • Treat images as the only inline tool-result media for OpenAI and Bedrock Mantle transports.
  • Move PDF tool-result attachments into the existing synthetic user media message.
  • Preserve the attachment filename when a PDF-capable model receives the replay.
  • Replace the PDF with the existing actionable error text when the model lacks PDF input capability.
  • Add a regression test for both supported and unsupported PDF-capability paths.

Effects

  • Existing sessions with stored PDF tool attachments can replay without resending an extensionless data file inside a tool result.
  • Direct OpenAI and Mantle models still receive supported PDFs as normal user file input.
  • Unsupported models receive text that directs the agent to inform the user instead of a provider rejection.

Verified with all 40 message-v2 tests, package typecheck, repository pre-push typecheck, Prettier, and Oxlint.

Closes #21908

🤖 Generated with Claude Code

OpenAI Responses converts file content inside a tool result without the original filename. Providers that validate file extensions can reject the synthesized filename and poison every later replay of the session.

Move PDF tool attachments into a normal user message for OpenAI and Bedrock Mantle transports. This keeps the filename, preserves supported PDF input, and lets the existing capability guard replace unsupported PDFs with an actionable model-visible error.

Closes anomalyco#21908

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions github-actions Bot added the needs:compliance This means the issue will auto-close after 2 hours. label Aug 13, 2026
@github-actions

Copy link
Copy Markdown
Contributor

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

  • PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

@github-actions

Copy link
Copy Markdown
Contributor

The following comment was made by an LLM, it may be inaccurate:

Potential related PRs found:

  1. fix(session): extract unsupported tool media #41196 - fix(session): extract unsupported tool media - Likely related; addresses extracting media from tool results for models without capability support

  2. fix(session): respect model media capabilities #41212 - fix(session): respect model media capabilities - Related; deals with respecting model media capabilities, which aligns with the PDF capability guard in this PR

  3. fix(session): extract tool-result media for models without attachment capability #41161 - fix(session): extract tool-result media for models without attachment capability - Directly related; handles tool-result media extraction for unsupported attachment capabilities

  4. fix(opencode): handle PDFs in tool results when using Amazon Bedrock #17401 - fix(opencode): handle PDFs in tool results when using Amazon Bedrock - Related; specifically addresses PDF handling in tool results for Bedrock provider

These PRs address the same general problem space of handling PDFs and media in tool results across different providers and model capabilities. Check if this PR (42401) is a fresh approach to an already-addressed issue or if it complements/supersedes the earlier work.

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

Labels

needs:compliance This means the issue will auto-close after 2 hours.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Valid PDF tool results can be forwarded to models without PDF input support

1 participant