Summary

When sandbox is enabled with workspaceAccess: "rw", the ## Workspace section of the system prompt shows the host filesystem path (e.g. /home/user/.openclaw/workspace) instead of the container's working directory (/workspace). The agent trusts this path and fails when trying to use it via exec.

Steps to reproduce

1. Configure an agent with sandbox enabled:

   "agents": {
     "defaults": {
       "sandbox": {
         "mode": "all",
         "workspaceAccess": "rw"
       }
     }
   }

2. Start the gateway and send a message to the agent
3. The agent receives a system prompt containing:

   ## Workspace
   Your working directory is: /home/user/.openclaw/workspace
   

4. Inside the sandbox container, the actual working directory is /workspace
5. When the agent runs ls /home/user/.openclaw/workspace via exec, it gets No such file or directory

Expected behavior

The system prompt should show the container-side path:

Your working directory is: /workspace

Actual behavior

The system prompt shows the host-side path:

Your working directory is: /home/user/.openclaw/workspace

The agent tries to access this path inside the container, fails, and enters a confusion loop trying to reconcile the mismatch.

OpenClaw version

v2026.2.13

Operating system

Linux (aarch64, Docker gateway)

Install method

npm global

Logs, screenshots, and evidence

Root cause in src/agents/pi-embedded-runner/run/attempt.ts:

const effectiveWorkspace = sandbox?.enabled
    ? sandbox.workspaceAccess === "rw"
      ? resolvedWorkspace      // ← host path for rw
      : sandbox.workspaceDir
    : resolvedWorkspace;

// ...later:
buildEmbeddedSystemPrompt({
    workspaceDir: effectiveWorkspace,  // ← host path injected into prompt

For workspaceAccess: "rw", effectiveWorkspace is the host-side resolvedWorkspace (e.g. /home/user/.openclaw/workspace). This is passed to buildEmbeddedSystemPrompt as workspaceDir, which becomes Your working directory is: /home/user/.openclaw/workspace in the system prompt.

The container's actual workdir is DEFAULT_SANDBOX_WORKDIR (/workspace), but this value never reaches the prompt.

Impact and severity

• Affected: All sandbox users with workspaceAccess: "rw" (gateway mode)
• Severity: Medium — agents consistently fail on first file/directory operations, then waste tokens trying to reconcile the path mismatch
• Frequency: 100% reproducible
• Consequence: Degraded agent reliability in sandbox mode; agents hallucinate about filesystem state

Additional information

Related issues:

• Cron isolated agent does not pass sandboxInfo to system prompt #4171 — Same symptom in cron isolated agent (sandboxInfo not passed at all). PR Fix/sandbox containerworkdir rw access #4226 fixes agentWorkspaceMount for the ## Sandbox section but does not fix the ## Workspace section's workspaceDir.
• [Feature]: Sandbox should present container paths as the canonical path system for agents #16212 — Broader proposal to make container paths the canonical path system
• Sandbox path validation fails for container-internal paths (/workspace/...) #9560 — Sandbox path validation fails for container-internal paths

This bug is distinct from #4171: the gateway does pass sandboxInfo to buildEmbeddedSystemPrompt, so the ## Sandbox section is present. The problem is specifically that workspaceDir (used in ## Workspace) is the host path, not the container path.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)