#Skills failing after v2026.5.7 to v2026.5.12 upgrade

1 messages · Page 1 of 1 (latest)

round compass
#

I have the following skill that I use as an example and has been running just fine until upgrading.

---
name: test-prod
description: Use when the user invokes test_prod or asks to test Prod agent routing. The expected behavior is to spawn the prod agent and return exactly the child result.

---

++ Usage

When this skill is invoked:

1. Call `agents_list` if needed to confirm the exact Prod agent id.
2. Call `sessions_spawn` with `runtime: "subagent"`, `agentId: "prod"`, `mode: "run"`, and task: `Reply with exactly prod-ok`.
3. Wait for the spawned run completion if the tool/runtime requires it.
4. Reply with the resulting text. The expected final reply is exactly: `prod-ok`.

If `sessions_spawn` or the Prod agent id is unavailable, explain that instead of replying NO_REPLY.

I would see the tool calls for the session spawning/yielding to the Prod agent before receiving the response of prod-ok as expected. However, after upgrade I do not see any tool calls and the response, while varying each time, seems to be addressing internal system messages rather than the skill prompt. For example:

This appears to be a log entry or a record of an action taken at a specific time and location (implied by the format).

Since there is no explicit question, I need more context to provide a helpful response. Could you please tell me:

1. **What do you want me to do with this information?** (e.g., interpret it, explain what it means, continue a conversation, analyze it?)
2. **What does this format represent?** (e.g., a chat transcript, a system log, a personal note?)

If you can provide context, I will do my best to assist you!

Logs are attached.

odd heartBOT
# round compass I have the following skill that I use as an example and has been running just fi...

I checked the log. The skill is being selected correctly:

Applying skill filter: test-prod
After skill filter: test-prod

So this does not look like skill discovery/frontmatter failing. The interesting part is later: the run is provider=ollama, model=gemma4:latest, selectedHarnessId=pi, then it completes with no tool-use records at all. That means the parent model/harness never attempted sessions_spawn; it is not getting as far as failing to spawn prod.

What I’d check next:

  1. Start with the exact version: openclaw --version
  2. Run openclaw status --all and check whether the session’s effective tool policy is restricting tools. If you use tools.allow, make sure sessions_spawn and agents_list are allowed, or allow group:sessions plus agents_list.
  3. Try the same test_prod skill from a fresh session after /new or reset. Harness selection is now pinned per session, so config/model/runtime changes can be hidden by an older session.
  4. Try once with a tool-reliable cloud model. Local Ollama models can answer the skill text instead of actually emitting tool calls, especially for orchestration tools. If the same skill works on a cloud model, the skill is fine and the failure is in the Ollama/Gemma tool-call path.
  5. If it still reproduces on the latest build with a tool-reliable model, this is worth a GitHub issue with this log plus sanitized openclaw status --all: https://github.com/openclaw/openclaw/issues

Relevant docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/tools/subagents

round compass
#
  1. As mentioned in the title. The skill was working in v2026.5.7, but stopped after upgrading to v2026.5.12.
  2. openclaw status --all doesn't return tool-specific info, however, I have confirmed that the agents have Full tool access.
  3. I always try it with a fresh session and even after restarting the gateway
  4. No, I do not use cloud models whatsoever, only local Ollama models.
  5. I will submit an issue if we cannot resolve
odd heartBOT
# round compass 1. As mentioned in the title. The skill was working in v2026.5.7, but stopped af...

Got it. Given those answers, I’d treat this as a likely 5.12 local/Pi runner regression until proven otherwise.

The log already proves the skill filter is fine, and your fresh-session/full-tools checks rule out the obvious stale snapshot/tool policy cases. The key remaining split is:

  • sessions_spawn is present in the compiled tool list, but Gemma/Ollama is no longer emitting the tool call under 5.12
  • or 5.12 is accidentally not exposing sessions_spawn to the Pi/Ollama run despite the policy saying Full access

Best next diagnostic: run the failing skill once, then in that same session run:

/export-trajectory test-prod-v512

In the export, check the context.compiled event. If tools contains sessions_spawn, this is probably model/tool-call behavior after the 5.12 Pi runner changes. If sessions_spawn is missing there, it’s an OpenClaw tool exposure bug.

Also worth trying the latest release/main if you can. There have been several post-5.12 fixes around skills/subagents/tool restrictions and local runner behavior, so if 5.17/main fixes it, that’s useful signal for the issue.