fix(agents): materialize sandbox skills for rw sandboxes by brokemac79 · Pull Request #90798 · openclaw/openclaw

brokemac79 · 2026-06-06T01:03:12Z

Summary

Fixes workspaceAccess: "rw" sandboxes so non-workspace skills are materialized into a sandbox-readable, read-only skills workspace instead of advertising host paths the agent cannot read.
Threads the materialized skills workspace through Docker, browser, SSH, local/remote fs bridges, read-tool workspace guards, embedded run prompts, and compaction prompt rebuilds.
Documents the generated read-only sandbox skill path at /workspace/.openclaw/sandbox-skills/skills.
Keeps generated skills out of user-owned project workspace paths, including shared rw sandboxes, while preserving workspace-owned .openclaw/sandbox-skills content.
Intentionally out of scope: changing sandbox policy semantics, broad skill loader refactors, or weakening workspace-only write/edit/apply_patch boundaries.

Linked context

Related: closed/unmerged PR #48034 attempted this area but did not make the sync reachable.

This was picked up from the specific-issue queue after ClawSweeper noted: no current fix is present, the related closed PR was unmerged, and the best path is a scoped maintainer-reviewed sandbox/skills fix.

Real behavior proof (required for external PRs)

Behavior or issue addressed: In workspaceAccess: "rw", sandboxed agents could see non-workspace skill host paths in the prompt but could not read them because workspace-only/sandbox path guards rejected those paths.
Real environment tested: Local OpenClaw checkout on Windows using the repo Docker sandbox image built from scripts/docker/sandbox/Dockerfile; the live container was Debian 12 (openclaw-sandbox:bookworm-slim).
Exact steps or command run after this patch:

docker build -t openclaw-sandbox:bookworm-slim -f scripts/docker/sandbox/Dockerfile scripts/docker/sandbox
node --import tsx --input-type=module <inline proof script>

The proof script used real syncSkillsToWorkspace(), resolveReadOnlyWorkspaceSkillMounts(), appendWorkspaceMountArgs(), workspaceAccess: "rw", and the bundled skills/healthcheck/SKILL.md skill.

Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

image=openclaw-sandbox:bookworm-slim
workspace_access=rw
synced_skill=C:\Users\marti\AppData\Local\Temp\openclaw-90410-docker-proof-eBrpxn\workspace\.openclaw\sandbox-skills\skills\healthcheck\SKILL.md
read_only_mounts=[
  {
    "hostPath": "C:\\Users\\marti\\AppData\\Local\\Temp\\openclaw-90410-docker-proof-eBrpxn\\workspace\\.openclaw\\sandbox-skills\\skills",
    "containerPath": "/workspace/.openclaw/sandbox-skills/skills"
  }
]
docker_exit=0
container="Debian GNU/Linux 12 (bookworm)"
workspace_access_test=begin
workspace-write-ok
skill_read_test=begin
2:name: healthcheck
skill_write_test=begin
skill_write=blocked
bash: line 1: /workspace/.openclaw/sandbox-skills/skills/healthcheck/SKILL.md: Read-only file system
host_workspace_write="workspace-write-ok"
host_skill_unchanged=true

Observed result after fix: syncSkillsToWorkspace() materialized the bundled healthcheck skill into the sandbox skills workspace; the same mount helpers used by Docker sandboxing mounted that materialized skill root at /workspace/.openclaw/sandbox-skills/skills; the live container could write to /workspace, could read the bundled skill at the rewritten path, and could not mutate the skill file through the mounted path. The host materialized SKILL.md remained unchanged after the write attempt.
What was not tested: Live SSH and browser-backend runtime proof were not run; those paths are covered by code/tests in this PR. Maintainers can ask for broader backend proof if they want runtime coverage beyond Docker.
Proof limitations or environment constraints: This is local Docker proof, not Crabbox/Testbox or Mantis. Per the session constraint, I did not rely on local Crabbox for proof. Mantis remains unavailable here; direct Crabbox run also timed out earlier and is not part of the proof claim.
Before evidence (optional but encouraged): Issue [Bug]: Non-workspace skills are inaccessible to the agent when sandbox is in workspaceAccess: "rw" mode #90410 includes the source-level failing behavior; the added tests encode the missing rw sandbox skill visibility path and workspace shadow/data-loss cases. ClawSweeper also confirmed current main source repro: current main skips skill sync for workspaceAccess: "rw" and keeps host-path skill snapshots.

Tests and validation

Commands run for the code commit:

node scripts/run-vitest.mjs src/agents/agent-tools.read.workspace-root-guard.test.ts src/agents/embedded-agent-runner/sandbox-skills.test.ts src/skills/loading/workspace-load.test.ts src/skills/runtime/embedded-run-entries.test.ts src/agents/sandbox.resolveSandboxContext.test.ts src/agents/sandbox/ssh-backend.test.ts src/agents/sandbox/workspace-mounts.test.ts src/agents/sandbox/workspace-skills-bridge-readonly.test.ts src/agents/agent-tools.sandbox-mounted-paths.workspace-only.test.ts src/skills/loading/workspace-sync.test.ts src/skills/loading/workspace-bundled-allowlist.test.ts src/skills/loading/workspace-precedence.test.ts
corepack pnpm tsgo:core
corepack pnpm tsgo:core:test
corepack pnpm oxlint <touched files>
git diff --check
node scripts/check-changed.mjs --dry-run --base origin/main
PYTHONIOENCODING=utf-8 python .agents/skills/autoreview/scripts/autoreview --mode branch --base origin/main
docker build -t openclaw-sandbox:bookworm-slim -f scripts/docker/sandbox/Dockerfile scripts/docker/sandbox
node --import tsx --input-type=module <inline Docker proof script>

Docs follow-up validation on cbf70880f443be436fb122145ff8fae190b1732f:

git diff --check
node scripts/check-docs-mdx.mjs docs/gateway/sandboxing.md
node_modules/.bin/oxfmt.cmd --check docs/gateway/sandboxing.md
node scripts/check-changed.mjs --dry-run --base origin/main

Docs validation limitation: corepack pnpm format:docs:check, corepack pnpm docs:check-mdx, and corepack pnpm lint:docs could not start because local pnpm attempted an install and aborted non-interactively with ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY. The direct MDX and formatter checks above passed. Commit was made with --no-verify for the same local hook/pnpm prompt reason.

Regression coverage added/updated:

rw sandbox skill sync target uses sandbox-owned materialized workspace, not user workspace.
Shared rw sandbox materialization uses a stable sandbox state path and preserves user-owned .openclaw/sandbox-skills content.
Docker/browser/read-only mount state includes materialized skills.
Local and remote fs bridges protect materialized skill roots as read-only.
SSH backend uploads/refetches materialized skills for fresh and reused runtimes.
Sandbox prompt rebuild drops host snapshots, loads workspace-only materialized skills, rewrites prompt paths to /workspace/.openclaw/sandbox-skills/..., and preserves remote eligibility filtering.
Read-tool guard normalizes container paths before choosing read-only overlay mounts.

Risk checklist

Did user-visible behavior change? Yes.

Did config, environment, or migration behavior change? No.

Did security, auth, secrets, network, or tool execution behavior change? Yes, sandbox file visibility changes for skill files.

Highest-risk area: sandbox filesystem boundaries for read-only skill materialization.

Risk mitigation: generated skills are mounted/read through explicit read-only/protected skill roots; write/edit/apply_patch boundaries remain workspace-only; shared rw materialization lives in sandbox state rather than user project paths; focused tests and live local Docker proof cover the read/write boundary requested by ClawSweeper.

Current review state

Current head: cbf70880f443be436fb122145ff8fae190b1732f.

CI state: green on the docs-only head. CI, CodeQL, CodeQL Critical Quality, OpenGrep PR Diff, and Workflow Sanity all completed successfully.

ClawSweeper state: latest re-review completed successfully at 2026-06-06 02:43 UTC and says Result: ready for maintainer review; proof is sufficient; patch quality is platinum hermit. Remaining item is human sandbox/security owner acceptance for the new read-only sandbox skill exposure.

Codex review: direct codex review --base origin/main repeatedly timed out in this environment, so I used the repo-local structured autoreview helper with Codex engine. Accepted/actionable findings were addressed; final local autoreview result was clean with overall patch correctness 0.83. ClawSweeper's latest re-review also reports overall correctness: patch is correct.

Label note: ClawSweeper's durable review is ready-for-maintainer, but the status: waiting on author label did not get removed by the label router. This account cannot mutate labels directly, so I asked @clawsweeper status to reconcile the stale label.

Still waiting on: human sandbox/security maintainer review of the boundary. No merge, land, or automerge requested.

clawsweeper · 2026-06-06T01:05:07Z

Codex review: needs maintainer review before merge. Reviewed June 7, 2026, 4:31 PM ET / 20:31 UTC.

Summary
The branch materializes eligible non-workspace skills into a generated read-only skills workspace for workspaceAccess: "rw" sandboxes and threads that root through sandbox backends, filesystem bridges, read guards, embedded prompts, docs, and regression tests.

PR surface: Source +837, Tests +849, Docs 0. Total +1686 across 36 files.

Reproducibility: yes. Source inspection of current main shows workspaceAccess: "rw" uses the agent workspace and skips the existing skill sync path, so non-workspace skill prompt paths remain host paths that sandbox read guards reject.

Review metrics: 1 noteworthy metric.

New sandbox-visible root: 1 generated read-only skill root added. Maintainers should explicitly review the new /workspace/.openclaw/sandbox-skills/skills exposure because it changes what rw sandboxed agents can read.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Get explicit sandbox/security owner acceptance for the read-only skill exposure.
[P2] Request live SSH, OpenShell, or browser-backend proof only if owners want backend-specific confirmation before merge.

Risk before merge

[P1] Merging intentionally makes eligible managed, bundled, and plugin skill files readable inside rw sandboxes through a generated read-only root; the guards look deliberate, but sandbox/security owners need to accept that boundary change.
[P1] The supplied real behavior proof covers the Docker-style rw path, while SSH, OpenShell, and browser bridge behavior is supported by source and tests rather than live backend proof.

Maintainer options:

Accept After Owner Review (recommended)
A sandbox/security owner can accept the read-only skill exposure after reviewing the current-head code, tests, Docker proof, and CI state.
Ask For Backend-Specific Proof
If owners want stronger confidence before accepting the boundary change, request live SSH, OpenShell, or browser-backend proof that skills are readable but not writable.
Pause For Boundary Redesign
If exposing managed or bundled skills inside rw sandboxes is not an acceptable policy, pause this PR and redesign the sandbox skill API instead of merging the current approach.

Next step before merge

[P2] The remaining action is human sandbox/security owner review and current-head validation, not an automated code repair.

Security
Cleared: No concrete vulnerability or supply-chain issue was found in the diff; the intentional sandbox read-boundary expansion remains a maintainer merge-risk decision.

Review details

Best possible solution:

Land after sandbox/security owners accept the read-only skill exposure and current-head validation remains green; request SSH, OpenShell, or browser live proof only if owners need backend-specific confidence.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection of current main shows workspaceAccess: "rw" uses the agent workspace and skips the existing skill sync path, so non-workspace skill prompt paths remain host paths that sandbox read guards reject.

Is this the best way to solve the issue?

Yes, with owner acceptance. The PR fixes the bug at the sandbox/skills boundary by materializing readable copies in sandbox-owned state instead of weakening path guards or writing generated skills into the user's workspace.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 0c33f4e0786e.

Label changes

Label changes:

add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR supplies live Docker output showing the materialized skill is readable, the workspace remains writable, and the skill mount rejects writes; sibling backends remain source/test-proven rather than live-proven.
remove status: ⏳ waiting on author: Current PR status label is status: 👀 ready for maintainer look.

Label justifications:

P1: The linked regression breaks managed, bundled, and plugin skill reads for real workspaceAccess: "rw" sandbox users.
merge-risk: 🚨 security-boundary: The diff intentionally exposes non-workspace skill files inside writable sandboxes through a new protected read-only mount and bridge path.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR supplies live Docker output showing the materialized skill is readable, the workspace remains writable, and the skill mount rejects writes; sibling backends remain source/test-proven rather than live-proven.
proof: sufficient: Contributor real behavior proof is sufficient. The PR supplies live Docker output showing the materialized skill is readable, the workspace remains writable, and the skill mount rejects writes; sibling backends remain source/test-proven rather than live-proven.

Evidence reviewed

PR surface:

Source +837, Tests +849, Docs 0. Total +1686 across 36 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	23	1003	166	+837
Tests	12	860	11	+849
Docs	1	1	1	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	36	1864	178	+1686

What I checked:

Repository policy read: Root AGENTS.md and scoped guides for extensions, agents, embedded runner, and docs were read; the review applied the sandbox/security-boundary and scoped-guide requirements. (AGENTS.md:1, 0c33f4e0786e)
Current-main source repro: Current main resolves workspaceAccess: "rw" to the agent workspace and only syncs skills inside the branch guarded by workspaceDir === sandboxWorkspaceDir plus cfg.workspaceAccess !== "rw", leaving rw sandboxes without materialized non-workspace skills. (src/agents/sandbox/context.ts:50, 0c33f4e0786e)
PR implementation path: The PR creates a sandbox-state skills workspace for rw mode, syncs eligible skills into it, and passes skillsWorkspaceDir and skillsEligibility into sandbox backend/context construction. (src/agents/sandbox/context.ts:95, ab80721966d1)
Read-only mount boundary: The new materialized skills root is exposed only as a protected read-only mount under /workspace/.openclaw/sandbox-skills/skills, alongside existing workspace skill read-only mounts. (src/agents/sandbox/workspace-mounts.ts:78, ab80721966d1)
Read guard and bridge coverage: Read-tool guard mapping checks additional container mounts before workspace mapping, and sandbox FS path resolution classifies protected skill mounts as non-writable. (src/agents/agent-tools.read.ts:783, ab80721966d1)
Prompt rewrite coverage: Sandboxed runs drop host-path skill snapshots, reload workspace-only materialized skills, and rewrite prompt-facing paths to the sandbox container root. (src/agents/embedded-agent-runner/sandbox-skills.ts:121, ab80721966d1)

Likely related people:

steipete: Authored the latest PR-head commits that harden OpenShell, SSH, remote upload guards, protected skill surfaces, and sandbox skill state handling, and the timeline shows he force-pushed the current head. (role: recent sandbox/security-boundary follow-up owner; confidence: high; commits: 420103064434, ed035d03839f, 7f7fb8cdd854; files: src/agents/sandbox/ssh.ts, src/agents/sandbox/workspace-mounts.ts, extensions/openshell/src/backend.ts)
vincentkoc: Current-main blame for the sandbox context branch that skips rw skill sync points to Vincent Koc's recent commit in this area, making him a useful routing candidate for current behavior provenance. (role: recent current-main sandbox code contributor; confidence: medium; commits: b9d530e29213; files: src/agents/sandbox/context.ts, src/agents/sandbox/workspace-mounts.ts, src/skills/loading/workspace.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

brokemac79 · 2026-06-06T01:15:51Z

Superseded parking note: local Docker became available after this comment, and live local Docker proof has now been added in the PR body plus this re-review comment.

Original status from before Docker was available:

CI was green: CI, CodeQL, CodeQL Critical Quality, OpenGrep PR Diff, and Workflow Sanity all completed successfully on 7cbe626a50beeca00e19830e1d255703ded8a333.
ClawSweeper found no narrow code defect, but marked the PR needs proof because this sandbox-boundary change still needed live Docker or SSH rw sandbox behavior proof with a real managed/bundled skill.
Mantis was unavailable; Crabbox/Testbox was unavailable or timed out and is not used for the proof claim.

Current status: live local Docker proof now shows the bundled healthcheck skill is materialized, readable in /workspace/.openclaw/sandbox-skills/skills, and write-protected while /workspace remains writable.

brokemac79 · 2026-06-06T01:30:07Z

Live local Docker proof has been added to the PR body.

Summary of the proof now supplied:

image=openclaw-sandbox:bookworm-slim
workspace_access=rw
synced_skill=...\.openclaw\sandbox-skills\skills\healthcheck\SKILL.md
read_only_mounts=[{"containerPath":"/workspace/.openclaw/sandbox-skills/skills"}]
docker_exit=0
workspace_access_test=begin
workspace-write-ok
skill_read_test=begin
2:name: healthcheck
skill_write_test=begin
skill_write=blocked
... Read-only file system
host_workspace_write="workspace-write-ok"
host_skill_unchanged=true

This uses the repo sandbox image built from scripts/docker/sandbox/Dockerfile, real syncSkillsToWorkspace(), real resolveReadOnlyWorkspaceSkillMounts() / appendWorkspaceMountArgs(), workspaceAccess: "rw", and the bundled skills/healthcheck/SKILL.md skill. It shows the workspace remains writable while the materialized bundled skill is readable and write-protected inside Docker.

Per the latest proof constraint, this is local Docker proof only; I did not use local Crabbox for the proof claim. Mantis remains unavailable in this session.

@clawsweeper re-review

clawsweeper · 2026-06-06T01:30:09Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/27048817281
Updated: 2026-06-06T01:39:24.108Z

brokemac79 · 2026-06-06T02:35:49Z

Addressed the ClawSweeper P3 author item on the docs-only head cbf70880f443be436fb122145ff8fae190b1732f.

Change made:

Updated docs/gateway/sandboxing.md to document that workspaceAccess: "rw" exposes eligible managed, bundled, or plugin skills at the generated read-only path /workspace/.openclaw/sandbox-skills/skills.

Docs follow-up validation:

git diff --check
node scripts/check-docs-mdx.mjs docs/gateway/sandboxing.md
node_modules/.bin/oxfmt.cmd --check docs/gateway/sandboxing.md
node scripts/check-changed.mjs --dry-run --base origin/main

Note: local pnpm docs wrappers and the commit hook could not start because pnpm attempted an install and aborted non-interactively with ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY, so the docs commit was made with --no-verify after the direct checks above passed.

@clawsweeper re-review

steipete · 2026-06-07T20:47:45Z

Land-ready proof for 929191945efdf57b7220a841bc64edd1ceeff469.

What changed:

rw sandboxes now use a materialized, read-only sandbox-visible skills workspace. This copies eligible skill file contents into .openclaw/sandbox-skills/...; it does not rename or copy the skill logical name.
Hardened Docker, SSH, and OpenShell refresh/read paths against stale, unreadable, or poisoned materialized skill directories.

Proof run:

pnpm check:test-types
node scripts/run-vitest.mjs extensions/openshell/src/openshell-core.test.ts src/agents/sandbox/ssh-backend.test.ts src/agents/sandbox/ssh.test.ts src/agents/sandbox/workspace-mounts.test.ts src/agents/sandbox/workspace-skills-bridge-readonly.test.ts src/agents/sandbox.resolveSandboxContext.test.ts src/agents/embedded-agent-runner/sandbox-skills.test.ts src/agents/agent-tools.sandbox-mounted-paths.workspace-only.test.ts src/agents/agent-tools.read.workspace-root-guard.test.ts src/skills/loading/workspace-load.test.ts src/skills/loading/workspace-sync.test.ts src/skills/runtime/embedded-run-entries.test.ts
.agents/skills/autoreview/scripts/autoreview --mode branch --base origin/main
gh pr checks 90798 --repo openclaw/openclaw

Results:

Test types passed.
Focused sandbox/OpenShell suite passed: 3 Vitest shards, 163 tests.
Autoreview clean: no accepted/actionable findings.
PR CI is green on the PR head; all checks are pass/skip.

Known proof gap: no live remote SSH/OpenShell/Docker user-environment run beyond unit and CI coverage.

gbb-netizen · 2026-06-09T18:48:37Z

it looks like the skills are there now, although the sandboxed model still just tried to access the skill from the npm directory, starts trying to search the home directory (despite not being there due to the sandbox), gives up, and tries to do things from scratch

not sure how it was supposed to work to point it at the skills directory? if my history is poisoned somehow I'm not sure how we're meant to fix it. Unfortunately I think due to this bug there weren't very many people using sandbox so there's not a lot of info out there

gbb-netizen · 2026-06-09T18:58:08Z

@steipete the agent itself says it's being fed the wrong paths instead of the /workspace paths in its startup context, for what it's worth. If that's the case then the user experience is still that skills (and many other things) don't work if they try to use a sandbox

brokemac79 · 2026-06-09T19:04:45Z

Hi @gbb-netizen

Thanks for checking this. The fix from #90798 landed in 3b6bcbf and is included starting with v2026.6.5-beta.3; it is also in the stable v2026.6.5 release.

Can you confirm the exact OpenClaw version you updated to, plus install method? The expected behavior on those builds is that sandbox prompt/startup context should point skills at /workspace/.openclaw/sandbox-skills/skills/..., not at npm install or home-directory paths.

If you are already on v2026.6.5 and this reproduces in a fresh sandbox/thread, that sounds like a remaining prompt/context rewrite issue rather than the intended fixed state. Existing pre-upgrade history could still contain stale host paths, so a fresh thread is the cleanest check. Please share the startup context/log section that lists the skill path, along with the exact version, and we can treat it as a follow-up bug if it still shows npm/home paths on v2026.6.5.

gbb-netizen · 2026-06-09T19:24:45Z

Hi @gbb-netizen

Thanks for checking this. The fix from #90798 landed in 3b6bcbf and is included starting with v2026.6.5-beta.3; it is also in the stable v2026.6.5 release.

Can you confirm the exact OpenClaw version you updated to, plus install method? The expected behavior on those builds is that sandbox prompt/startup context should point skills at /workspace/.openclaw/sandbox-skills/skills/..., not at npm install or home-directory paths.

If you are already on v2026.6.5 and this reproduces in a fresh sandbox/thread, that sounds like a remaining prompt/context rewrite issue rather than the intended fixed state. Existing pre-upgrade history could still contain stale host paths, so a fresh thread is the cleanest check. Please share the startup context/log section that lists the skill path, along with the exact version, and we can treat it as a follow-up bug if it still shows npm/home paths on v2026.6.5.

Already on v2026.6.5, installed with openclaw update. I'm installed on WSL using npm I believe? (whatever was recommended as of a month or so ago). I used openclaw sandbox recreate --all w/ gateway restart, then I tried a new thread with /new, and it seems to have the same issue and tries to read, eg ~/.npm-global/lib/node_modules/openclaw/skills/gog/SKILL.md. Using a docker sandbox. Happy to try to reset things more if there's a better recreation/reset I can try.

The skills are being materialized as documented in the directory, though. It's just not trying to use them.

brokemac79 · 2026-06-09T19:52:59Z

Thanks @gbb-netizen , that is enough to treat this as a follow-up bug rather than a reset/setup issue. You should not need to do more broad state resets.

On v2026.6.5, a fresh Docker sandbox run should advertise skill paths under:

/workspace/.openclaw/sandbox-skills/skills/...

If the startup context is still showing paths like:

~/.npm-global/lib/node_modules/openclaw/skills/gog/SKILL.md

then the materialization part from #90798 is working, but another prompt/startup-context path is still using the original host skill snapshot instead of the sandbox-rewritten entries.

Could you please raise this as a new bug issue using the repo bug report format here?

https://github.com/openclaw/openclaw/issues/new?template=bug_report.yml

Contributing guide for reference:

https://github.com/openclaw/openclaw/blob/main/CONTRIBUTING.md

Suggested issue title:

[Bug]: Docker sandbox still advertises host skill paths in startup context on v2026.6.5

Suggested details to include:

Bug type: Regression (worked before, now fails) or Behavior bug
Version: v2026.6.5
Install method: openclaw update, WSL, npm/global npm install if that matches your setup
OS: WSL distro/version plus host OS if convenient
Sandbox: Docker sandbox, workspaceAccess: "rw"
Reset/repro attempted:
- openclaw sandbox recreate --all
- gateway restart
- new thread via /new
Expected:
- Startup context should point skills at /workspace/.openclaw/sandbox-skills/skills/...
Actual:
- Skills are materialized in that directory, but the model is still instructed to read host paths such as ~/.npm-global/lib/node_modules/openclaw/skills/gog/SKILL.md
Evidence:
- A small redacted startup-context/log snippet showing the bad skill path
- openclaw --version output
- Any redacted config showing the sandbox mode, if easy
Related context:
- Follow-up from [Bug]: Non-workspace skills are inaccessible to the agent when sandbox is in workspaceAccess: "rw" mode #90410 and fix(agents): materialize sandbox skills for rw sandboxes #90798
- fix(agents): materialize sandbox skills for rw sandboxes #90798 fixed materialization/readability, but this report suggests a remaining prompt/startup-context rewrite path is still using host skill paths

Once you file it, please comment back here with the new issue link. I’ll start work on a new PR for it immediately.

gbb-netizen · 2026-06-09T20:19:53Z

Version: v2026.6.5

Install method: openclaw update, WSL, npm/global npm install if that matches your setup

OS: WSL distro/version plus host OS if convenient

Sandbox: Docker sandbox, workspaceAccess: "rw"

Reset/repro attempted:

openclaw sandbox recreate --all

gateway restart

new thread via /new

Expected:

Startup context should point skills at /workspace/.openclaw/sandbox-skills/skills/...

Actual:

Skills are materialized in that directory, but the model is still instructed to read host paths such as ~/.npm-global/lib/node_modules/openclaw/skills/gog/SKILL.md

Evidence:

A small redacted startup-context/log snippet showing the bad skill path

openclaw --version output

Any redacted config showing the sandbox mode, if easy

Related context:

Follow-up from [Bug]: Non-workspace skills are inaccessible to the agent when sandbox is in workspaceAccess: "rw" mode #90410 and fix(agents): materialize sandbox skills for rw sandboxes #90798

fix(agents): materialize sandbox skills for rw sandboxes #90798 fixed materialization/readability, but this report suggests a remaining prompt/startup-context rewrite path is still using host skill paths
filed it here:
[Bug]: Docker sandbox still advertises host skill paths in startup context on v2026.6.5 #91761

not sure how to log to show the context directly, was primarily testing through following what the bot was trying to do in new threads (watching it look at wrong directories and then fail to locate skills entirely) and then asking it what was in its injection

brokemac79 · 2026-06-09T20:28:15Z

@gbb-netizen - i have created new issue ticket #91764 . i will start work on this now. pls feel free to follow that issue (and when PR created follow that too), but I will do my best to try and resolve for you.

brokemac79 · 2026-06-09T20:38:02Z

@gbb-netizen - i have created new issue ticket #91764 . i will start work on this now. pls feel free to follow that issue (and when PR created follow that too), but I will do my best to try and resolve for you.

the clawsweeper bot has closed my ticket because it's now a dupe of your new one. don't worry - keep yours open. i will add some extra info to it and then start work on the fix

brokemac79 · 2026-06-09T20:57:54Z

to ensure clear linking, the 'new' issue created by the user that the new PR I will work on will be linked to is #91761

brokemac79 requested a review from a team as a code owner June 6, 2026 01:03

openclaw-barnacle Bot added docker Docker and sandbox tooling agents Agent runtime and tooling size: XL proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 6, 2026

openclaw-barnacle Bot added triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. and removed proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 6, 2026

openclaw-barnacle Bot added docs Improvements or additions to documentation gateway Gateway runtime and removed triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels Jun 6, 2026

steipete added 7 commits June 7, 2026 11:05

fix(sandbox): avoid python for ssh upload guard

846dae4

fix(openshell): guard materialized skills sync

a66e2ba

fix(sandbox): refresh protected skill surfaces

9f87cf0

fix(openshell): preserve skills shadow across filesystems

52ba9c2

fix(sandbox): allow symlinked remote root ancestors

bbea46a

fix(sandbox): keep materialized skills in state

e733a8a

fix(openshell): drop poisoned sandbox skills downloads

ab80721

steipete force-pushed the fix/issue-90410-rw-sandbox-skills branch from cbf7088 to ab80721 Compare June 7, 2026 19:54

openclaw-barnacle Bot added the extensions: openshell label Jun 7, 2026

steipete added 4 commits June 7, 2026 20:59

test(sandbox): use public ssh backend command surface

7729c4d

fix(sandbox): dispose ssh session on skills refresh failure

3cb421b

fix(sandbox): clear stale ssh sandbox skills

facbac7

fix(openshell): preserve skills shadow on poisoned download

9291919

clawsweeper Bot added status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. and removed status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. labels Jun 7, 2026

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 7, 2026

steipete merged commit 3b6bcbf into openclaw:main Jun 7, 2026
163 checks passed

gbb-netizen mentioned this pull request Jun 9, 2026

[Bug]: Docker sandbox still advertises host skill paths in startup context on v2026.6.5 #91761

Closed

brokemac79 mentioned this pull request Jun 9, 2026

[Bug]: Docker sandbox still tries host skill paths after v2026.6.5 sandbox skill materialization #91764

Closed

brokemac79 mentioned this pull request Jun 10, 2026

fix(sandbox): use materialized skill paths in startup prompts #91791

Merged

Uh oh!

Conversation

brokemac79 commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Linked context

Real behavior proof (required for external PRs)

Tests and validation

Risk checklist

Current review state

Uh oh!

clawsweeper Bot commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brokemac79 commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brokemac79 commented Jun 6, 2026

Uh oh!

clawsweeper Bot commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brokemac79 commented Jun 6, 2026

Uh oh!

steipete commented Jun 7, 2026

Uh oh!

Uh oh!

gbb-netizen commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gbb-netizen commented Jun 9, 2026

Uh oh!

brokemac79 commented Jun 9, 2026

Uh oh!

gbb-netizen commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brokemac79 commented Jun 9, 2026

Uh oh!

gbb-netizen commented Jun 9, 2026

Uh oh!

brokemac79 commented Jun 9, 2026

Uh oh!

brokemac79 commented Jun 9, 2026

Uh oh!

brokemac79 commented Jun 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

brokemac79 commented Jun 6, 2026 •

edited

Loading

clawsweeper Bot commented Jun 6, 2026 •

edited

Loading

brokemac79 commented Jun 6, 2026 •

edited

Loading

clawsweeper Bot commented Jun 6, 2026 •

edited

Loading

gbb-netizen commented Jun 9, 2026 •

edited

Loading

gbb-netizen commented Jun 9, 2026 •

edited

Loading