[Design limitation] Why openclaw_youtube can’t (for now) do Bilibili-style “trigger by comments on any video”

AIDO debug
, , ,
1

As of 2026-03-18, I’ve basically validated all the paths that are possible with the official API in this direction. Here’s the conclusion up front: if the goal is like Bilibili, where a bot can discover trigger comments under any YouTube video, then automatically summarize the video, combine subtitles, and then post a comment, this is basically not achievable with only the official YouTube Data API v3.

It’s not because YouTube can’t comment, and it’s not because OAuth doesn’t work. It’s because the most critical step—discovering trigger comments—is not provided in a usable form by the official API.

What effect are we trying to achieve?

The goal is actually very clear:

  • Account A or a bot account can work under any YouTube video
  • The trigger can be @fixcolar, or a fixed activation phrase, e.g. “Coconut, summarize this video with subtitles combined”
  • Once the trigger hits, the system automatically obtains the video, the comment, and the context
  • If there are subtitles, inject the subtitles into the LLM
  • Finally, that account automatically goes back to the comment section of that video and posts a comment

The reason the Bilibili plugin works is that it’s not “scanning video comment sections”; it’s reading the account’s own @ mention feed / reply feed. As long as someone @’s you anywhere site-wide, Bilibili puts it into the message feed, so the plugin can work across videos.

On YouTube’s official API side, the bottleneck is exactly this step.

Why the official API approach doesn’t work

1. commentThreads.list can’t query by “comment author”, and there is no site-wide mention feed

Official docs:

The main filters commentThreads.list supports are basically:

  • videoId
  • allThreadsRelatedToChannelId
  • id

Meaning, at most, you can:

  • Fetch comment threads under a specific video
  • Fetch comment threads related to a specific channel
  • Fetch by a known thread id

It cannot do these things:

  • Query “which videos did a given account comment on recently”
  • Query “where on the entire site did someone @ me”
  • Query “where on the entire site did my activation keyword appear”

This means: relying only on this endpoint, you can only watch fixed channels or fixed videos—you can’t do “trigger under any video”.

2. comments.list also can’t query history by author

Official docs:

The core filters comments.list supports are only:

  • id
  • parentId

It’s more like “I already know the commentId; please fetch this comment or its replies for me”, rather than “help me find what this person has commented recently”.

So it also doesn’t solve the problem of “discovering trigger comments in arbitrary videos”.

3. activities.list?mine=true doesn’t save you either

Official docs:

Intuitively, the closest idea might be: can we use the account’s own activity feed?

But the official docs are very explicit:

  • The comment type is “not currently returned”
  • activities.list does not currently return resources for new comments

In other words, the account’s own activity feed can’t be used to reliably obtain “which video I just commented under”.

4. Official Push Notification also doesn’t push comment events

Official docs:

This push mechanism pushes channel feed changes; fundamentally it’s still centered around channel content updates, not a comment/mention event stream.

So it can’t replace “site-wide comment discovery” either.

5. Gmail comment notifications are unstable; they’re only a side path and not suitable as the main pipeline

Official help:

The official help even explicitly warns:

consecutive comments on a video may not lead to notifications for each

Meaning consecutive comments may not each produce a notification. Using email as the main trigger pipeline will inherently miss events.

What this implies

Parts where the official API is still useful

The YouTube API is not completely useless; it actually has value in the second half:

  • After you know the video, you can post a top-level comment: commentThreads.insert
  • After you know the parent comment, you can post a reply: comments.insert
  • You can fetch video metadata
  • Combined with yt-dlp, you can also fetch existing subtitles for public videos

In other words:

“Comment discovery” doesn’t work, but “comment posting” is feasible.

What’s truly missing is the first half

What’s missing is:

  • Discovering which videos account A itself just posted comments under
  • Discovering where someone @’d the bot across the whole site
  • Discovering whether an activation-keyword comment appeared under any video

Without this step, the whole “site-wide triggering like Bilibili” plan can’t stand.

So how should we understand the positioning of the current API-based openclaw_youtube?

If we only look at the official API route, it’s better suited to these narrow scenarios:

  • Monitoring comments received by your own channel
  • Monitoring comments under fixed channels / fixed videos
  • Auto-replying when the commentId / videoId is already known
  • When the user explicitly requests “combine subtitles”, injecting public subtitles

But it does not fit this goal:

  • Triggering with @fixcolar under any video
  • Triggering by posting “Coconut, summarize this video with subtitles combined” under any video

So continuing to pile parameters onto the official Data API doesn’t mean much. This isn’t an engineering-effort problem; it’s that the interface itself doesn’t provide this kind of discovery capability.

What “workaround” options exist going forward?

The directions below aren’t wishful thinking—they’re the routes that still have a real chance of landing.

Option 1: Tampermonkey script / browser extension for active triggering

This is the option I’m most optimistic about right now.

Approach:

  • You open any YouTube video page
  • A Tampermonkey script or extension reads the current page’s videoId directly
  • You click a button, or the script has a built-in fixed prompt like “summarize this video with subtitles combined”
  • The frontend sends videoId + prompt to a local service
  • The backend fetches subtitles, runs the LLM, then posts a comment via the API

Benefits of this route:

  • No need to discover “where did I comment”
  • Doesn’t depend on whether YouTube sends notifications
  • The page is only responsible for triggering, not for actually posting the comment
  • Actually posting the comment can still use the official API, with higher stability

If later you want “on any video page, click once to auto-post a summary comment”, this route is the most reliable.

Option 2: Poll YouTube Studio / Notifications page in a logged-in browser

This route is more like a replacement for the Bilibili message-feed idea.

Approach:

  • Maintain a logged-in YouTube browser profile on the local machine
  • An extension or daemon periodically reads YouTube Studio’s comments page, notifications page, or mention page
  • Parse new comment / mention / reply events
  • Hand the discovered events to OpenClaw and reply via the official API

Pros:

  • Can get close to the “@ triggers under any video” experience

Cons:

  • Essentially web automation; high maintenance cost
  • A page redesign can break it
  • Login state, risk controls, and captchas are all more troublesome than the official API

Option 3: Semi-manual handoff via comment link / commentId

This is the most primitive but also the most stable method.

Approach:

  • You first post a trigger comment yourself under any video
  • Then manually send the comment link or commentId to the bot
  • After the bot gets it, it runs the backend flow to reply / summarize / inject subtitles

It’s not elegant, but it’s the fastest way to get the “generate comment content” half working end-to-end.

Option 4: Hybrid architecture

This is actually a fairly realistic long-term architecture:

  • Use non-official paths for the discovery side: browser pages, Tampermonkey, extensions, Studio notifications pages, etc.
  • Continue using the official API for the execution side: posting top-level comments or replies

That is:

  • First half relies on web context
  • Second half relies on the formal API

This is currently the most defensible engineering path.

Conclusion at the current stage

I think this conclusion should be stated clearly to avoid continuing to burn time in the wrong direction:

  • If openclaw_youtube insists on “only using the official Data API”, it can only become a fixed-channel / fixed-video comment bot
  • If the goal is “trigger under any video like Bilibili”, you must abandon the assumption of “pure API discovery”
  • What can truly land is a hybrid approach: browser-side discovery + API-side replies

In other words:

This YouTube thing is not “impossible”, it’s “impossible to do relying only on the official comment API”.

That’s the most important conclusion at this stage.