Summary

Verified that create_or_update_file imposes no server-side content size limit. The reported truncation is not reproducible via a controlled test and is not caused by the MCP server.

Why

Issue #2182 reported that create_or_update_file silently truncates large files (~500+ lines of shell script). Investigation confirms:

• No limit in tool code: content is read as a plain string, converted to []byte, and forwarded directly to the GitHub Contents API — no truncation, no max-size check.
• No limit in transport: stdio transport uses Go's json.Decoder with no buffer cap; message size is bounded only by system memory.
• Response already surfaces file size: MinimalFileContent.Size reflects the byte count stored on GitHub, giving callers a signal to detect a mismatch.
• The issue author's own controlled reproduction (600 lines, ~72 KB) did not reproduce truncation, pointing to content-dependent LLM behavior (e.g. heredocs, backslashes, quotes causing context-window or JSON-serialization issues at the client level) rather than a server bug.

No code change is required.

What changed

• No code changes — investigation only.

MCP impact

• No tool or API changes

Prompts tested (tool changes only)

• N/A

Security / limits

• No security or limits impact

Tool renaming

• I am not renaming tools as part of this PR

Lint & tests

• Linted locally with ./script/lint
• Tested locally with ./script/test

Docs

• Not needed

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.