The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		May 14, 2026 11:56pm

PR Summary

Medium Risk
Adds a new file-attachment path from the Agent UI through execution and into multiple provider adapters, including base64 materialization and request shaping; mistakes could lead to ignored inputs or oversized payloads. Capability-gating reduces blast radius but touches core agent execution and provider request formatting.

Overview
Agent blocks now support a new files message role, allowing users to attach one or more workspace files alongside the existing system/user/assistant messages.

The editor UI adds a Files row that renders FileUpload inline, stores attachments inside the messages array, and surfaces warnings when the selected model doesn’t support attachments or when specific MIME types will be ignored.

Execution and providers are extended end-to-end: the agent handler extracts files messages, materializes them via readUserFileContent into ProviderFileAttachment base64 payloads (with size limits), and passes them through ProviderRequest.fileAttachments; Anthropic, OpenAI/Azure OpenAI, and Google/Gemini/Vertex request builders append attachments to the latest user message in provider-specific formats, with model capability gating via new supportsFileAttachments.

^{Reviewed by Cursor Bugbot for commit 9d9a959. Bugbot is set up for automated code reviews on this repo. Configure here.}

Greptile Summary

This PR introduces a Files message type for Agent blocks, allowing users to attach files directly within the messages array. Files are materialised at execution time, routed through per-provider formatters (OpenAI Responses API input_file/input_image, Anthropic content blocks, Gemini inline data), and gated by a new fileAttachments capability flag per provider/model.

• UI layer (messages-input.tsx, file-upload.tsx): adds a "files" role option in the message-row popover, renders a controlled FileUpload for that row, and shows inline warnings when the selected model or provider does not support the attached file types.
• Executor layer (agent-handler.ts): extractFileInputs collects FilesMessage entries and buildFileAttachments materialises them to base64 via readUserFileContent, then passes a ProviderFileAttachment[] array through buildProviderRequest.
• Provider layer: anthropic/core.ts, google/utils.ts, and openai/utils.ts each gain a helper that splices file content blocks/parts into the last user message (or synthesises a new user turn when none exists).

Confidence Score: 4/5

The core execution path is correct and well-tested; files are properly gated behind capability checks and silently dropped for unsupported models.

The main concerns are data-hygiene: MIME type constants duplicated across two files will drift, ghost Zustand entries accumulate in the workflow store for each controlled FileUpload row, and file reads are sequential rather than parallel. None of these break functionality today, but the store-entry accumulation could affect serialised workflow size over time.

messages-input.tsx (duplicate MIME constants, ghost store entries) and agent-handler.ts (sequential file reads).

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant UI as MessagesInput (UI)
    participant Store as Zustand Store
    participant Handler as AgentBlockHandler
    participant MatSrv as readUserFileContent
    participant Provider as Provider (OAI/Anthropic/Gemini)

    UI->>Store: "setMessages([...TextMessages, FilesMessage{files:[...]}])"
    Note over UI: Warns if model !supportsFileAttachments or Anthropic-unsupported MIME types

    Handler->>Store: read inputs.messages
    Handler->>Handler: extractValidMessages() → TextMessage[]
    Handler->>Handler: extractFileInputs() → RawFileInput[]

    alt supportsFileAttachments(model)
        loop each file
            Handler->>MatSrv: readUserFileContent(userFile, ctx)
            MatSrv-->>Handler: base64 string
        end
        Handler->>Handler: buildFileAttachments → ProviderFileAttachment[]
    else model does not support files
        Handler->>Handler: return undefined (files dropped, warning logged)
    end

    Handler->>Provider: "executeProviderRequest({messages, fileAttachments})"
    Provider->>Provider: appendFileBlocks/Parts to last user message
    Provider-->>Handler: LLM response

_{Reviews (1): Last reviewed commit: "Add tests for agent file attachments" | Re-trigger Greptile}

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

^{_{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}}

@mesrefoglu is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.