openclaw - 💡(How to fix) Fix [Bug]: Inbound media staged to global ~/.openclaw/media/inbound/ instead of agent workspace path, making files unreachable in sandboxed agents [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When a file is uploaded to Slack and received by a sandboxed agent, the inbound media staging pipeline writes the file to the global ~/.openclaw/media/inbound/ path. The path injected into the agent's prompt also points to this global location. For sandboxed agents, the global host path is outside the sandbox mount and is unreachable — the agent cannot access, read, or ingest the file.

The expected behavior is that inbound media for an agent with a configured workspace should be staged to <workspace_root>/media/inbound/, which is bind-mounted into the sandbox and accessible.

Related prior issues (same root cause, different channel):

• #43378 — same bug reported for Telegram, marked closed — fix appears not to have been extended to Slack
• #32362 — same bug for Telegram xlsx attachments, open/stale

Steps to reproduce

1. Deploy a sandboxed agent with a workspace configured (e.g. workspace: /root/workspace-sales, Docker sandbox mode: all, bind-mount workspace-root → /workspace)
2. Upload any file (PDF tested) to the Slack channel bound to the sandboxed agent
3. Observe: agent reports the file is not found or not accessible
4. Check ~/.openclaw/media/inbound/ — the file is present at the global path
5. Check <workspace_root>/media/inbound/ — directory is empty; file was never written there

Expected behavior

Inbound media for a sandboxed agent with a configured workspace root should be staged to:

<workspace_root>/media/inbound/<filename>

The path injected into the agent's prompt should match this workspace-relative path, which resolves to /workspace/media/inbound/<filename> inside the sandbox.

Actual behavior

File is staged to:

/root/.openclaw/media/inbound/76e093ba...pdf   ← global host path (confirmed written)

Path injected into agent prompt:

/root/.openclaw/media/inbound/76e093ba...pdf   ← inaccessible from inside sandbox

Workspace media directory:

/root/workspace-sales/media/inbound/   ← empty; never received a file since provisioning (2026-04-07)

Agent response: "I don't see the GenAIPI-Leadership-Deck.pdf attached in the workspace."

Mount evidence (from /proc/1/mountinfo inside sandbox)

/root/workspace-sales → /workspace   (bind mount, rw)

The global ~/.openclaw/media/inbound/ path has no corresponding mount inside the sandbox. Files written there are invisible to the sandboxed agent process.

OpenClaw version

2026.4.2 (d74a122)

Operating system

Linux 6.8.0-100-generic x86_64 (Ubuntu)

Install method

npm global

Agent configuration (affected agent)

{
  "id": "sales",
  "workspace": "/root/workspace-sales",
  "sandbox": {
    "mode": "all",
    "scope": "agent",
    "workspaceAccess": "rw",
    "docker": {
      "image": "openclaw-sandbox-sales:bookworm-slim",
      "network": "openclaw-sales-sandbox"
    }
  }
}

Impact and severity

High — All inbound file uploads (any type) to any sandboxed agent are silently unreachable. The agent receives no error; it simply cannot find the file.

Evidence classification

Confirmed facts

• Global path ~/.openclaw/media/inbound/ receives the file — physically present there
• Sandbox bind-mount: /root/workspace-sales → /workspace (rw) — confirmed from /proc/1/mountinfo
• Path injected into agent prompt points to global host path, not workspace path
• <workspace_root>/media/inbound/ has been empty since agent provisioning (2026-04-07)
• Agent could not access the uploaded PDF; reported file not found in #sales Slack channel (2026-04-08 ~05:48 UTC)

Likely contributing factors

• Staging pipeline uses a hardcoded or globally-resolved path rather than resolving <agent.workspace>/media/inbound/ when the receiving agent has a workspace configured
• The prompt path injection step runs from the same global-path value without a workspace-relative translation step

Unknowns / needs verification

• Whether the bug is in the write step (file never written to workspace path), the path injection step (file written correctly but wrong path injected), or both
• Whether agents with a workspace configured but not sandboxed are also silently affected
• Whether files:read Slack scope is present on the bot token (separate potential issue)

Suspected root cause

The inbound media staging pipeline resolves the destination path globally (~/.openclaw/media/inbound/) without checking whether the target agent has a workspace configured. When a workspace is present, both the staging write and the prompt-injected path should resolve to <agent.workspace>/media/inbound/.

Note: This is a path-resolution bug in the staging pipeline, not a sandbox bind-mount design gap. The fix should be in staging path resolution, not in adding additional bind-mounts.

Workaround

None for sandboxed agents. Files must currently be shared via a path accessible inside the sandbox (e.g. Google Drive synced to workspace).

Non-sandboxed agents: unaffected — global path is host-accessible.

Recent changes

• Sandboxed sales agent provisioned 2026-04-07 (new deployment, first file upload attempt)
• No OpenClaw version change immediately prior to discovery

Logs, screenshots, and evidence

• Mount proof from /proc/1/mountinfo inside sandbox: /root/workspace-sales → /workspace (bind mount, rw)
• Staged file location: /root/.openclaw/media/inbound/76e093ba...pdf (present on host)
• Workspace inbound dir: /root/workspace-sales/media/inbound/ (empty since 2026-04-07)
• Agent response logged in #sales Slack channel at approx. 2026-04-08 05:48 UTC

Additional information

The sandboxed Sales Jarvis agent was asked to ingest GenAIPI-Leadership-Deck.pdf uploaded to the #sales Slack channel. The agent responded that the file was not present in the workspace. Investigation confirmed the staging path mismatch described above.

See also: #43378 (same bug, Telegram, closed), #32362 (same bug, Telegram xlsx, open/stale).