Repository navigation
[Automated] Draft docs (kagent): feat(sandbox): read_sandbox_file returns text pages and images - #600
Merged
Merged
Conversation
…urns text pages and images Signed-off-by: GitHub Action <action@github.com>
Verified every number against the merged kagent#3120: maxSandboxPageBytes, maxSandboxImageBytes, defaultSandboxReadLines, and maxSandboxLineBytes in go/core/internal/mcp/sandboxes.go. The draft's figures were right; its precision and coverage were not. - A page holds at most 2000 lines, not exactly 2000. The draft read as wrong for any file shorter than a page. - "A line longer than 2000 bytes is cut" left the reader unable to tell a dropped line from a truncated one. The code truncates to 2000 bytes and appends a [line cut] marker. - Paging was undocumented where it matters: offset is a 1-based line number, and a short page reports the offset to continue from. Naming offset and limit without either fact does not let a reader page. - An image over 10 MiB returns a message asking for a smaller copy. The draft's "other file types return a description" did not cover it. - Condition before command, per ste.md: the trailing "when" clause moves to the front of the sentence. - Dropped the "Unlike write_sandbox_file and read_sandbox_outputs" clause, which restated the contrast the preceding paragraph drew. - Split the seven-sentence block into three paragraphs, one per result shape. Added the three file tools to the tool-binding example above, which listed only lifecycle tools and so named none of the tools this section discusses. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Rachael Graham <rachael.graham@solo.io>
Author
Docs preview
Both are uploaded Worker versions and serve no production traffic. |
Rachael-Graham
approved these changes
Oct 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
kagent-dev/kagent#3120 — feat(sandbox): read_sandbox_file returns text pages and images
Docs versions:
1.x(first shipped in v1.0.0-alpha12)What changes for users: The sandbox MCP
read_sandbox_filetool now returns content that a model can read directly instead ofdata_base64. Text returns as numbered, paged lines; PNG, JPEG, and GIF files up to 10 MiB return as images; other file types return a description.What the docs now say: The Standalone sandboxes page now separates
read_sandbox_filefrom the base64 transfer tools. Readers learn thatwrite_sandbox_fileandread_sandbox_outputsstill use base64, whileread_sandbox_fileusesoffsetandlimitfor text paging and returns images directly.Not verified: No cluster was configured, so the MCP calls are unrun.
How
kagent-3120was drafted, and what was not verifiedPlan, and what changed it
docs-site/content/kagent/1.x/about/substrate-runtime/standalone-sandboxes.md, and the code-path target does not describe sandbox file reads.Why a documentation change is necessary
The pull request changes the user-visible result shape of
read_sandbox_file: the tool no longer returnsdata_base64, and it can return text pages or image content directly. The existing Standalone sandboxes page said every MCP transfer or output read was base64, bounded at 1 MiB, and offset-based. That statement is now wrong forread_sandbox_file, so a reader building or debugging an agent would expect the old structured result.What changed on disk
docs-site/content/kagent/1.x/about/substrate-runtime/standalone-sandboxes.md: Corrects the MCP transfer-limit paragraph and documents the currentread_sandbox_fileresult shapes.How to verify this change
kagent-apiRemoteMCPServer to an AgentTemplate with the sandbox file tools, then have the agent callread_sandbox_filefor a text file in the Sandbox.1\tfrom MCP, instead of adata_base64field. Reading a PNG, JPEG, or GIF file that is at most 10 MiB should return an image attachment.How the pages were chosen (triage report)
Draft a documentation change
kagent-dev/kagent#3120 — feat(sandbox): read_sandbox_file returns text pages and images
kagent-dev/websiteread_sandbox_filereturns base64, which models can only read by decoding it as output tokens. It now behaves like Claude Code's nativeReadtool:.claude/skills/kagent/references/sandboxes.mddocs/architecture/sandboxes.mdgo/harness/claude/config/config.gogo/harness/codex/config/config.goWarnings
Draft branch:
pr-tracker-draft-kagent-3120Important
The test suite has not run on this pull request. It was opened by
github-actions[bot], and GitHub does not start workflows for pull requests opened with the repository's own token. This repository's checks are held asaction_requireduntil somebody presses Approve and run on the Checks tab. Checks that come from GitHub Apps rather than Actions, such as DCO, run on their own.Please approve the checks before reviewing the content: an absence of failures here means the tests have not run, not that they passed.