Bug: Normal tool text outputs can degrade to (see attached image) placeholders in agent context
Summary
Normal OpenClaw tool text outputs can be delivered to the agent as literal (see attached image) placeholders instead of text. This makes the agent blind to ordinary command/status output.
This appears related to, but broader than, #75674. #75674 covered MCP resource results being converted to (see attached image), and was closed as fixed by #90728 / v2026.6.6 via MCP EmbeddedResource normalization. The current live repro is not limited to MCP resources: ordinary text tool results from multiple standard tools were affected.
Live repro context
Observed in a Discord main session on OpenClaw 2026.6.9 (82827d3) after provider/model churn involving github-copilot/gemini-3.1-pro-preview, fallback behavior, and later pinning to github-copilot/gpt-5.5.
Affected ordinary text outputs included:
exec command outputsession_status outputgh issue view 75674 --repo openclaw/openclaw --json ...read of a saved JSON file containing the fetched issue data- message-tool send/read result visibility in the affected session
A clean peer lane can retrieve the same source bytes normally. For example, gh issue view 75674 --repo openclaw/openclaw --json number,title,state,url,body returns normal JSON/text from an unaffected session, while the affected session receives (see attached image) in the agent-visible tool-result transcript/model context.
Concrete repro packet from live session
One affected boundary observed in the live Discord main session:
- Tool call shape: ordinary text-returning tool invocation, e.g.
exec / session_status / gh issue view ... --json ... / read of a saved JSON file.
- Expected source bytes: the tool runner completes and produces ordinary text output. A clean peer lane can retrieve the same bytes as text/JSON.
- Observed in affected session: the agent-visible tool-result transcript/model context contains the literal placeholder
(see attached image) instead of the text output.
Concrete example to verify from transcript before filing:
This indicates the source bytes exist and the tool call is not inherently image-producing; the failure is in tool-result content materialization into the agent-visible transcript/model context.
Expected behavior
Tool results whose payload is ordinary text/JSON/stdout should be passed to the agent as text in transcript/model context.
Actual behavior
The affected assistant instance sees (see attached image) instead of the text payload. This is not merely a UI rendering problem: the placeholder is what the agent receives, so the model cannot inspect the tool result bytes.
Related issues / scope boundaries
Impact
When this trips, the agent can no longer safely inspect basic tool output. It may incorrectly treat commands/files/API responses as image attachments or missing text, blocking debugging and making public upstream writes unsafe without a clean peer verifier.
Bug: Normal tool text outputs can degrade to
(see attached image)placeholders in agent contextSummary
Normal OpenClaw tool text outputs can be delivered to the agent as literal
(see attached image)placeholders instead of text. This makes the agent blind to ordinary command/status output.This appears related to, but broader than, #75674. #75674 covered MCP
resourceresults being converted to(see attached image), and was closed as fixed by #90728 / v2026.6.6 via MCP EmbeddedResource normalization. The current live repro is not limited to MCP resources: ordinary text tool results from multiple standard tools were affected.Live repro context
Observed in a Discord main session on OpenClaw
2026.6.9 (82827d3)after provider/model churn involvinggithub-copilot/gemini-3.1-pro-preview, fallback behavior, and later pinning togithub-copilot/gpt-5.5.Affected ordinary text outputs included:
execcommand outputsession_statusoutputgh issue view 75674 --repo openclaw/openclaw --json ...readof a saved JSON file containing the fetched issue dataA clean peer lane can retrieve the same source bytes normally. For example,
gh issue view 75674 --repo openclaw/openclaw --json number,title,state,url,bodyreturns normal JSON/text from an unaffected session, while the affected session receives(see attached image)in the agent-visible tool-result transcript/model context.Concrete repro packet from live session
One affected boundary observed in the live Discord main session:
exec/session_status/gh issue view ... --json .../readof a saved JSON file.(see attached image)instead of the text output.Concrete example to verify from transcript before filing:
gh issue view 75674 --repo openclaw/openclaw --json number,title,state,url,body,commentsreturns issue JSON; clean lane verified MCP tool result with type: "resource" is converted to "(see attached image)" placeholder #75674 title/body and closure note.(see attached image)/ unable to inspect the saved JSON viaread, while peer lanes could read the same issue normally.This indicates the source bytes exist and the tool call is not inherently image-producing; the failure is in tool-result content materialization into the agent-visible transcript/model context.
Expected behavior
Tool results whose payload is ordinary text/JSON/stdout should be passed to the agent as text in transcript/model context.
Actual behavior
The affected assistant instance sees
(see attached image)instead of the text payload. This is not merely a UI rendering problem: the placeholder is what the agent receives, so the model cannot inspect the tool result bytes.Related issues / scope boundaries
resource→(see attached image), closed as fixed by fix(agents): coerce non-text/image MCP tool-result blocks to text (fixes #90710) #90728 / v2026.6.6 MCP EmbeddedResource normalization.github-copilot/gpt-5.5encrypted-content replay/fallback poison. Mentioned only as operational context because gpt-5.5 is not a safe escape hatch during this failure; it should not be folded into this issue.Impact
When this trips, the agent can no longer safely inspect basic tool output. It may incorrectly treat commands/files/API responses as image attachments or missing text, blocking debugging and making public upstream writes unsafe without a clean peer verifier.