
OpenClaw Debugging
FreeStreamline debugging for OpenClaw models and tools.
Free · Opens the source repo
What OpenClaw Debugging does
OpenClaw Debugging is designed for developers working with the OpenClaw framework who need to diagnose and resolve discrepancies in model behavior across different environments. This skill enables you to identify the root causes of issues by utilizing targeted logs, probes, and proof paths, rather than relying on guesswork. By following a structured approach, you can effectively debug various components such as local tests, live models, and CI environments.
The debugging process begins with clearly defining the suspected boundary, whether it's related to configuration, tool construction, or the provider payload. You can then enable specific debug signals that narrow down the issue, allowing for a focused investigation. The skill provides detailed instructions on how to reproduce the problem consistently, ensuring that you are testing under the same conditions as the original failure. This methodical approach helps in accurately identifying discrepancies between the expected and actual behavior of your OpenClaw setup.
Additionally, OpenClaw Debugging offers insights into model transport logs, enabling you to monitor the flow of requests and responses in real-time. By using targeted environment flags, you can gather relevant information about the model's payload and stream timing, which can be crucial for diagnosing issues. The skill also outlines common boundaries that developers should be aware of, such as differences between configuration and activation states, ensuring that you have a comprehensive understanding of the factors at play.
This skill is particularly beneficial for developers who frequently work with OpenClaw and need a reliable method for debugging complex interactions within their applications. By leveraging the structured debugging process and comprehensive logging capabilities, you can enhance the reliability of your OpenClaw implementations and streamline your development workflow.
When to use it
Use this skill when you encounter unexpected behavior in OpenClaw models or tools across different environments and need to debug systematically.
When not to use it
This skill may not be suitable for users who are not working with OpenClaw or those who require a more general-purpose debugging tool.
What you can build with it
Debugging Configuration Issues
When you suspect that configuration settings are not being applied correctly, use the skill to narrow down the issue.
Resolving Model Discrepancies
If your OpenClaw model behaves differently in local tests versus live environments, this skill helps identify the root cause.
Monitoring Live Model Behavior
Utilize the skill's logging capabilities to track requests and responses in real-time for live OpenClaw models.
How to install OpenClaw Debugging
View source1. Install with the skills CLI
npx skills add openclaw/openclaw/openclaw-debugging --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by openclawOpenClaw Debugging
Use this skill when OpenClaw behavior differs between local tests, live models, providers, code mode, Tool Search, Crabbox, or CI, and the next move should be a debug signal rather than a guess.
Read First
docs/logging.mdfor log files,openclaw logs, and targeted debug flags.docs/reference/test.mdfor local test commands.docs/tools/code-mode.mdfor code-mode exec/wait and tool catalog rules.- Use
$openclaw-testingfor choosing test lanes. - Use
$crabboxfor broad, Docker, package, Linux, live-key, or CI-parity proof.
Default Loop
- State the suspected boundary: config, tool construction, provider payload, fetch, stream/SSE, transcript replay, worker/runtime, package/dist, or CI.
- Add or enable the narrowest signal that proves that boundary.
- Reproduce with the same provider/model/config. Do not randomly switch models unless the model itself is the variable being tested.
- Compare configured state with actual run activation.
- Patch the root cause.
- Rerun the exact failing probe, then broaden only if the contract requires it.
Model Transport Logs
Use targeted env flags instead of global debug when the model request shape or stream timing matters:
OPENCLAW_DEBUG_MODEL_TRANSPORT=1 openclaw gateway
OPENCLAW_DEBUG_MODEL_PAYLOAD=tools OPENCLAW_DEBUG_SSE=events openclaw gateway
OPENCLAW_DEBUG_MODEL_PAYLOAD=full-redacted OPENCLAW_DEBUG_SSE=peek openclaw gateway
Useful flags:
OPENCLAW_DEBUG_MODEL_TRANSPORT=1: request start, fetch response, SDK headers, first SSE event, stream done, and transport errors atinfo.OPENCLAW_DEBUG_MODEL_PAYLOAD=summary: bounded payload summary.OPENCLAW_DEBUG_MODEL_PAYLOAD=tools: all model-facing tool names.OPENCLAW_DEBUG_MODEL_PAYLOAD=full-redacted: capped, redacted JSON payload. Use only while debugging; prompts/message text may still appear.OPENCLAW_DEBUG_SSE=events: first-event and stream-completion timing.OPENCLAW_DEBUG_SSE=peek: first five redacted SSE events.OPENCLAW_DEBUG_CODE_MODE=1: code-mode tool-surface diagnostics.
Watch logs with:
openclaw logs --follow
Common Boundaries
- Config vs activation: config can be enabled while the run disables tools, is raw, has an empty allowlist, or lacks model tool support. Check the actual visible tools before enforcing provider payload invariants.
- Tool surface: inspect final model-visible tool names, not only the tool
registry or config. Code mode means exactly
execandwaitonly after it actually activates. - Provider payload: log fields, model id, service tier, reasoning, input size, metadata keys, prompt-cache key presence, and tool names before SDK call.
- Fetch vs SSE: fetch response proves HTTP headers arrived; first SSE event proves provider body progress. A gap here is a stream/body/provider issue, not tool execution.
- Worker/dist: run
pnpm buildwhen touching workers, dynamic imports, package exports, lazy runtime boundaries, or published paths. - Live keys: use the configured secret workflow for missing provider keys before saying live proof is blocked. Env checks are presence-only; never print secrets.
Code Pointers
- Model payload + Responses stream:
src/agents/openai-transport-stream.ts - Guarded fetch/timing:
src/agents/provider-transport-fetch.ts - OpenAI/Codex provider wrappers:
src/llm/providers/stream-wrappers/openai.ts - Tool construction, Tool Search, code-mode activation:
src/agents/embedded-agent-runner/run/attempt.ts - Code-mode runtime and worker:
src/agents/code-mode.tssrc/agents/code-mode.worker.ts - Tool Search catalog:
src/agents/tool-search.ts
Proof Choice
- Single helper/payload bug: local targeted Vitest.
- Docs/logging-only:
pnpm check:docsandgit diff --check. - Worker/dist/lazy import/package surface: targeted tests plus
pnpm build. - Live provider/model behavior: same provider/model with debug flags and a real key if available.
- Docker/package/Linux/CI-parity:
$crabbox. - CI failure: exact SHA, relevant job only, logs only after failure/completion.
Output Habit
Report:
- boundary tested
- exact command/env shape, redacted
- observed signal, such as tool names or first SSE event timing
- fix location
- narrow proof and any remaining risk
Frequently asked questions about OpenClaw Debugging
Similar skills
Agent Host Debug Logs
Analyze Agent Host debug logs for deeper insights.
Code OSS Dev - Launch + Debug
Launch and debug Code OSS with isolated profiles.
Phoenix CLI
Debug LLM applications with structured analysis tools.
Power Automate Debugging
Diagnose and fix Power Automate flow errors effectively.
Arize Trace
Inspect and export traces for LLM applications.
Runtime Behavior Probe
Investigate real runtime behavior with precision.
