-
Notifications
You must be signed in to change notification settings - Fork 3
plat 078
PUL-DD9EDE3C: current browser oversized-result, production spill and every-folder-guard tool_output_folder tests pass; also covered by PLAT-200.
Resolved in SQLite for internal tracking with previous concern/detail records preserved in resolution events. Source/tests verified; deployed replay and historical business/module-result repair are not claimed. Full mapping: remaining-report audit.
PLAT-078 — spilled bridge tool output (large agent_browser snapshots) landed outside every granted read path
| Coordination | Value |
|---|---|
| Assigned agent | unassigned |
| Ticket state |
implemented — both contributing mechanisms are fixed; runtime reverify pending |
| Last synchronized | 2026-08-10 |
- Priority: P2 — a step gets an unrecoverable, unactionable failure when a browser snapshot is large enough to overflow the coding CLI's own MCP result cap
-
Owner: step execution folder guard (
setupExecutionFolderGuard,controller_agent_factory.go) -
Found on: PLAT-073 cluster F,
dd9ede3c(upwork): "agent_browser snapshot results continue to overflow the tool-result size limit post-v1.0.21-purification (toptal-scan-jobs 68,223 chars, search-find-and-shortlist 130,705 chars on 2026-08-07), and the spilled-result fallback read also fails as outside every workspace root."
Two independent, contributing mechanisms — only the first is fixed here:
-
agent_browser'ssnapshotcommand has no output-size cap. Claude Code's own MCP tool-result cap (independent of, and smaller than, mcpagent's own 128 KiB bridge-result limit) truncates a large snapshot and spills the untruncated copy to a location under its own CLI project directory — the exact same failure shape already named and fixed forread_skill(mcpagent/agent/skill.go:21-33,maxReadSkillBatchSize=1, "the coding CLI truncated it against its 25,000-token result cap, wrote the full copy under its own project directory, and told the agent to read that path — which the workspace folder guard forbids. The agent had no legal way to comply.").agent_browserhas no equivalent bound. -
MCP_TOOL_OUTPUT_DIR(mcpagent's own 128 KiB inline-truncation spill target) resolves outside the folder guard's grants. It's set to<CodingAgentWorkingDir>/tool_output_folder(mcpagent/agent/coding_agents_bridge.go:198-200), andCodingAgentWorkingDirresolves to the bare workflow root (resolveCodingAgentWorkingDir,pkg/orchestrator/base_orchestrator_agent_factory.go:174-183, fedbo.GetWorkspacePath()) — a sibling ofruns/thatsetupExecutionFolderGuardnever granted a normal execution step read access to. Confirmed against the live filesystem:workspace-docs/Workflow/<name>/tool_output_folder/exists as a sibling ofruns/,db/,execution/, holding spilled files up to 16 MB that a normal step could not read back.
setupExecutionFolderGuard (controller_agent_factory.go:427) now adds
<workspace-root>/tool_output_folder to readPaths for every step. This
closes mechanism 2 directly — a step that hits mcpagent's own 128 KiB spill
can now read the result back — without touching
resolveCodingAgentWorkingDir, which is shared by every coding-agent step
and would have been a far riskier, broader-blast-radius change to make just
for this one symptom.
Test: TestExecutionFolderGuardGrantsToolOutputFolderRead
(controller_agent_factory_test.go) — asserts the read grant exists and,
mirroring the sibling run-folder-widening test, that granting it does not
widen access to the bare workflow root.
The initial 6b688f51c implementation narrowed default arguments and
truncated the returned snapshot. That prevented an overflow, but it silently
changed the agent's requested evidence surface; it was immediately superseded.
The replacement runs the exact snapshot command the agent supplied. If the
raw result exceeds 24,000 runes, it returns a typed
SNAPSHOT_RESULT_TOO_LARGE error containing the raw rune/byte count and clear
retry options (--selector <css> or --depth <n>). It returns no partial
snapshot, does not inject --compact, and does not alter any explicit option.
The agent therefore makes the next evidence-scope decision itself.
This is not a regression of the folder-guard fix: the earlier change made an already-spilled mcpagent result readable; this change prevents an independent, smaller coding-CLI result limit from receiving an unbounded page tree at all. Tests cover exact argument preservation and the typed oversized-result error.
-
go build ./...clean. - New tests pass; full baseline
(
go test ./cmd/server/... ./pkg/orchestrator/agents/workflow/step_based_workflow/...) still shows exactly 22 pre-existing failures — no new failures. -
Not yet reverified live — requires a restart and an upwork run that
produces a large
agent_browsersnapshot beforedd9ede3ccan be closed.
- A step that triggers mcpagent's 128 KiB bridge-result spill can read the
spilled file back from
tool_output_folder/without a folder-guard denial. - A large snapshot returns
SNAPSHOT_RESULT_TOO_LARGEwith no transformed or partial evidence. - The retry is agent-chosen and explicit: a targeted selector or smaller depth.
Auto-synced from docs/ on main. Edit there, not here.