#refusing to add torrent

1 messages · Page 1 of 1 (latest)

limber cairnBOT
quartz pulsarBOT
#

Let me verify the current docs paths and then I’ll answer concretely.

#

I’m checking whether that qBittorrent skill is model-driven or direct-dispatch, because that changes the fix.

#

Short version, this is probably not user error.

What’s happening is:

  • the qBittorrent skill is very likely just prompt/instruction text
  • it does not override the model’s own safety policy
  • “add this magnet link” is ambiguous, so many models jump to “this might be piracy” and refuse

If you’re using the common jmagar/qbittorrent skill, it looks like a plain SKILL.md, not a deterministic direct-dispatch tool. So even /qbittorrent ... still goes through the model by default.

Docs:

What usually helps:

#

  1. Be explicit if the content is legit

    • “Add this official Ubuntu ISO magnet link to qBittorrent.”
    • “This is my own torrent / public domain / Linux distro mirror.”

  2. Don’t expect model swapping alone to fix it

    • OpenAI vs MiniMax can still make the same safety call here.

  3. For a real fix, make it deterministic

    • best path is a plugin/tool or skill command that bypasses the model
    • in OpenClaw terms, that means direct tool dispatch, not just a natural-language skill

Can you paste:

  • openclaw --version
  • the exact refusal text
  • which qBittorrent skill you installed

If you want, I can help you turn it from “model decides” into “command executes” so it stops moralizing about magnets.

quartz pulsarBOT
#

Yep, for that exact example the refusal is expected.

Why:

  • that magnet is for a copyrighted movie rip on public trackers
  • the dn= literally says Avengers Endgame ... [YTS.LT]
  • owning the Blu-ray does not make “download this public torrent rip for me” a safe request for the model to execute

So this is not really an OpenClaw bug, and not something a different model will reliably fix. The qBittorrent skill you installed is just a normal SKILL.md, it does not override model/provider safety.

So the answer to your original question is:

  • not user error, exactly
  • not mainly a prompting issue either
  • for this specific magnet, the refusal is basically working as intended

Your version, 2026.4.15, also looks recent enough that I would not suspect an old skill-routing bug first.