Route first: setup failure vs enabled-but-failing runtime
When you search for OpeClaw tool-call failures or Skill execution errors, classify the symptom: Skills will not install or the toggle is missing; a tool/Skill is enabled but every call is denied; it stops halfway with an error; a file path is not found; or the UI shows an error code / failure reason.
The Skills setup guide covers install and enable. This page covers runtime failures after enable: permissions, path strings, arguments, and how to read return messages. Workspace file reads belong in the local-folder guide; timelines in log-diagnose; mid-answer text stops in truncated output.
Do not invent concrete tool API names, unpublished permission-toggle labels, or an official error-code table. Availability, permission scope, and message text follow the tool status and logs visible in your current client. Redact paths, keys, and account details before sharing logs.
- Cannot install / no entry: Skills setup.
- Enabled but still failing: this page (permission, path, args, return text).
- Unread workspace files: local folder / workspace.
- Need a timeline: log-diagnose; text stops mid-way: truncated output.
Tool has no permission: check visible grants, then narrow scope
“No permission” usually means the call was rejected, a resource was blocked, or the Skill was stopped at the start. In the current client, confirm the tool/Skill is enabled and whether file, script, or network prompts appeared—use the labels on screen; do not guess unpublished option names from rumors.
Suggested order: keep only the one tool or Skill under test → retry with the minimum grant shown in the dialog or settings → confirm the target path sits inside what you already allowed → if it still fails, take key log lines (redacted). Enabling many extensions at once makes the boundary hard to isolate.
On managed work or school devices, policy may allow the app to open but block scripts or extension writes. Ask an admin about policy instead of chasing unknown “one-click elevate” packages.
File path not found: verify the string before reinstalling
When a path is not found, separate “workspace never attached” from a bad path string, wrong relative base, or a target outside the allowed directory. The first case belongs in the local-folder guide; the second is checked here against the path used in that call.
Checklist: is the path complete; does casing match the OS (especially macOS/Linux); were spaces or special characters truncated; is a relative path resolved from the current workspace root. Do not treat “the model said it read the file” as success—trust the tool return or log failure text.
When pasting paths into chat or a ticket, replace usernames, private project folders, and key filenames with placeholders. After redaction, use the log-diagnose guide for key error lines.
- Workspace not attached / system permission dialog: local-folder guide.
- Path string, relative base, out-of-scope access: check here.
- Redact before sharing: home directories, secrets, internal hostnames.
Skill stops halfway: execution error vs output interruption
When a Skill stops halfway, first check for an explicit tool/Skill error. Denial, invalid path, bad arguments, or a stated failure reason stay on the runtime path; no tool error and mid-sentence text stop belong in the truncated-output guide.
Minimum reproducible steps: one Skill, one short task, no sensitive directories; record the on-screen text at the stop (redacted); if needed, collect logs for the current build via the log-diagnose guide and keep only timestamps plus error lines.
Do not invent “error code X always means official meaning Y.” The same number can differ across builds or tools—follow the visible client message and release notes.
Arguments and return messages: how to read them without inventing a code table
When a tool returns an error, save the full text (plus a few surrounding lines), not only a number. Argument failures often mean a required field is missing, a type mismatch, an empty path, or a request beyond what the tool currently declares—field names follow the current client/tool docs.
Read in order: short UI message → key log error line → known tool/Skills limits in the current release notes. This site does not publish an official error-code map or a concrete tool API name list.
If the message points to auth failure, quota, or proxy inability to reach the model, that is a model-channel issue—use the API key / quota or proxy guides instead of tweaking Skills arguments here.
Routing table: pick the next page without mixing layers
Use the table for routing only. Menu names, permission copy, and error text follow your current client.
| Symptom | First classification | Next step |
|---|---|---|
| Skills will not install or enable entry is missing | Install / enable layer | Skills setup guide |
| Enabled, but denied or access blocked | Runtime permission | This page: narrow grants and retry |
| Path missing or file unread | Workspace or path string | Local-folder first, then verify this path |
| Skill stops halfway with a tool error | Execution failure | This page + log-diagnose (redacted) |
| Text stops mid-way, no tool error | Output interruption | Truncated & interrupted output guide |
| 401 / 429 / proxy cannot reach model | Model channel | API key or proxy connection guide |
Do not invent concrete tool API names, unpublished permission toggles, or an official error-code table; follow visible tool status and log text in the current client.
Minimum proof and checklist before asking for help
Minimum proof: enable only one related tool or Skill → run a short task on a non-sensitive test folder → if it works, re-enable others gradually; if it fails, freeze that repro and recheck permission and path.
Before asking for help or self-reading logs: note client version, OS, whether you just updated, the full error text (paths and keys redacted), and what permission/path checks you already tried. How to collect logs and read key lines is in the log-diagnose guide.
For install entry or release status, use the download page; general product questions belong in the FAQ. If the real issue is “forgot earlier context” rather than a tool error, use the context & session management guide.
Tool & Skill call failures FAQ
If an OpeClaw tool call fails, does that mean Skills were not installed correctly?
Separate two layers. If the Skills toggle is missing, install fails, or there is no enable entry at all, use the Skills setup guide. This page covers “enabled but still failing at runtime”: denied permission, missing path, bad arguments, or a tool error message. Follow the tool status and log text visible in your current client.
A Skill stops halfway—is that a tool failure or truncated output?
If the UI or logs show a tool/Skill execution error, permission denial, or invalid path, use this guide. If the model text stops mid-sentence or a code fence is left open with no tool error, use the truncated-output guide. Both can appear in sequence—fix the layer with a clear error first.
How should I read a tool error code? Is there an official code table?
This site does not invent unpublished official error-code tables or list concrete tool API names. Copy the full client or log message (after redaction) and compare it with your build notes and visible tool status. For timelines, use the log-diagnose guide for your current version.
Path not found—this page or the local workspace guide?
If the workspace was never attached, a system permission dialog was denied, or the whole folder is unreadable, start with the local-folder / workspace guide. If the tool already claims access to a path and still fails, use this page to check the path string, relative vs absolute base, and whether the target is outside the allowed scope.
Use this with an OpeClaw workflow
Check the current OpeClaw download status first, then save this guide as part of your setup, review, or troubleshooting workflow.