Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In an AlphaClaw Docker runtime, the skills prompt advertises managed skill files as ~/.openclaw/skills/...; model-issued read calls sometimes resolve that to stale host/workspace paths such as /home/art/.openclaw/... or /home/art/niemand/.openclaw/..., causing repeated ENOENT loops even though the live skill exists at /data/.openclaw/skills/... and works.

Steps reproduce

Observed on 2026-06-14 UTC in Telegram group topic agent:niemand:telegram:group:-1003728533943:topic:7669 with OpenClaw 2026.6.6 / commit a435706, launched via AlphaClaw Docker.

1. Run OpenClaw in Docker with AlphaClaw-style environment:

HOME=/data
OPENCLAW_HOME=/data
OPENCLAW_STATE_DIR=/data/.openclaw
OPENCLAW_CONFIG_PATH=/data/.openclaw/openclaw.json

2. Ensure a managed skill exists under the live state root:

/data/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md

3. In a Telegram topic, ask an agent to use that skill, e.g. Use world cup skill and tell me how Germany's group is doing so far.

4. Inspect the session and gateway logs.

Actual behavior

The model repeatedly calls read against paths that do not exist in the AlphaClaw container/runtime, alternating between stale host/workspace expansions and occasionally the prompt path:

{"role":"assistant","content":[{"type":"toolCall","name":"read","arguments":{"path":"/home/art/niemand/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md"}}]}

The corresponding tool result is an error:

{
  "status": "error",
  "tool": "read",
  "error": "ENOENT: no such file or directory, access '/home/art/niemand/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md'"
}

Gateway logs show the same failure pattern across multiple attempts:

[gateway] 2026-06-14T05:08:03.970+00:00 [tools] read failed: ENOENT: no such file or directory, access '/home/art/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md' raw_params={"path":"/home/art/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md"}
[gateway] 2026-06-14T05:08:08.541+00:00 [tools] read failed: ENOENT: no such file or directory, access '/home/art/niemand/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md' raw_params={"path":"/home/art/niemand/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md"}

This turns into a user-visible loop in Telegram: the agent keeps saying it needs to read/check the skill instead of running the deterministic helper or reporting lookup failure. In one observed run, the model eventually read the skill successfully, then still regressed back to another stale path read.

Expected behavior

One of these should be true:

• The skills prompt should advertise a path that the read tool resolves deterministically in the same runtime where tools execute, e.g. /data/.openclaw/skills/... for AlphaClaw container runs, or another canonical oc:///managed-skill URI.
• Or the read tool should resolve prompt-provided ~/.openclaw/skills/... consistently to the live OpenClaw state root, not to the workspace home or retired host mirror.

After a failed skill read, the agent/runtime should not keep retrying equivalent invalid paths indefinitely. A failed ENOENT read is not evidence that the skill is unavailable when the managed skill registry already knows the canonical file path.

OpenClaw version

2026.6.6 (a435706) from gateway trajectory metadata.

Operating system

NixOS host, Docker container runtime. Container env proof:

HOME=/data
OPENCLAW_HOME=/data
OPENCLAW_STATE_DIR=/data/.openclaw
OPENCLAW_CONFIG_PATH=/data/.openclaw/openclaw.json

Install method

AlphaClaw Docker image: alphaclaw:0.9.18-openclaw-2026.6.6-node22.21.1.

Model

ollama/kimi-k2.7-code:cloud

Provider / routing chain

Telegram -> OpenClaw gateway embedded agent -> Ollama cloud model provider.

Additional provider/model setup details

Thinking was off for the observed Telegram turn. This may make the loop noisier, but the failure does not depend on model knowledge: the runtime provided a prompt-facing skill path that could be, and was, resolved to a dead path by tool calls.

Real behavior proof

The skill exists in the live container and is readable at the live state path:

$ docker exec alphaclaw sh -lc 'ls -la /data/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md; node -e "const fs=require(\"fs\"); console.log(fs.existsSync(\"/data/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md\"))"'
-rw-rw-r--+ 1 node users 8384 Jun 14 04:31 /data/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md
true

The helper behind the skill works when invoked from the real skill directory:

$ cd /home/art/.local/state/alphaclaw/.openclaw/skills/world-cup-soccer-openclaw-skill
$ scripts/match-live team-context --query Germany --json
{"commentaryMode":"limitationOnly","confidence":"missing_timestamp","query":"Germany","standing":{"group":"Group E","played":0,"points":0,"rank":1,"source":"espn","team":{"abbreviation":"GER","id":"481","name":"Germany"}},"status":"teamContext"}

The prompt-facing skills catalog cached for the session advertises this instead:

<skill>
  <name>world-cup-soccer</name>
  <location>~/.openclaw/skills/world-cup-soccer-openclaw-skill/SKILL.md</location>
</skill>

Source-level pointer: src/agents/skills/workspace.ts compacts prompt-facing paths before rendering the available-skills prompt:

// resolvedSkills keeps canonical paths snapshot / runtime consumers.
const promptSkills = compactSkillPaths(resolvedSkills)

The path compaction helper explicitly relies on ~ and assumes the read tool resolves it correctly:

/**
 * Replace user's home directory prefix with `~` in skill file paths to
 * reduce system prompt token usage. Models understand `~` expansion, and the
 * read tool resolves `~` against the user home directory.
 */

In this AlphaClaw setup, the relevant live state root is /data/.openclaw in-container, while the failed reads are against /home/art/.openclaw and /home/art/niemand/.openclaw.

Impact

Affected: Telegram group/topic agents using managed skills in AlphaClaw Docker.

Severity: High for skill-based workflows. The agent appears alive but gets stuck in tool-read loops and may repeatedly send setup/preamble text instead of doing the requested task.

Frequency: Reproduced repeatedly in the observed topic; gateway logs show many ENOENT reads over several minutes.

Consequence: broken skill invocation, noisy Telegram output, and failed user task despite the skill being installed and functional.

Related but not duplicate

• Skills silently truncated - user-created skills invisible with no warning or prioritization #50677 covers skills silently disappearing/truncating from the prompt. This issue is different: the skill is present in the prompt, but the advertised path can resolve to a dead location.
• [Bug]: Internal tool/status messages leak into Telegram chat even when streaming/tool progress is disabled #79804 appears related to the separate Telegram leak of internal tool/status text. This issue includes that as observed user impact, but the main root cause here is inconsistent skill-path resolution.

Additional information

This is a public behavior bug report, not a private security report. It does not rely on an untrusted user crossing an OpenClaw security boundary; it is a trusted-operator runtime correctness issue.