Remixing widgets

Remixing forks a widget into your account, gives you a fresh dedicated agent, and stamps an attribution line back to the original. The forked copy is yours to edit and republish; the source's author sees a bumped remix_count and can walk descendants.

The flow

Click "Remix this widget" in the workspace node toolbar (or the post detail overflow menu).

The platform clones the entire folder subtree into your content tree — files, tools, assets, nested folders, up to the depth / node caps (MAX_CLONE_DEPTH = 20, MAX_CLONE_NODES = 2000).

A fresh dedicated agent is minted with a user-scoped slug — bob-<yourId6>-<originalSlug>-r<N> where <N> increments per remix in your namespace.

The publish pipeline runs against your clone — function rows, agent_configs, skills.custom_http, skills.custom_tools are all stamped on the new agent.

The new content row records its lineage in three columns (remix_of_content_id, remix_of_post_id, remix_of_user_id) and the source post's remix_count increments.

You're dropped into your fork — edit widget.json, change index.html, add tools, then republish.

Attribution

Post cards for remixes render a "Remixed from @author/slug" line under the title. The line is attribution only — there's no CTA, no clickable jump elsewhere on the row. The post detail view embeds a lineage tree showing ancestors above and direct descendants below; clicking a node navigates to that widget.

The lineage walker walks up to 100 levels of ancestry / descent before truncating (truncated: true in the API payload). If you hit the truncation indicator on a viral widget, you're looking at a chain of remixes 100 deep — congratulations.

Which bundles can be remixed?

Bundle kind	Remixable?	Notes
`folder`	yes (full clone)	the first-class case
`external-cooperative` (URL import Tier A)	yes (catalog-row copy only)	your remix points at the same remote `manifestUrl` — you're forking the catalog listing, not the source
`external-passive` (URL import Tier B)	no	nothing to clone; the source is a remote iframe
`native` (built-in)	no	the behaviour lives in platform code
`system` (platform function)	no (v1)	reserved for future plans
live canvas items	no	a live item (browser, voice, screen) has no bundle; remix would silently spawn a new session on your quota

The detailed reasoning lives in ADR-v3-15. The user-visible error strings are i18n keys under widget.notRemixable.* (.passive, .native, .system, .live).

Dedicated agent naming

The slug bob-<userId6>-<slug>-r<N> is user-scoped by design — a remix by one user does not collide with a remix by another, even of the same source. New human usernames starting with bob- are rejected at signup to keep the namespace clean; existing grandfathered accounts are handled in a separate cleanup task.

If your remix slug collides (a prior remix of the same source by you, or a simultaneous mint), the platform appends -<N> and retries up to 5 times before surfacing an error.

After remixing

You own the fork's content rows and the new dedicated agent.

The source author keeps their bumped remix_count; they cannot delete your fork.

If the source author deletes their original, the lineage columns on your fork nullify (ON DELETE SET NULL); your post card stops showing "Remixed from" but otherwise nothing breaks.

Republishing your fork follows the same flow as authoring a fresh widget — see authoring.md.

What is NOT a remix

Editing your own widget in place — no new lineage; the existing catalog row is updated.

Importing a URL (Tier A / B) — that's an import (external-* bundle), not a remix.

Cloning a workspace — workspace cloning deep-copies items but does not stamp lineage columns; it's a private editing convenience, not publication.

See also: authoring.md for the publish pipeline and mcp-app-publishing.md for what external hosts see when they crawl the catalog.