feat: add google_drive/upload_from_file action for token-efficient file uploads

[iris-clawd]

Summary

Adds a new google_drive/upload_from_file platform action that reads files directly from disk and uploads to Google Drive, bypassing the LLM context window entirely.

Problem

The current google_drive/upload_file action requires passing file content as a parameter in the tool call. This means:

1. Token waste — file content goes through the LLM context, consuming tokens
2. Context limit — binary files (base64-encoded) easily exceed the 128k context limit
3. Poor UX — agents struggle with large or binary file content

Solution

New action: google_drive/upload_from_file

Parameter	Type	Required	Description
file_path	string	✅	Path to the local file to upload
name	string	❌	Custom name (defaults to filename)
mime_type	string	❌	MIME type (auto-detected if omitted)
parent_folder_id	string	❌	Target folder ID
description	string	❌	File description

The tool reads the file locally, base64-encodes it, and sends to the same platform API endpoint (GOOGLE_DRIVE_SAVE_FILE). The LLM only ever sees the short file path string.

Backwards Compatibility

• Existing google_drive/upload_file is completely untouched — zero risk to the 10k+ existing executions
• New action is additive only
• Automatically available when apps include google_drive or google_drive/upload_from_file

Changes

• crewai_platform_file_upload_tool.py — new CrewAIPlatformFileUploadTool class
• crewai_platform_tool_builder.py — auto-injects local tools for apps that support them
• __init__.py — exports new class
• test_crewai_platform_file_upload_tool.py — 14 unit tests
• google_drive.mdx — docs for new action + usage example

Usage

agent = Agent(
    role="File Uploader",
    goal="Upload local files efficiently",
    apps=['google_drive/upload_from_file']
)

The agent can then call google_drive_upload_from_file(file_path='/data/report.pdf') — the PDF is read from disk and uploaded without ever touching the LLM context.

---

Note

Medium Risk
Introduces a new tool that reads arbitrary local files and uploads them to Google Drive, which can have security/ops implications if agents are allowed broad filesystem access. Also changes tool construction to inject local tools for google_drive, affecting which tools are available at runtime.

Overview
Adds a new google_drive/upload_from_file capability that uploads a local disk file to Google Drive without sending file contents through the LLM context, including MIME auto-detection, size guarding (50MB simple-upload limit), and error handling.

Updates the platform tool builder to auto-inject this client-side tool when apps includes google_drive or google_drive/upload_from_file, exports it from the package, and adds unit tests plus Google Drive integration docs and an example for token-efficient uploads.

^{Written by Cursor Bugbot for commit 0000239. This will update automatically on new commits. Configure here.}

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
crewai	🟢 Ready	View Preview	Apr 3, 2026, 8:33 PM

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Unrelated Google Drive actions inject local upload tool

Medium Severity

The second block (checking app_base) always runs even when the app string is a specific action. Because app_base = app.split("/")[0] extracts just "google_drive" from any action like "google_drive/list_files" or "google_drive/download_file", it matches _LOCAL_TOOL_APPS and injects CrewAIPlatformFileUploadTool even though the user never requested it. Only a full app name like "google_drive" (without a slash) was intended to trigger injection of all local tools. The second block needs an elif or a guard to ensure it only fires for bare app names.

 

[cursor]

No path validation allows arbitrary file exfiltration

High Severity

The tool reads any file the process can access (expanduser + resolve follows ~ and symlinks) and uploads it to Google Drive with zero path restrictions. An LLM influenced by prompt injection could exfiltrate sensitive files like .env, SSH keys, or credentials. The existing FileWriterTool in the same codebase already implements path traversal protection — similar safeguards (allowlist, directory sandboxing) are missing here.