$ ~/registry/skill/openclaw-node-inspect-debugger

SKILL

node-inspect-debugger

Name: node-inspect-debugger
Author: openclaw

Debug Node.js apps with inspect, breakpoints, heap, and CPU profiling.

Stars

★ 386,615

Source

GitHub

Updated

2026-08-18

// securityLow risk

Prompt only, no code
Open source
Community-trusted· 377.5k

Summary

This skill appears to be prompt/documentation-style content for Node.js debugging, with no declared secrets and no stated external remote endpoints. Given the open-source GitHub source and very high community adoption, overall risk is low, though its instructions do guide users to use local debugger/Inspector ports and install extra debugging tooling, so it should still be used in a controlled environment.

CredentialsLow risk

The material explicitly states there are no required secrets or environment variables, and the README does not request API tokens, cloud credentials, or account authorization; no obvious credential collection, storage, or abuse path is shown.

Network egressLow risk

No remote host is declared; the documented access is primarily to the local Inspector port such as 127.0.0.1:9229 for local debugging, with an explicit warning not to expose it on 0.0.0.0. There is no stated behavior of sending user data to third-party services.

Code executionLow risk

The system flags it as prompt-only; while the material includes example commands such as node inspect, kill -SIGUSR1, and npm installation of debugging libraries, these are documentation instructions rather than automatic execution capabilities of the skill itself. No extra system execution privileges are requested by the skill itself.

Data accessLow risk

The material does not declare built-in capability to directly read/write user files or persist data; the examples only mention possible local profile/heap outputs to /tmp during debugging, which are user-invoked local debugging artifacts rather than excessive data access by the skill itself.

Supply chainLow risk

The source is an open-source GitHub repository with extremely high community adoption (about 377k stars), providing strong auditability and source credibility that materially lowers supply-chain risk. The undeclared license and unknown maintenance status are worth noting, but based on the available facts they do not justify a higher risk rating.

Recommendations

Use the Inspector only on localhost or in an isolated development environment, and avoid exposing --inspect on 0.0.0.0.
If you install extra CDP dependencies as suggested, prefer pinned versions and review the source of the related npm packages.
Heap/profile artifacts produced during debugging may contain sensitive runtime information, so restrict where they are stored and who they are shared with.

Audited by: gpt-5.4 · 2026-06-16

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "node-inspect-debugger" skill from askskill:
1. Download https://raw.githubusercontent.com/openclaw/openclaw/main/skills/node-inspect-debugger/SKILL.md
2. Save it as ~/.claude/skills/node-inspect-debugger/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Trace breakpoints and call flow

Prompt

Show me how to debug a Node.js service with node inspect and --inspect. Explain how to start debugging, set breakpoints, step through code, inspect the call stack, and include common command examples.

Expected

A practical Node.js debugging guide with startup methods, breakpoint commands, and call stack inspection.

Analyze a memory leak

Prompt

I suspect a memory leak in a Node.js app. Explain how to connect a debugger via Chrome DevTools Protocol or --inspect, capture a heap snapshot, and analyze suspicious object growth.

Expected

A workflow for finding memory leaks, including debugger connection, heap snapshot capture, and suspicious object analysis.

Find CPU performance bottlenecks

Prompt

Explain how to collect a CPU profile for a Node.js program, identify hot functions, and optimize performance based on the profiling results. Include commands and analysis steps.

Expected

A CPU profiling guide covering profile collection, hot spot identification, and optimization recommendations.

// docs

Node Inspect Debugger

Use for Node.js debugging that needs inspector access: hidden locals, async hangs, flaky tests, child processes, startup races, memory growth, or CPU hot paths.

Default to node inspect first. Use Chrome DevTools Protocol only when you need scripted breakpoints, automated state capture, heap snapshots, or CPU profiles.

Quick start

Pause on entry: node inspect path/to/script.js
TypeScript: node --inspect-brk --import tsx path/to/script.ts
Existing PID: kill -SIGUSR1 <pid> then node inspect -p <pid>
Inspect target list: curl -s http://127.0.0.1:9229/json/list | jq
OpenClaw CLI path: node --inspect-brk openclaw.mjs ...
OpenClaw test path: OPENCLAW_VITEST_MAX_WORKERS=1 node --inspect-brk scripts/run-vitest.mjs <file>

Debugger REPL

Continue/step: cont, next, step, out, pause
Breakpoints: sb('file.js', 42), sb(42), sb('functionName'), breakpoints, cb('file.js', 42)
Inspect: bt, list(8), watch('expr'), exec expr
Current scope: repl, then evaluate locals directly; Ctrl+C exits repl mode.
Exit safely: cont before quitting if the process should continue; otherwise kill.

OpenClaw tips

Prefer 127.0.0.1 inspector binds. Do not expose --inspect=0.0.0.0 unless the network is isolated.
For Vitest, debug one file with one worker. Avoid worker pools while stepping.
For TS source breakpoints, use --enable-source-maps when useful; node inspect can still show emitted paths.
For child processes, NODE_OPTIONS=--inspect-brk can propagate the inspector, but each child needs its own port.
For long-lived gateway or dev processes, attach by PID after confirming the target with /json/list.

Programmatic CDP

Install tooling outside the repo unless the project already depends on it:

mkdir -p /tmp/cdp-tools
npm --prefix /tmp/cdp-tools i chrome-remote-interface
NODE_PATH=/tmp/cdp-tools/node_modules node /tmp/cdp-debug.cjs

Minimal driver:

const CDP = require("chrome-remote-interface");

(async () => {
  const client = await CDP({ port: 9229 });
  const { Debugger, Runtime } = client;

  Debugger.paused(async ({ callFrames, reason }) => {
    const top = callFrames[0];
    console.log("paused", reason, top.url, top.location.lineNumber + 1);
    const { result } = await Debugger.evaluateOnCallFrame({
      callFrameId: top.callFrameId,
      expression: "JSON.stringify({ pid: process.pid })",
    });
    console.log(result.value ?? result.description);
    await Debugger.resume();
  });

  await Runtime.enable();
  await Debugger.enable();
  await Debugger.setBreakpointByUrl({ urlRegex: ".*target\\.js$", lineNumber: 41 });
  await Runtime.runIfWaitingForDebugger();
})();

Profiles

CPU: enable Profiler, start, wait, stop, write /tmp/profile.cpuprofile, open in Chrome DevTools.
Heap: enable HeapProfiler, collect addHeapSnapshotChunk, call takeHeapSnapshot, write /tmp/heap.heapsnapshot.

Pitfalls

--inspect does not pause; use --inspect-brk when setup must happen before code runs.
Default port is 9229; use --inspect=0 or a unique port for parallel targets.
If a breakpoint misses, confirm file path, source map behavior, and whether execution already passed the line.
If the process appears frozen after detaching, it may still be paused in the debugger.