openclaw - 💡(How to fix) Fix image_generate outputs should be accessible from sandbox workspace for follow-up workflows [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#75683Fetched 2026-05-02 05:31:50
View on GitHub
Comments
1
Participants
2
Timeline
1
Reactions
2
Author
Timeline (top)
commented ×1

image_generate returns a MEDIA: path under /home/<user>/.openclaw/media/tool-image-generation/..., but sandboxed agents cannot read that file or use it as input for follow-up tools such as exec, basecamp attach, local image processing, OCR/text verification, or archiving.

For agent workflows, generated media should ideally be materialized in a workspace-readable location, or exposed through a first-class copy/export handle.

Root Cause

A common agent media workflow is:

  1. Generate image with image_generate
  2. Inspect / verify it
  3. Optionally modify it locally
  4. Upload it elsewhere, e.g. Basecamp, website, archive, repo, etc.

Currently step 1 succeeds, but step 2+ fail unless the agent regenerates the image manually into /workspace via a separate script/API call. That defeats the purpose of having image_generate as a first-class tool.

Fix Action

Fix / Workaround

We generated poster mockups with image_generate. The output was visible in Telegram, but could not be uploaded to Basecamp from the agent because basecamp attach runs in the sandbox and only sees /workspace files. The workaround was to bypass image_generate and call the OpenAI Images API from a Python script to save the image directly under /workspace/media/generated/, then upload that file.

That workaround is unnecessary friction if generated tool media can be workspace-addressable.

Code Example

MEDIA:/home/aaajiao/.openclaw/media/tool-image-generation/image-1---c8371631-4715-4cd8-bebb-b8ac962cf45c.png

---

read /home/aaajiao/.openclaw/media/... -> Path escapes sandbox root (~/.openclaw/workspace)
exec ls /home/aaajiao/.openclaw/media/... -> No such file or directory
RAW_BUFFERClick to expand / collapse

Summary

image_generate returns a MEDIA: path under /home/<user>/.openclaw/media/tool-image-generation/..., but sandboxed agents cannot read that file or use it as input for follow-up tools such as exec, basecamp attach, local image processing, OCR/text verification, or archiving.

For agent workflows, generated media should ideally be materialized in a workspace-readable location, or exposed through a first-class copy/export handle.

Observed

A successful image generation returned:

MEDIA:/home/aaajiao/.openclaw/media/tool-image-generation/image-1---c8371631-4715-4cd8-bebb-b8ac962cf45c.png

The user can see the image in chat, but the agent cannot access it from the sandbox workspace:

read /home/aaajiao/.openclaw/media/... -> Path escapes sandbox root (~/.openclaw/workspace)
exec ls /home/aaajiao/.openclaw/media/... -> No such file or directory

So the generated image can be delivered to the user, but cannot be composed into the next step of the workflow from inside the sandbox.

Why this matters

A common agent media workflow is:

  1. Generate image with image_generate
  2. Inspect / verify it
  3. Optionally modify it locally
  4. Upload it elsewhere, e.g. Basecamp, website, archive, repo, etc.

Currently step 1 succeeds, but step 2+ fail unless the agent regenerates the image manually into /workspace via a separate script/API call. That defeats the purpose of having image_generate as a first-class tool.

Expected behavior

One of these would solve it:

  • Save/copy generated media into a workspace-readable path such as /workspace/media/generated/...
  • Or return both paths:
    • delivery path for MEDIA: rendering
    • sandbox/workspace path for agent follow-up work
  • Or provide a first-class media export/copy tool that can copy MEDIA: outputs into the current workspace
  • Or allow tools that accept file inputs to consume prior MEDIA: artifact references directly

Environment

  • OpenClaw: v2026.4.29
  • Agent: main session, sandboxed runtime
  • Workspace: /workspace
  • Host repo: /home/aaajiao/.openclaw/workspace
  • Tool: image_generate

Concrete use case

We generated poster mockups with image_generate. The output was visible in Telegram, but could not be uploaded to Basecamp from the agent because basecamp attach runs in the sandbox and only sees /workspace files. The workaround was to bypass image_generate and call the OpenAI Images API from a Python script to save the image directly under /workspace/media/generated/, then upload that file.

That workaround is unnecessary friction if generated tool media can be workspace-addressable.

extent analysis

TL;DR

Save generated media into a workspace-readable path, such as /workspace/media/generated/..., to enable sandboxed agents to access and process the files.

Guidance

  • Modify the image_generate tool to save generated media in a workspace-readable location, such as /workspace/media/generated/..., in addition to the current MEDIA: path.
  • Consider returning both paths (delivery path for MEDIA: rendering and sandbox/workspace path) to allow for flexible handling of generated media.
  • Develop a first-class media export/copy tool that can copy MEDIA: outputs into the current workspace, providing a workaround for existing tools.
  • Update tools that accept file inputs to consume prior MEDIA: artifact references directly, reducing the need for manual file handling.

Example

No code snippet is provided as the issue does not contain sufficient technical details for a specific implementation.

Notes

The proposed solutions require modifications to the image_generate tool or the introduction of new tools and features, which may involve significant development and testing efforts.

Recommendation

Apply a workaround by saving generated media into a workspace-readable path, such as /workspace/media/generated/..., to enable sandboxed agents to access and process the files, as this approach is more feasible and less invasive than modifying existing tools or introducing new features.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

One of these would solve it:

  • Save/copy generated media into a workspace-readable path such as /workspace/media/generated/...
  • Or return both paths:
    • delivery path for MEDIA: rendering
    • sandbox/workspace path for agent follow-up work
  • Or provide a first-class media export/copy tool that can copy MEDIA: outputs into the current workspace
  • Or allow tools that accept file inputs to consume prior MEDIA: artifact references directly

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix image_generate outputs should be accessible from sandbox workspace for follow-up workflows [1 comments, 2 participants]