Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Raised on behalf of @gbb-netizen from follow-up comments on #90798, following the OpenClaw contribution guidance for reporting a new regression/bug as a GitHub Issue before a follow-up fix PR: https://github.com/openclaw/openclaw/blob/main/CONTRIBUTING.md

On v2026.6.5, Docker sandbox skill files are materialized under the documented /workspace/.openclaw/sandbox-skills/skills/... path, but fresh sandboxed threads still appear to make the agent use host/npm skill paths such as ~/.npm-global/lib/node_modules/openclaw/skills/gog/SKILL.md.

Steps to reproduce

Based on the reporter's observed reproduction:

1. Install/update to OpenClaw v2026.6.5 via openclaw update in WSL using the npm-based install path.
2. Use a Docker sandbox with workspaceAccess: "rw".
3. Run openclaw sandbox recreate --all.
4. Restart the Gateway.
5. Start a fresh thread with /new.
6. Ask the agent to use a bundled/non-workspace skill, for example gog.
7. Observe the agent attempting to read/search host paths such as ~/.npm-global/lib/node_modules/openclaw/skills/gog/SKILL.md instead of using the sandbox materialized skill path.

Expected behavior

After #90798 in v2026.6.5, the sandbox startup/prompt context should advertise skill files under the sandbox-readable materialized path:

/workspace/.openclaw/sandbox-skills/skills/<skill-name>/SKILL.md

The agent should not be instructed to read host/npm/home paths that are outside the sandbox boundary.

Actual behavior

The reporter says the materialized skill files are present in the documented sandbox directory, but the agent still tries to use host paths such as:

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

The agent then searches inaccessible locations, fails to locate the skill content, and falls back to doing the work from scratch.

The reporter could not easily capture the raw startup context, but observed the behavior by watching new-thread tool attempts and by asking the agent what was in its injected context.

OpenClaw version

v2026.6.5

Original report #90410 was on 2026.6.1; this follow-up reproduces after updating to v2026.6.5.

Operating system

Ubuntu 24 under WSL, carried forward from the original report #90410. Exact WSL distro/build details beyond Ubuntu 24 are not yet captured.

Install method

openclaw update; reporter believes this is the npm/global npm install path recommended around May 2026.

Original report #90410 listed install method as npm.

Model

chatgpt-5.5, carried forward from the original report #90410. The reporter has not explicitly reconfirmed the model for this follow-up after updating to v2026.6.5.

Provider / routing chain

openclaw -> codex, carried forward from the original report #90410. The reporter has not explicitly reconfirmed the provider/routing chain for this follow-up after updating to v2026.6.5.

Additional provider/model setup details

Original report #90410 had no additional provider/model setup details.

Logs, screenshots, and evidence

Reporter comments on the merged fix PR:

• fix(agents): materialize sandbox skills for rw sandboxes #90798 (comment)
• fix(agents): materialize sandbox skills for rw sandboxes #90798 (comment)

Relevant prior issue and fix PR:

• Prior bug: [Bug]: Non-workspace skills are inaccessible to the agent when sandbox is in workspaceAccess: "rw" mode #90410
• Fix PR: fix(agents): materialize sandbox skills for rw sandboxes #90798
• Merge commit: 3b6bcbf
• Release containing the fix: https://github.com/openclaw/openclaw/releases/tag/v2026.6.5

Evidence from release/PR state:

• fix(agents): materialize sandbox skills for rw sandboxes #90798 materialized eligible non-workspace skills into a sandbox-readable, read-only workspace for workspaceAccess: "rw".
• The reporter confirms the files are materialized as documented.
• The remaining reported failure is that the agent still appears to receive or act on host/npm skill paths in startup/injected context.

Remaining evidence gap:

• No direct redacted startup-context/log capture is available yet.
• The current report is grounded in user-observed new-thread tool behavior and the agent's own answer about its injected context.

Impact and severity

Affected: Docker sandbox users on v2026.6.5 relying on bundled/non-workspace skills in workspaceAccess: "rw" mode.

Severity: High, because skills can still be effectively unusable even though the materialized files exist.

Frequency: Reporter reproduced after openclaw sandbox recreate --all, Gateway restart, and a fresh /new thread.

Consequence: Sandboxed agents fail to load intended skill content and fall back to unskilled behavior.

Original #90410 impact was that builtin skills were fully broken with sandbox workspaceAccess: "rw"; this follow-up suggests #90798 fixed materialization/readability but not every prompt/startup-context path that tells the agent where to read skills.

Additional information

This should be treated as a follow-up to #90410/#90798, not a request for more user resets. The likely implementation hypothesis is that one startup prompt/context source still uses a host-path skill snapshot instead of the sandbox-rewritten materialized skill entries, but that needs code/repro confirmation before being treated as root cause.

This issue is intentionally scoped to the observed bug so a follow-up PR can remain focused, as requested by CONTRIBUTING.md.