openclaw - 💡(How to fix) Fix `read` tool remains hard-bound to workspace root despite broader FS policy / runtime patches [1 comments, 2 participants]

read tool remains hard-bound to workspace root despite broader FS policy / runtime patches

Summary

The read tool in this session still rejects paths outside ~/.openclaw/workspace with errors like:

• Path escapes sandbox root (~/.openclaw/workspace): /opt/homebrew/...
• Path escapes sandbox root (~/.openclaw/workspace): /Users/.../.openclaw/openclaw.json

This persists even after:

• setting broader FS policy
• restarting the gateway
• patching gateway/runtime sandbox path resolution
• patching openshell sandbox path resolution

That suggests the active read tool path for this surface/session is enforced by an outer tool-host layer that still hard-binds to the workspace root.

Environment

• OpenClaw 2026.4.22
• macOS
• workspace: /Users/gabrielschwartz/.openclaw/workspace

Reproduction

Config state tested

• tools.fs.workspaceOnly=false was tested
• later restored to true
• the issue persisted while broader access was enabled

Steps

1. Start from a normal direct session.
2. Attempt to use the read tool on either:
   • /opt/homebrew/lib/node_modules/openclaw/skills/healthcheck/SKILL.md
   • /Users/gabrielschwartz/.openclaw/openclaw.json

Actual result

read returns:

Path escapes sandbox root (~/.openclaw/workspace): /opt/homebrew/lib/node_modules/openclaw/skills/healthcheck/SKILL.md

and similarly for ~/.openclaw/openclaw.json.

Control / comparison

Host exec can read the same files successfully via Python/cat, so this is not:

• file absence
• host permission failure
• bad path
• bad openclaw.json

Expected behavior

If effective FS policy permits broader access, read should either:

1. read the file successfully, or
2. fail according to the same effective runtime policy actually in force

At minimum, all layers should agree on the same root policy.

Actual behavior

read remains hard-bound to:

• ~/.openclaw/workspace

even when lower/runtime layers were patched to allow readonly access to:

• ~/.openclaw
• /opt/homebrew/lib/node_modules/openclaw

This indicates inconsistent path enforcement across layers.

Traced code layers

1) Gateway/runtime tool assembly layer

File:

• /opt/homebrew/lib/node_modules/openclaw/dist/pi-tools-D-xZrhRV.js

Relevant logic:

• workspaceOnly = fsPolicy.workspaceOnly
• read tool wrapped with:
  • wrapToolWorkspaceRootGuard(...)
  • wrapToolWorkspaceRootGuardWithOptions(...)

Observed around:

• lines 846-860

This layer appears configurable and patchable.

2) General sandbox path resolver

File:

• /opt/homebrew/lib/node_modules/openclaw/dist/sandbox-DA33PQCZ.js

Relevant function:

• resolveSandboxFsPathWithMounts(params)

Observed fallback:

resolveSandboxPath({
  filePath: input,
  cwd: params.cwd,
  root: params.defaultWorkspaceRoot
});
throw new Error(`Path escapes sandbox root (${params.defaultWorkspaceRoot}): ${input}`);

This was patchable locally, but patching it did not change this chat session’s read behavior.

3) openshell extension sandbox path layer

File:

• /opt/homebrew/lib/node_modules/openclaw/dist/extensions/openshell/index.js

Observed logic only allows paths inside:

• workspace root
• agent root

Observed throw:

throw new Error(`Path escapes sandbox root (${workspaceRoot}): ${params.filePath}`);

Observed around:

• lines 442-466

This was also patchable locally, but patching it still did not change this session’s read behavior.

4) Outer tool-host/session layer (suspected actual active layer)

Evidence:

• After patching layers 2 and 3 and restarting, read in this chat still returned the same workspace-root error.
• Therefore the active read tool for this session is likely served by another outer wrapper/tool-host layer not covered by the patched installed gateway files.

This appears to be the real bug target.

Why this is a bug

There is a policy mismatch:

• lower/internal runtime layers are configurable and patchable
• but the user-facing read tool for this session still enforces a stricter workspace-only boundary
• the failure message stays anchored to ~/.openclaw/workspace regardless of broader effective settings attempted below

So the product currently behaves as if:

• config says one thing
• inner runtime may do another
• outer tool host still does a third

That inconsistency is the bug.

Recommended fix target

Primary target:

• the outer tool-host implementation that serves the read tool for direct chat sessions

Recommended fix:

1. Find the topmost read path validator actually used by this session type/surface.
2. Make it consume the same effective FS policy as the runtime:
   • same workspaceOnly resolution
   • same allowed-root expansion behavior
3. Ensure all read path guards share one canonical resolver instead of duplicating workspace-root checks.

Minimum acceptable fix

If broader FS access is enabled, read should allow readonly access to approved roots like:

• config dir / state dir (~/.openclaw)
• installed skill dir (/opt/homebrew/lib/node_modules/openclaw)

while keeping write/edit/apply_patch guarded separately.

Better fix

Unify path enforcement so:

• read
• write
• edit
• sandbox bridge
• extension bridge
• tool host

all derive from one effective FS policy implementation.

Workaround

A workaround that works today is using host exec to read excerpts.

That confirms the remaining problem is specific to the read tool path guard, not host access itself.