openclaw - 💡(How to fix) Fix [Bug]: media://inbound/ path resolution fails for agents with custom workspace (non-sandbox), causing ENOENT errors and broken image access

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When an agent has a custom workspace (e.g. workspace-regi), the media://inbound/ reference injected into the prompt resolves to a broken workspace-relative path (workspace-regi\media:\inbound...) instead of the correct global path (C:\Users\centr.openclaw\media\inbound). This affects both Telegram images and the agent's ability to read memory files via read/exec tools on Windows.

Steps to reproduce

1. Configure two agents, one with default workspace (main) and one with custom workspace (workspace: "~/.openclaw/workspace-regi", agent id: "regi"), both without sandbox.
2. Bind both agents to separate Telegram accounts.
3. Send an image to each agent via Telegram.
4. Observe the path the agent uses to try to access the image.
5. Also observe: on session startup, the agent with custom workspace tries to read memory/YYYY-MM-DD.md — if the file doesn't exist yet, ENOENT is thrown and logged to the terminal.

Expected behavior

media://inbound/ references should resolve to the global ~/.openclaw/media/inbound/ absolute path regardless of the agent's workspace setting. The fix implemented for #63285 (sandbox agents) should be extended to non-sandbox agents with custom workspaces. The path resolution must be workspace-independent for inbound media since the staging pipeline always writes to the global path. For the read/ENOENT issue on session startup: the Gateway should either auto-create the daily memory file if missing, or the agent framework should handle ENOENT gracefully instead of logging errors.

Actual behavior

1. Terminal log fills with ENOENT: read failed: ENOENT: no such file or directory, access 'C:\Users\centr\.openclaw\workspace-regi\memory\2026-05-27.md' — the read tool uses the workspace path correctly but the agent has no way to handle missing files.

2. media://inbound/xxx.jpg reference resolves incorrectly:

   • Workspace: workspace-regi
   • Gateway injects: media://inbound/xxx.jpg
   • Expected: C:\Users\centr.openclaw\media\inbound\xxx.jpg
   • Actual: workspace-regi\media:\inbound\xxx.jpg (broken)

3. The only workaround is to hardcode paths in SOUL.md/MEMORY.md files, instructing the agent to extract filenames from media:// references and reconstruct full paths manually. This works inconsistently — model instruction following varies between providers.

OpenClaw version

2026.5.20 (e510042)

Operating system

Windows 11 Pro (10.0.26200) x64

Install method

npm global

Model

custom-api-deepseek-com/deepseek-v4-pro and ollama-cloud/deepseek-v4-pro:cloud

Provider / routing chain

Direct DeepSeek API + Ollama Cloud proxy

Additional provider/model setup details

The bug is independent of the model/provider — it's a Gateway-level path resolution issue. Both agents use different providers (DeepSeek direct API vs Ollama Cloud proxy), yet both are affected.

Logs, screenshots, and evidence

Terminal log excerpt (repeating every session):

`07:38:11 [tools] read failed: ENOENT: no such file or directory, access 'C:\Users\centr\.openclaw\workspace-regi\memory\2026-05-27.md'`

The media://inbound/ path corruption is confirmed via agent prompt inspection — the reference resolves to `workspace-regi\media:\inbound\...` instead of `C:\Users\centr\.openclaw\media\inbound\...`

Impact and severity

Affected: Any agent with a non-default workspace on Windows, sandbox: off Severity: Medium-high — terminal log pollution (ENOENT spam every session) + broken image access requiring brittle MD-file workarounds Frequency: 100% reproducible — every session startup + every image message Consequence: Image processing is slowed down or fails as agents search for files at wrong paths; terminal log fills with ENOENT noise

Additional information

Related issues:

• #63285 (closed) — same root cause, fix implemented for sandboxed agents only
• #43378 (Telegram, closed)
• #32362 (Telegram xlsx, open/stale)

The sandbox fix rewrites MediaPath for sandbox agents; the same logic is needed for non-sandbox agents with custom workspaces.

Current workaround (brittle, model-dependent):

• Agent with exec: use Get-ChildItem to find actual file paths in the global media/inbound directory
• Agent without exec: hardcode the path in SOUL.md/MEMORY.md, extract filename from media:// reference, reconstruct full path

The workaround works inconsistently — model instruction following varies between providers, causing intermittent failures.