You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Therefore, I believe this section is made to raise some identified issues, right? So let's go 😄
All 6 bin/ launchers use #!/usr/bin/python, which doesn't exist on macOS or stock Debian/Ubuntu (only /usr/bin/python3). The README puts bin/ on PATH and calls tools by their bare names, so the kernel resolves the shebang, and every command dies with "bad interpreter." It only works on Arch, it would be better to use #!/usr/bin/env python3 in all six + TOOL_DEVELOPMENT_GUIDE.md
picocom & telnetshell skills call python3 .claude/skills/.../helper.py, a path that only resolves via the repo-local .claude/skills --> ../skills symlink. Under the documented plugin install, the skill loads from the plugin dir while the bash CWD is the user's project, so the path points to nothing, disabling both skills' primary workflows. ${CLAUDE_PLUGIN_ROOT} appears zero times repo-wide. It would be better to rewrite it to "${CLAUDE_PLUGIN_ROOT}/skills/<name>/<script>.py".
onvifscan -a/--all fires destructive, unauthenticated writes. SetSystemFactoryDefault (Hard) and UpgradeSystemFirmware (with a junk blob), gated only by the -a flag, no confirmation, no WS-Security header. A single -a against an authorized but vulnerable camera can irreversibly factory-reset it. It would be better to move it behind a dedicated opt-in flag + confirmation + dry-run and drop the junk firmware payload.
Claude cannot adapt to silent wrong output, because it has no signal that the output is wrong. It consumes the tool's stdout as ground truth and relays it to you with confidence.
wsdiscovery silently drops 2 of 3 probes and reports "0 devices found." Claude concludes the network is clean. It's actually not.
iotnet's _check_payload_rule returns False, so zigbee/zwave/Modbus traffic never flagged. Claude reports "no IoT protocol vulnerabilities."
onvifscan brute flags any HTTP 200 as a valid login, so Claude reports working credentials that don't work.
Hey @nmatt0 ,
First, the tool is great. I've just tested it.
Therefore, I believe this section is made to raise some identified issues, right? So let's go 😄
All 6 bin/ launchers use
#!/usr/bin/python, which doesn't exist on macOS or stock Debian/Ubuntu (only/usr/bin/python3). The README puts bin/ on PATH and calls tools by their bare names, so the kernel resolves the shebang, and every command dies with "bad interpreter." It only works on Arch, it would be better to use #!/usr/bin/env python3 in all six + TOOL_DEVELOPMENT_GUIDE.mdpicocom & telnetshell skills call python3
.claude/skills/.../helper.py, a path that only resolves via the repo-local .claude/skills --> ../skills symlink. Under the documented plugin install, the skill loads from the plugin dir while the bash CWD is the user's project, so the path points to nothing, disabling both skills' primary workflows.${CLAUDE_PLUGIN_ROOT}appears zero times repo-wide. It would be better to rewrite it to "${CLAUDE_PLUGIN_ROOT}/skills/<name>/<script>.py".onvifscan -a/--all fires destructive, unauthenticated writes. SetSystemFactoryDefault (Hard) and UpgradeSystemFirmware (with a junk blob), gated only by the
-aflag, no confirmation, no WS-Security header. A single-aagainst an authorized but vulnerable camera can irreversibly factory-reset it. It would be better to move it behind a dedicated opt-in flag + confirmation + dry-run and drop the junk firmware payload.Claude cannot adapt to silent wrong output, because it has no signal that the output is wrong. It consumes the tool's stdout as ground truth and relays it to you with confidence.