Bug Description

The create_or_update_file tool silently truncates large files (~500+ lines) when pushing to GitHub. The tool reports success (returns a valid commit SHA and file metadata), but the file content that lands on GitHub is incomplete. There is no error or warning.

Real-World Impact

This caused real damage in our project: an install.sh script (~500+ lines) was updated via the MCP create_or_update_file tool. The tool reported success, but the file that landed on GitHub was truncated, breaking the installer for all users who ran it. Because the tool returned a success response with a valid commit SHA, there was no indication anything went wrong until users reported failures.

Reproduction Steps

1. Generate a large file with 500+ lines of content (e.g., a shell script with functions, heredocs, variables, special characters)
2. Use the create_or_update_file MCP tool to push it to a repository
3. The tool returns success with a valid commit SHA and file size
4. Retrieve the file via gh api repos/{owner}/{repo}/contents/{path} and decode from base64 — compare line counts

Expected Behavior

• The complete file content should be pushed to GitHub
• If the file is too large for the tool to handle, the tool should return an error rather than silently truncating

Actual Behavior

• The file is silently truncated (tail end of the file is cut off)
• The tool returns a success response with a commit SHA
• No error or warning is produced

Reproduction Notes

A controlled test with 600 identical short comment lines (~120 chars each, ~72KB total) pushed via create_or_update_file did not reproduce the truncation — all 600 lines arrived intact. This suggests the truncation may be:

• Content-dependent: triggered by special characters in shell scripts (heredocs, variable expansions, backticks, quotes, etc.)
• Size-dependent at higher thresholds: the original truncated file may have been larger in byte size
• Related to the MCP client-server serialization: the content parameter may be truncated during JSON serialization for certain content patterns

The original truncated file was a real shell script with varied content (functions, heredocs, set -e, variable expansions, etc.).

Severity

High — This is silent data loss. The tool reports success while delivering truncated content. Users have no way to detect the truncation without independently verifying every file push. This fundamentally undermines trust in the tool for file operations.