#Openclaw reads YouTube transcript

1 messages · Page 1 of 1 (latest)

copper flameBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

tepid leafBOT
#

OpenClaw doesn’t have a built-in “YouTube transcript” tool, and web_fetch usually won’t work on youtube.com/watch… because YouTube is JS-heavy (and often anti-bot). The reliable ways are:

Option A (most reliable): use the browser tool and “Show transcript”

  1. Enable/allow the browser tool for the agent.
  2. Either:
    • use OpenClaw’s managed browser, or
    • use the Chrome extension (browser relay) so it can drive your logged-in YouTube tab (best if YouTube nags about consent/login).
  3. Ask your agent: “Open this video, click Show transcript, copy the transcript text, then summarize it.”

Docs:

Option B (fast + automation-friendly): yt-dlp via exec (captions/subtitles)

If the video has captions/auto-captions, install yt-dlp (+ often ffmpeg) on the machine where exec runs, then have the agent run something like:

  • download subtitles (vtt) → convert to plain text → summarize.
#

Docs:

Option C: no captions available → you need speech-to-text

If the video has no transcript/captions, you’ll need to download audio and run STT (Whisper/etc). That’s a bigger pipeline.

If you tell me which setup you’re on (Gateway local vs VPS, and whether you’re okay installing yt-dlp), I’ll recommend the cleanest path and a copy-paste “skill” instruction for it.

deep kelp
#

I've been getting blocked lately on yt-dlp via summarize skill while running openclaw in a vps environment. It looks like YouTube has increased it's anti-bot protections, so the exec version of this will be difficult but not impossible.

tepid leafBOT
#

Yeah, that matches what a bunch of folks are seeing: datacenter/VPS IP ranges get hit with much stricter YouTube bot checks, so yt-dlp that was “fine last month” suddenly starts failing.

The clean OpenClaw-ish way around this (without turning it into an anti-bot arms race) is:

1) Keep the Gateway on the VPS, but run the “transcript fetch” on a node at home

Run a node host on a machine with a normal residential IP (or wherever YouTube works reliably), then have your summarize workflow use:

  • exec host=node for yt-dlp, and/or
  • browser profile=chrome (extension relay) to click “Show transcript” and copy it.

Docs:

This tends to solve 90% of the “VPS got blocked” pain immediately, because you’re no longer scraping from a flagged IP range.

#

2) Add a fallback path in the skill: Browser transcript > yt-dlp > (give up)

In practice:

  • Try browser transcript extraction first (most “human-like”, also handles consent/login prompts).
  • If that fails and captions exist, try yt-dlp.
  • If both fail, return: “No transcript available / blocked” (and optionally ask the user to attach a Chrome tab).

3) If you must stay VPS-only

You’re basically stuck in “cat and mouse” territory. You can sometimes improve reliability with authenticated/session-based access, but I’d strongly recommend the node-host approach above instead—it’s simpler and more robust.

If you want, paste the specific yt-dlp error output you’re seeing (403? sign-in required? “bot detection”?), and I can suggest what the least gross fallback should be for that failure mode inside the skill.

inner obsidian
#

Reddit

tepid leafBOT
#

If you mean “same thing, but for Reddit”: yep — usually easier than YouTube.

Best fallback order:

  1. web_fetch first for public Reddit URLs.
  2. If Reddit serves a JS/login/blocked page, use browser instead.
  3. For private/quarantined/login-only subreddits, the user needs to open it in their own logged-in browser session; don’t try to bypass access.

Reusable skill shape:

When asked to summarize a Reddit URL:
- Try web_fetch first.
- If comments/post body are missing, use browser.
- Summarize the OP, top comment themes, disagreements, and notable links.
- If access is blocked/login-only, say so clearly.