$ ~/registry/skill/openclaw-python-debugpy

SKILL

python-debugpy

Name: python-debugpy
Author: openclaw

Debug Python issues with pdb, breakpoints, post-mortem analysis, and debugpy.

Stars

★ 382,582

Source

GitHub

Updated

2026-07-11

// securityCaution

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

Summary

This skill material is essentially debugging documentation/prompt content with no declared secrets or fixed remote endpoints, so the overall risk is low. However, it explicitly guides local debugging, process attach, and runtime inspection via pdb/debugpy, so least-privilege use is still important, and the mismatch between the skill name and the referenced repository should be verified.

CredentialsLow risk

The material explicitly states that no keys or environment variables are required, and the README does not request API tokens, account credentials, or external service authentication. No direct credential collection, storage, or exfiltration mechanism is described.

Network egressCaution

No fixed remote endpoint is declared, but the README includes debugpy listen/attach usage. The examples bind to 127.0.0.1 by default and explicitly warn against exposing 0.0.0.0, which reduces risk. If users change this to external exposure, debugging session contents could become remotely accessible.

Code executionCaution

The documentation instructs use of `python3 -m pdb`, `breakpoint()`, and `debugpy --pid`, which involve launching local Python processes, attaching to existing processes, and executing/evaluating statements at breakpoints. The README itself explicitly treats `--pid` as an injection action. This gives it local code-execution and process-control characteristics, but within the material this is normal debugger functionality.

Data accessCaution

By design, the debugger can read source, call stacks, local variables, and exception context, and may modify runtime state; when attaching to a running process, access depends on the target process's privileges. No extra system permissions beyond debugging are described, but attaching to sensitive or production processes should be avoided.

Supply chainCaution

Positive factors include the open-source designation, GitHub source, and very high community adoption, which normally lower supply-chain risk substantially. However, the provided repository link is `openclaw/openclaw`, which does not obviously match the skill name `python-debugpy`, and the license and maintenance status are unspecified, creating provenance ambiguity. Verify that the repository is actually the source for this skill.

Recommendations

Use debug listening only in local or controlled environments, keep it bound to `127.0.0.1`, and do not expose it publicly.
Avoid using `debugpy --pid` against production or highly sensitive processes unless explicitly approved.
Verify that this skill actually maps to the provided GitHub repository, and review the real source, license, and recent maintenance status.
Remove `breakpoint()` and `pdb`/`debugpy` statements after debugging and rerun the normal test flow.

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 "python-debugpy" skill from askskill:
1. Download https://raw.githubusercontent.com/openclaw/openclaw/main/skills/python-debugpy/SKILL.md
2. Save it as ~/.claude/skills/python-debugpy/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Find the cause of a script error

Prompt

Guide me to debug this Python error with pdb and post-mortem analysis: the program exits with a ValueError. I want to inspect variable values, the call stack, and the next troubleshooting steps.

Expected

Step-by-step debugging guidance using pdb or traceback inspection, including stack frames, variables, and error context.

Add breakpoint-based debugging to code

Prompt

Help me insert breakpoint() into this Python code and explain which variables to inspect at each stop, how to step through execution, and how to tell whether the bug is in a loop or conditional branch.

Expected

Annotated example code with breakpoints plus step-by-step debugging instructions and key inspection points.

Set up remote attach debugging

Prompt

I need to remotely attach to a running Python service with debugpy. Give me a minimal working setup, including server startup parameters, listening port, security considerations, and how to connect from a local IDE.

Expected

A debugpy remote debugging setup with commands, code snippets, connection steps, and security cautions.

// docs

Python Debugpy

Use when Python code needs interactive debugging: hidden locals, confusing state mutation, failing tests, subprocesses, long-running services, or remote/headless attach.

Pick the smallest debugger that reaches the bad frame.

Choose

breakpoint(): local code, source edits ok, fastest path.
python3 -m pdb: no source edit, launch from the beginning.
python3 -m pdb -c continue: stop at an unhandled exception.
debugpy: remote/headless process, DAP client, already-running PID, or service startup race.

Commands

python3 -m pdb path/to/script.py arg1
python3 -m pdb -c continue path/to/script.py
python3 -c "import debugpy" || python3 -m pip install debugpy
python3 -m debugpy --listen 127.0.0.1:5678 --wait-for-client path/to/script.py
python3 -m debugpy --listen 127.0.0.1:5678 --wait-for-client -m package.module
python3 -m debugpy --listen 127.0.0.1:5678 --pid <pid>

For source-edit attach:

import debugpy

debugpy.listen(("127.0.0.1", 5678))
debugpy.wait_for_client()
debugpy.breakpoint()

For post-mortem:

import pdb, sys

try:
    run()
except Exception:
    pdb.post_mortem(sys.exc_info()[2])
    raise

pdb

Flow: n, s, r, c, q.
Stack/source: w, u, d, a, l, ll.
Values: p expr, pp expr, display expr.
Breakpoints: b file.py:42, b func, b file.py:42, condition, cl <num>.
Mutate/evaluate: !statement; full REPL: interact.

Rules

Reproduce with the smallest command/test first.
Disable parallel test workers for pdb; interactive stdin usually breaks inside worker pools.
Keep debugpy in the active env; do not add it as a project dependency unless the project already wants it.
Bind debug servers to 127.0.0.1; do not expose 0.0.0.0 unless isolated or tunnelled.
Use unique ports for parallel sessions.
Treat debugpy --pid as injection; avoid security-sensitive or production targets unless explicitly approved.
If PID attach fails on Linux, check ptrace/container privileges before changing the target.
Cleanup before commit: rg -n 'breakpoint\\(|pdb\\.set_trace|debugpy\\.' --type py.
Rerun the normal project test/gate without the debugger.
PYTHONBREAKPOINT=0 disables breakpoint().
If a process is stuck after debugger detach, confirm it is not still paused at a breakpoint.

openclawGet→

// similar tools

MCP

★3

Debug, flash, and inspect microcontrollers through pyOCD and CMSIS-DAP probes.

—Get→

MCP

sbl-debugger

Debug ARM Cortex-M targets via GDB/OpenOCD with inspection and peripheral decoding.

—Get→

$ loading_

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

// examples

Find the cause of a script error

Prompt

Guide me to debug this Python error with pdb and post-mortem analysis: the program exits with a ValueError. I want to inspect variable values, the call stack, and the next troubleshooting steps.

Expected

Step-by-step debugging guidance using pdb or traceback inspection, including stack frames, variables, and error context.

Add breakpoint-based debugging to code

Prompt

Help me insert breakpoint() into this Python code and explain which variables to inspect at each stop, how to step through execution, and how to tell whether the bug is in a loop or conditional branch.

Expected

Annotated example code with breakpoints plus step-by-step debugging instructions and key inspection points.

Set up remote attach debugging

Prompt

I need to remotely attach to a running Python service with debugpy. Give me a minimal working setup, including server startup parameters, listening port, security considerations, and how to connect from a local IDE.

Expected

A debugpy remote debugging setup with commands, code snippets, connection steps, and security cautions.

// docs

Python Debugpy

Use when Python code needs interactive debugging: hidden locals, confusing state mutation, failing tests, subprocesses, long-running services, or remote/headless attach.

Pick the smallest debugger that reaches the bad frame.

Choose

breakpoint(): local code, source edits ok, fastest path.
python3 -m pdb: no source edit, launch from the beginning.
python3 -m pdb -c continue: stop at an unhandled exception.
debugpy: remote/headless process, DAP client, already-running PID, or service startup race.

Commands

python3 -m pdb path/to/script.py arg1
python3 -m pdb -c continue path/to/script.py
python3 -c "import debugpy" || python3 -m pip install debugpy
python3 -m debugpy --listen 127.0.0.1:5678 --wait-for-client path/to/script.py
python3 -m debugpy --listen 127.0.0.1:5678 --wait-for-client -m package.module
python3 -m debugpy --listen 127.0.0.1:5678 --pid <pid>

For source-edit attach:

import debugpy

debugpy.listen(("127.0.0.1", 5678))
debugpy.wait_for_client()
debugpy.breakpoint()

For post-mortem:

import pdb, sys

try:
    run()
except Exception:
    pdb.post_mortem(sys.exc_info()[2])
    raise

pdb

Flow: n, s, r, c, q.
Stack/source: w, u, d, a, l, ll.
Values: p expr, pp expr, display expr.
Breakpoints: b file.py:42, b func, b file.py:42, condition, cl <num>.
Mutate/evaluate: !statement; full REPL: interact.

Rules

Reproduce with the smallest command/test first.
Disable parallel test workers for pdb; interactive stdin usually breaks inside worker pools.
Keep debugpy in the active env; do not add it as a project dependency unless the project already wants it.
Bind debug servers to 127.0.0.1; do not expose 0.0.0.0 unless isolated or tunnelled.
Use unique ports for parallel sessions.
Treat debugpy --pid as injection; avoid security-sensitive or production targets unless explicitly approved.
If PID attach fails on Linux, check ptrace/container privileges before changing the target.
Cleanup before commit: rg -n 'breakpoint\\(|pdb\\.set_trace|debugpy\\.' --type py.
Rerun the normal project test/gate without the debugger.
PYTHONBREAKPOINT=0 disables breakpoint().
If a process is stuck after debugger detach, confirm it is not still paused at a breakpoint.