YOUTUBE_UPDATE_VIDEO silently destroys embeddable / publicStatsViewable when changing privacy_status

[nathanpelton]

YOUTUBE_UPDATE_VIDEO silently destroys embeddable / publicStatsViewable when changing privacy_status

Summary

YOUTUBE_UPDATE_VIDEO forwards only the fields the caller passed as the status part of
YouTube's videos.update. That endpoint replaces the part rather than patching it, so any
status field the caller didn't mention is reset to its default.

Calling YOUTUBE_UPDATE_VIDEO(video_id=..., privacy_status="public") — with no other arguments —
therefore silently sets embeddable: false and publicStatsViewable: false on the video.

The call returns success. Nothing in the tool description or the response indicates that unrelated
settings were destroyed.

Impact

Silent, non-obvious data loss on a live resource. embeddable: false disables the video on every
third-party site that embeds it, which for a publishing workflow is a real, revenue/reach-affecting
regression that is invisible unless you happen to diff status before and after.

It is also not repairable through the toolkit — YOUTUBE_UPDATE_VIDEO exposes no embeddable
or publicStatsViewable parameter, so once clobbered the only fix is YouTube Studio by hand, or
bypassing the tool entirely.

I hit this while publishing an audiobook series on a schedule; 6 videos were affected before I
noticed, and the only reason I noticed was an unrelated audit of the status block.

Reproduction

1. Take any video with embeddable=true, publicStatsViewable=true (the upload default).
2. YOUTUBE_UPDATE_VIDEO(video_id=<id>, privacy_status="public")     # only this field
3. YOUTUBE_GET_VIDEO_DETAILS_BATCH(id=[<id>], parts=["status"])

Expected: privacyStatus changes; embeddable and publicStatsViewable unchanged.
Actual: embeddable: false, publicStatsViewable: false.

Evidence that privacy_status is specifically the trigger

Across a 61-video channel, all 61 received a metadata write (title + description + tags) in
one pass, and 6 of them later received a privacy_status write:

cohort	n	embeddable after
metadata write only	55	true (55/55)
metadata write + privacy_status write	6	false (6/6)

Controlled check on a single untouched video — re-sent identical title/description/tags,
no privacy_status:

BEFORE  embeddable=true  publicStatsViewable=true
AFTER   embeddable=true  publicStatsViewable=true

So metadata-only updates are safe; sending privacy_status is what triggers the reset.

Root cause

This is documented YouTube behavior for videos.update, not a YouTube bug:

"If your request does not specify a value for a property that already has a value, the
property's existing value will be deleted."
— https://developers.google.com/youtube/v3/docs/videos/update

The wrapper needs to account for it. Sending a complete status object works correctly — I
verified this by calling the API directly:

PUT https://www.googleapis.com/youtube/v3/videos?part=status
{"id": "<id>", "status": {
   "privacyStatus": "public", "embeddable": true, "publicStatsViewable": true,
   "license": "youtube", "selfDeclaredMadeForKids": false}}

That preserves everything.

Suggested fix

Read-modify-write inside YOUTUBE_UPDATE_VIDEO: when any status field is being changed, first
GET the video's current status, merge the caller's change into it, and send the complete
object. Same applies to the snippet part.

Failing that, two cheaper mitigations:

• expose embeddable, publicStatsViewable, license, selfDeclaredMadeForKids as parameters so
  callers can at least restore them; and
• document the destructive behavior in the tool description, which currently only warns about tags
  ("an empty list for tags removes all existing tags").

Possibly related

A tags-only call — YOUTUBE_UPDATE_VIDEO(video_id=..., tags=[...]) with no title/description —
returned success but the tags did not persist; re-reading showed the video still had zero tags.
Resending the same tags together with title and description worked. I did not isolate this as
carefully as the status bug, so treat it as an observation rather than a confirmed second defect,
but it smells like the same partial-part handling.

Environment

Hosted Composio MCP, YouTube toolkit, accessed via the tool-router session (not the Python SDK
directly), 2026-07-31.

[github-actions]

🤖 Automated Claude triage note: this does not look like an SDK bug, so I've labeled it as support for support team follow-up. Claude cannot reply back in a conversation.

[nathanpelton]

Thanks for triaging. Flagging one thing for whoever picks this up: this isn't a usage question, it's a reproducible data-loss defect in the hosted YouTube tool — YOUTUBE_UPDATE_VIDEO forwards a partial status object to videos.update, which YouTube documents as destructive, so unrelated settings are silently reset. Evidence is in the description: 55 control videos kept embeddable: true, while the 6 that received a privacy_status write all flipped to false.

Two things that make it worse in practice:

1. It's unrecoverable through the toolkit — no tool exposes embeddable or publicStatsViewable, so once clobbered the only fixes are YouTube Studio by hand or bypassing Composio.

2. YOUTUBE_UPDATE_VIDEO: expose status.publishAt so videos can be scheduled #4014 (closed as a tool request) is the direct cause of the exposure. Without status.publishAt, scheduled publishing has to be done by repeatedly calling privacy_status — which is exactly the call that breaks things. Adding publishAt would let people avoid the bug entirely. I ended up going straight to the YouTube API for 55 videos to work around both.

Happy to provide any further detail.

[abhishekpatil4]

Hi Nathan Pelton (@nathanpelton) , thanks for reporting this and for including the detailed reproduction steps. I’ve relayed it internally to the team, and .we’ll be taking a closer look.

[nathanpelton]

No — they aren't preserved, and that's the defect.

videos.update is a full replace on whatever part you send. Google documents it:

If you are submitting an update request, and your request does not specify a value for a property that already has a value, the property's existing value will be deleted.

YOUTUBE_UPDATE_VIDEO accepts title, description, tags, category_id and privacy_status — but not embeddable, publicStatsViewable or publishAt. So any call that touches status sends a status part containing only privacyStatus, and YouTube clears the rest.

The costly one for us wasn't embeddable — it was publishAt. We publish an audiobook as scheduled chapters months out. Editing a scheduled video's metadata through this tool drops its publish time, and the video sits private instead of going live on its date. There's no way to set it back through the tool, because publishAt isn't exposed either. (That was originally #4014, closed as a tool request; it's the same root cause as this issue.)

Fixes, in order of preference:

1. Read-modify-write inside the tool — videos.list(part=status), merge the caller's changes over what's already there, then update. Fixes every field at once, no signature change.
2. Expose embeddable, publicStatsViewable, publishAt, license and selfDeclaredMadeForKids so a caller can at least round-trip them.
3. At minimum, document that any status write is destructive to the rest of status.

We've worked around it since July by calling videos.update through proxy_execute with a complete status object. Two of our chapters are currently holding publish dates in 2027 across repeated metadata edits — that's the workaround holding, not the tool.