@agent-native/core 0.219.0 → 0.220.0-nightly-20261023212848

package/dist/tracking/providers.js

@@ -9,6 +9,8 @@ const AGENT_NATIVE_ANALYTICS_DEFAULT_ENDPOINT = "https://analytics.agent-native.
 export const AGENT_NATIVE_ANALYTICS_PROVIDER = "agent-native-analytics";
 const BATCH_INTERVAL_MS = 10_000;
 const MAX_BATCH_SIZE = 50;
+// The PostHog, Segment and Amplitude Node SDKs' default request timeout.
+const SEND_TIMEOUT_MS = 10_000;
 const QUEUE_KEY = Symbol.for("@agent-native/core/tracking.queue");
 const TIMER_KEY = Symbol.for("@agent-native/core/tracking.timer");
 function getQueue() {
@@ -52,6 +54,7 @@ function drainQueue() {
         method: "POST",
         headers: { "Content-Type": "application/json", ...item.headers },
         body: item.body,
+        signal: AbortSignal.timeout(SEND_TIMEOUT_MS),
     }).then(() => undefined, () => undefined)));
 }
 function isLocalhostUrl(value) {

package/dist/triggers/actions/manage-automation.d.ts

@@ -67,6 +67,7 @@ declare const _default: import("../../action.js").ActionDefinition<{
     triggerType: "event" | "manual" | "schedule" | "webhook";
     body: string;
 }, {
+    updated?: undefined;
     created: boolean;
     resourceId: string;
     name: string;
@@ -88,16 +89,15 @@ declare const _default: import("../../action.js").ActionDefinition<{
     mcpTools: string[];
     webhookPath: string;
     deleted?: undefined;
-    updated?: undefined;
     changed?: undefined;
     previouslyEnabled?: undefined;
     requestedEnabled?: undefined;
 } | {
+    updated?: undefined;
     created?: undefined;
     deleted: boolean;
     resourceId: string;
     name: string;
-    updated?: undefined;
     scope?: undefined;
     triggerType?: undefined;
     event?: undefined;

package/docs/content/external-agents.mdx

@@ -309,7 +309,7 @@ need a connector such as `npx @agent-native/core@latest connect https://assets.a
 | `visual-plans` | `agent-native-plans` | visual plans, recaps, and repo-native docs      |
 | `context-xray` | `xray`               | local Codex/Claude Code context usage           |
 
-The default client selection is all supported local clients; add `--client codex`, `--client claude-code`, or another specific target to narrow setup. Inline hosts (ChatGPT, Claude.ai, Claude Desktop main chat) render the picker / variant grid in chat; CLI/link-only hosts (Codex, Claude Code, Claude Desktop "Code" tab) return an "Open in … →" link where the user picks in the browser and pastes a handoff summary back.
+The default client selection is all supported local clients; add `--client codex`, `--client claude-code`, or another specific target to narrow setup. Inline hosts (ChatGPT, Claude chat on web, desktop, and mobile, plus the Claude Desktop Code tab) render the picker / variant grid in chat; CLI/link-only hosts (Codex CLI, Claude Code terminal, Cowork, Code on claude.ai web) return an "Open in … →" link where the user picks in the browser and pastes a handoff summary back. [Cowork doesn't declare MCP Apps yet](https://github.com/anthropics/claude-code/issues/103924), and using it on the same connector can make inline apps disappear in Chat until you reconnect the connector.
 
 When you truly need an isolated app instead of Dispatch's workspace gateway,
 run the same command with that app's host:

package/docs/content/mcp-apps.mdx

@@ -15,7 +15,7 @@ description: "Author and embed interactive MCP App UIs inside Claude, ChatGPT, a
 | Build generated inline UI inside Agent-Native chat           | [Generative UI](/docs/generative-ui)     |
 | Lower-level MCP server reference (auth, tools, custom mount) | [MCP Server](/docs/mcp-protocol)         |
 
-MCP Apps are the official `io.modelcontextprotocol/ui` extension that lets compatible hosts — Claude, Claude Desktop, ChatGPT, VS Code GitHub Copilot, Goose, Postman, MCPJam, and Cursor — render interactive UIs inline in chat. In agent-native apps, every MCP App is a **real React route**, not a separate plain-HTML widget.
+MCP Apps are the official `io.modelcontextprotocol/ui` extension that lets compatible hosts — Claude, ChatGPT, VS Code GitHub Copilot, Microsoft 365 Copilot, Cursor, Goose, Postman, MCPJam, and others — render interactive UIs inline in chat. In agent-native apps, every MCP App is a **real React route**, not a separate plain-HTML widget.
 
 Inside an Agent-Native app's own chat, prefer [native chat renderers](/docs/native-chat-ui) for first-party widgets such as tables, charts, typed results, and approval affordances. Use [Generative UI](/docs/generative-ui) when the in-app agent should create arbitrary sandboxed controls or visualizers inline. Use MCP Apps for external/cross-host inline UI in Claude, ChatGPT, Copilot, Cursor, and other compatible hosts, with the action `link` as the universal deep-link fallback.
 
@@ -241,9 +241,9 @@ Display mode is best-effort. The in-app `McpAppRenderer` currently reports an in
 
 ## Host support and caching {#client-support}
 
-The current official MCP Apps client list includes Claude, Claude Desktop, VS Code GitHub Copilot, Goose, Postman, MCPJam, ChatGPT, and Cursor; host support still varies by plan, release channel, and client version, so check the [MCP extension support matrix](https://modelcontextprotocol.io/extensions/client-matrix). ChatGPT custom MCP apps are available through developer mode for Business and Enterprise/Edu workspaces on ChatGPT web; see OpenAI's [developer mode and MCP apps](https://help.openai.com/en/articles/12584461-developer-mode-and-full-mcp-apps-in-chatgpt-beta) notes.
+Hosts that render MCP Apps inline include Claude chat on web, desktop, and mobile, plus the Claude Desktop Code tab; ChatGPT; VS Code GitHub Copilot (1.109+); Microsoft 365 Copilot; Cursor (2.6+); Goose; Postman; MCPJam; Codex Desktop (26.616+); and T3 Code (in Codex threads). Host support still varies by plan, release channel, and client version, so check the [MCP extension support matrix](https://modelcontextprotocol.io/extensions/client-matrix). ChatGPT custom MCP apps are available through developer mode for Business and Enterprise/Edu workspaces on ChatGPT web; see OpenAI's [developer mode and MCP apps](https://help.openai.com/en/articles/12584461-developer-mode-and-full-mcp-apps-in-chatgpt-beta) notes.
 
-Claude Code, Codex, and other CLI/code-editor clients still receive the same resources and metadata when they support MCP Apps, but treat them as link-out hosts unless you have verified inline iframe rendering in that exact surface. The deep link remains the reliable fallback when a host chooses not to render an iframe. In practice, every agent-native app should be authored with both: MCP Apps for inline review/edit in capable hosts, and `link` for universal round-tripping back to the full app.
+The Claude Desktop Code tab renders MCP Apps, as observed in [widget data](https://github.com/anthropics/claude-code/issues/103809) and [tool-name](https://github.com/anthropics/claude-code/issues/104045) bug reports. Use the deep-link fallback in the Claude Code terminal, Cowork, Code on claude.ai web, and the Codex CLI. [Cowork doesn't declare MCP Apps yet](https://github.com/anthropics/claude-code/issues/103924), and using it on the same connector can make inline apps disappear in Chat until you reconnect the connector. For other clients, verify inline iframe rendering in the exact surface you target. The deep link remains the reliable fallback when a host chooses not to render an iframe. In practice, every agent-native app should be authored with both: MCP Apps for inline review/edit in capable hosts, and `link` for universal round-tripping back to the full app.
 
 Claude and ChatGPT can cache tool and resource metadata for an existing custom connector. After changing MCP App metadata, verify with a fresh tool call; if the host still uses the old descriptor, reconnect the Claude connector or rescan/review the ChatGPT connector so it refreshes the catalog. If Claude logs a warning about `_meta.ui.csp` or `_meta.ui.permissions` living on the tool descriptor after a deploy, that connector is using stale metadata: delete/reconnect the Claude connector and start a fresh chat.
 

package/docs/content/mcp-protocol.mdx

@@ -203,7 +203,7 @@ If an action declares `mcpApp`, the server advertises the official MCP Apps exte
 - Hosts that render MCP Apps show the UI inline; hosts that don't can still call the tool and use the deep-link fallback.
 - Product UIs should use `embedApp()` so the inline surface is the real React app route, or a focused route that renders a shared React component such as an Analytics chart — never a separate plain-HTML implementation.
 - The server emits both standard MCP Apps metadata and ChatGPT Apps SDK compatibility metadata so app-capable hosts find the same `ui://` resource.
-- The current official extension matrix includes Claude, Claude Desktop, VS Code GitHub Copilot, Goose, Postman, MCPJam, ChatGPT, and Cursor. Host support varies by version and plan — see the [External Agents Catalog — MCP Apps compatibility](/docs/external-agents-catalog#mcp-apps-compatibility) for the user-facing guidance.
+- Host support varies by plan, release channel, and client version. See [MCP Apps → Host support](/docs/mcp-apps#client-support) for rendering hosts and link-out clients, including Claude Code.
 
 ### MCP App embed bridge {#mcp-app-embed-bridge}
 

package/docs/content/sharing.mdx

@@ -197,6 +197,7 @@ A failed request sets `error` and keeps the rows already loaded. It never looks
 For a ready-made sidebar that combines owned chats, shared chats, and eligible started drafts, import `useOwnershipChatHistory()` and `OwnershipChatHistoryRail` from `@agent-native/toolkit/app/chat/ownership-history`. The adapter keeps owner and access-basis details on shared rows, pages each section independently, and retains rows and local optimistic changes when a refresh fails. Its mutation callbacks return `Promise<boolean>`, allowing the app to navigate only after a write succeeds. See [Sharing Kit](/docs/toolkit-sharing#shared-chat-history) for an example.
 
 An active empty draft remains selectable and runnable while its first save is pending. Until persistence is confirmed, hide pin, rename, and archive actions, and the adapter rejects calls to those callbacks. `ownDraftRows` supplies persistence provenance for owned drafts, while confirmed owned rows from the server list keep their normal actions. For custom `OwnDraftRow` values, set optional `persisted?: boolean` to `true` only for a confirmed persisted server row owned by the current user. Do not infer persistence from message count or active ID. Role, privacy, and whether the active draft is empty remain separate facts.
+Pins are personal: `pinnedAt` is the caller's pin, including on shared chats; list and search sort by it. `useChatThreads().pinThread(id, pinned)` keeps its existing signature. Both `useChatThreads()` and `useChatThreadList()` provide `hideThread(id, hidden)` for shared chats. Hidden chats are excluded from list and search unless `includeHidden: true` is set; their rows and single-thread reads include the caller's `hiddenAt`. Opening a hidden chat by id or link still works. Owners cannot hide their own chats; they archive instead. Rename and archive remain owner-only. Hide throws `ChatThreadMutationError` on HTTP refusals (`status` 403 for owners, 404 without access); successful calls return `true`. The HTTP contract is `POST /_agent-native/agent-chat/threads/:id/hide` with `{ hidden: boolean }`; list/search use `includeHidden=1`. The `chat-history` tool supports `pin`, `unpin`, `hide`, `unhide`, and search with `includeHidden: true`. Revoking access hides prior viewer state; deleting a thread deletes that state.
 
 ## Same model, agent and UI {#agent-and-ui}
 

package/docs/content/template-assets-integrations.mdx

@@ -52,8 +52,10 @@ copies a handoff summary and shows a copyable context block; paste that summary
 back into the chat so the external agent can use the selected media URL and
 asset metadata.
 
-Codex, Claude Code, and Claude Desktop Code should be treated as link-out hosts
-for this flow. They may not render MCP Apps inline, and remote CDN markdown
+Codex CLI, the Claude Code terminal, Cowork, and Code on claude.ai web use the
+link-out flow. For rendering hosts, including the Claude Desktop Code tab and
+Codex Desktop, see
+[MCP Apps → Host support](/docs/mcp-apps#client-support). Remote CDN markdown
 images may not display reliably in the chat transcript. Agents should keep the
 asset link as the source of truth; when a visible inline preview is needed in a
 code-editor chat, download the selected `previewUrl`/`downloadUrl` to a local
@@ -211,7 +213,7 @@ Generate and pick brand media without leaving Codex, Claude Code, Claude, or Cha
    the one-command setup.
 
 2. **Ask for images.** In your agent's chat: "Generate three blog hero options from the Acme product shots." The agent opens the picker with candidate images you can regenerate, retune (prompt, aspect, count), and choose from.
-3. **Pick.** In inline hosts (ChatGPT, Claude.ai, Claude Desktop main chat) the picker renders right in the chat — click a candidate and the choice flows back automatically. On CLI/link-only hosts (Codex, Claude Code, Claude Desktop "Code" tab) you get an **"Open in Assets →"** link; open it, pick in the browser, then paste the copied handoff summary back into your chat — or just say "use image A".
+3. **Pick.** In inline hosts (ChatGPT, Claude chat on web, desktop, and mobile, plus the Claude Desktop Code tab) the picker renders right in the chat — click a candidate and the choice flows back automatically. On CLI/link-only hosts (Codex CLI, Claude Code terminal, Cowork, Code on claude.ai web) you get an **"Open in Assets →"** link; open it, pick in the browser, then paste the copied handoff summary back into your chat — or just say "use image A". [Cowork doesn't declare MCP Apps yet](https://github.com/anthropics/claude-code/issues/103924), and using it on the same connector can make inline apps disappear in Chat until you reconnect the connector.
 4. **Apply to code.** The chosen Media URL and `assetId` come back to the agent, which uses the URL directly in the code it writes (an `<img>` src, a download) or calls `export-asset`.
 
 ### Distributing the app skill

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.219.0",
+  "version": "0.220.0-nightly-20261023212848",
   "description": "The agentic application framework for building autonomous agents with intuitive UIs",
   "homepage": "https://github.com/BuilderIO/agent-native#readme",
   "bugs": {
@@ -730,7 +730,7 @@
     "yaml": "^2.9.0",
     "yjs": "^13.6.33",
     "zod": "^4.3.6",
-    "@agent-native/agentkit": "^0.219.0",
+    "@agent-native/agentkit": "^0.220.0-nightly-20261023212848",
     "@agent-native/recap-cli": "^0.5.88"
   },
   "devDependencies": {
@@ -801,7 +801,7 @@
     "xlsx": "^0.18.5"
   },
   "peerDependencies": {
-    "@agent-native/core-corpus": ">=0.196.0",
+    "@agent-native/core-corpus": "0.220.0-nightly-20261023212848",
     "@ai-sdk/anthropic": ">=3",
     "@ai-sdk/cohere": ">=3",
     "@ai-sdk/google": ">=3",

package/src/templates/chat/.agents/skills/actions/SKILL.md

@@ -172,6 +172,7 @@ Everything else — CRUD, settings, search, list/detail reads, auth state, anyth
 - **Do** signal failure by throwing, using `fail()` for expected caller-readable failures. Never return `{ error: ... }` as a failure result: a normal return is treated as a successful action. Reserve bare errors for unexpected internal faults.
 - **Do** use `fail()` rather than a bare `Error` for caller-readable failures. It carries the action's message, `errorCode`, and `details` to the browser and to agents; unexpected errors become a generic 500. Reserve bare throws for internal faults.
 - **Do** give `fail()` the status that matches the cause: it defaults to `400`, and `useActionQuery` retries only `429`, `502`, `503`, and `504`. Mutations do not retry; use transient statuses only for retryable failures.
+- **Do** throw `NoWriteError(message, { errorCode, statusCode })` instead of `fail()` for a rejection raised before the action's first write, such as an edit that matches nothing or a missing target. The agent then retries with corrected arguments instead of stopping on a write whose outcome is unknown. Throw it only before the first write: the framework rejects the claim when a nested write action ran, but it cannot see the handler's own writes.
 - **Do** render `actionErrorMessage(error) ?? yourCopy` in UI, never bare `error.message`. The message keeps an `Action <name> failed:` prefix that belongs in a console, so a toast built from it reads "Action update-brand-kit failed: That name is taken." The helper returns only what the action wrote, and `undefined` when nothing did (network drop, proxy HTML page), which is why the fallback is not optional.
 - **Do** pass a real `errorCode` when the agent should branch on the failure rather than re-read it. Codes other than the default `action_failed` are appended to the tool result as `(errorCode: not_found)`, on both the in-app agent and MCP. `details` follow as an `Error details: {...}` JSON line, and as `structuredContent.error` over MCP, capped at 2,000 characters, so keep them to what the agent acts on next: ids, limits, field names. The status never reaches either.
 - **Don't** re-export actions as REST — `/_agent-native/actions/:name` is already the REST surface; duplicating it under `/api/*` hides the operation from agents.

package/src/templates/default/.agents/skills/actions/SKILL.md

@@ -172,6 +172,7 @@ Everything else — CRUD, settings, search, list/detail reads, auth state, anyth
 - **Do** signal failure by throwing, using `fail()` for expected caller-readable failures. Never return `{ error: ... }` as a failure result: a normal return is treated as a successful action. Reserve bare errors for unexpected internal faults.
 - **Do** use `fail()` rather than a bare `Error` for caller-readable failures. It carries the action's message, `errorCode`, and `details` to the browser and to agents; unexpected errors become a generic 500. Reserve bare throws for internal faults.
 - **Do** give `fail()` the status that matches the cause: it defaults to `400`, and `useActionQuery` retries only `429`, `502`, `503`, and `504`. Mutations do not retry; use transient statuses only for retryable failures.
+- **Do** throw `NoWriteError(message, { errorCode, statusCode })` instead of `fail()` for a rejection raised before the action's first write, such as an edit that matches nothing or a missing target. The agent then retries with corrected arguments instead of stopping on a write whose outcome is unknown. Throw it only before the first write: the framework rejects the claim when a nested write action ran, but it cannot see the handler's own writes.
 - **Do** render `actionErrorMessage(error) ?? yourCopy` in UI, never bare `error.message`. The message keeps an `Action <name> failed:` prefix that belongs in a console, so a toast built from it reads "Action update-brand-kit failed: That name is taken." The helper returns only what the action wrote, and `undefined` when nothing did (network drop, proxy HTML page), which is why the fallback is not optional.
 - **Do** pass a real `errorCode` when the agent should branch on the failure rather than re-read it. Codes other than the default `action_failed` are appended to the tool result as `(errorCode: not_found)`, on both the in-app agent and MCP. `details` follow as an `Error details: {...}` JSON line, and as `structuredContent.error` over MCP, capped at 2,000 characters, so keep them to what the agent acts on next: ids, limits, field names. The status never reaches either.
 - **Don't** re-export actions as REST — `/_agent-native/actions/:name` is already the REST surface; duplicating it under `/api/*` hides the operation from agents.

package/src/templates/factory/.agents/skills/review-prs/SKILL.md

@@ -287,6 +287,12 @@ not already settled by Steve's written direction, flag it to Steve and do not
 merge until he decides. A routine bug fix or bounded improvement within an
 established workflow is not a major decision.
 
+Keep the PR thread silent while a product, UX, or app-owner decision is
+unresolved. Do not comment or reply to request, announce, or explain that the
+decision is needed; record the gate only in the recap. This remains true after
+an author update, so do not send a thanks-only or status-only reply while the
+decision is pending.
+
 The app-owner map is for approval exceptions only; an owner approval is not a
 merge requirement:
 
@@ -455,12 +461,29 @@ code or screenshot requests. This also applies when another comment or bot
 event is newer than Steve's request; bot activity alone does not reopen the
 handoff.
 
+On a contributor-owned PR, do not draft a follow-up unless the author has made
+a substantive update since Steve's last message. Begin a first reply by
+thanking the author for the PR; if replying after an author update, begin by
+thanking them for that update. Never write “I have no further feedback” or
+another vague closing. State the disposition, the exact next action, and who
+owns it. If a product, UX, or app-owner decision is still needed, do not post
+an author-facing status comment or ask the author to get that review; keep the
+thread silent and report the decision gate in the recap. Never comment that a
+product owner needs to review the PR. For a contributor thread paused by an
+unresolved gate, an internal decision does not count as an author update, and
+an author update made while the decision is pending does not qualify for a
+follow-up. Keep the thread silent until the decision is resolved and the author
+makes a substantive update after resolution; then thank them for that update
+and state the resolved disposition, exact next action, and owner. This
+contributor-update gate does not govern review feedback on the active user's
+own PR; follow the own-PR review-update rule in `ship`.
+
 If no prior Steve request is awaiting an update and this would be Steve's first
 comment on that PR, begin the draft with a warm thank-you that tags the author
 using the exact GitHub `author.login` from the live PR metadata, for example:
 
 ```text
-Thanks for the contribution @username!
+Thanks for the PR, @username!
 
 Couple requests. Can you please [make the specific update] so [the intended
 behavior or outcome] is preserved?
@@ -473,8 +496,9 @@ the concrete request in a friendly, conversational way (for example, "Couple
 requests. Can you please ...?"). Keep the technical request specific,
 actionable, and supported by the diff or source evidence; ask for a regression
 test when appropriate to the code change rather than as a blanket requirement.
-Do not repeat a thank-you on a follow-up. Do not draft a duplicate request when
-an existing Steve comment already covers it; link or summarize that request
+For a follow-up after an author update, thank them for that update rather than
+repeating the first-contact thanks. Do not draft a duplicate request when an
+existing Steve comment already covers it; link or summarize that request
 instead. Drafts are for the user to review and are never posted by this skill
 unless the current invocation explicitly authorizes posting.
 

package/src/templates/headless/.agents/skills/actions/SKILL.md

@@ -172,6 +172,7 @@ Everything else — CRUD, settings, search, list/detail reads, auth state, anyth
 - **Do** signal failure by throwing, using `fail()` for expected caller-readable failures. Never return `{ error: ... }` as a failure result: a normal return is treated as a successful action. Reserve bare errors for unexpected internal faults.
 - **Do** use `fail()` rather than a bare `Error` for caller-readable failures. It carries the action's message, `errorCode`, and `details` to the browser and to agents; unexpected errors become a generic 500. Reserve bare throws for internal faults.
 - **Do** give `fail()` the status that matches the cause: it defaults to `400`, and `useActionQuery` retries only `429`, `502`, `503`, and `504`. Mutations do not retry; use transient statuses only for retryable failures.
+- **Do** throw `NoWriteError(message, { errorCode, statusCode })` instead of `fail()` for a rejection raised before the action's first write, such as an edit that matches nothing or a missing target. The agent then retries with corrected arguments instead of stopping on a write whose outcome is unknown. Throw it only before the first write: the framework rejects the claim when a nested write action ran, but it cannot see the handler's own writes.
 - **Do** render `actionErrorMessage(error) ?? yourCopy` in UI, never bare `error.message`. The message keeps an `Action <name> failed:` prefix that belongs in a console, so a toast built from it reads "Action update-brand-kit failed: That name is taken." The helper returns only what the action wrote, and `undefined` when nothing did (network drop, proxy HTML page), which is why the fallback is not optional.
 - **Do** pass a real `errorCode` when the agent should branch on the failure rather than re-read it. Codes other than the default `action_failed` are appended to the tool result as `(errorCode: not_found)`, on both the in-app agent and MCP. `details` follow as an `Error details: {...}` JSON line, and as `structuredContent.error` over MCP, capped at 2,000 characters, so keep them to what the agent acts on next: ids, limits, field names. The status never reaches either.
 - **Don't** re-export actions as REST — `/_agent-native/actions/:name` is already the REST surface; duplicating it under `/api/*` hides the operation from agents.

package/src/templates/workspace-core/.agents/skills/actions/SKILL.md

@@ -172,6 +172,7 @@ Everything else — CRUD, settings, search, list/detail reads, auth state, anyth
 - **Do** signal failure by throwing, using `fail()` for expected caller-readable failures. Never return `{ error: ... }` as a failure result: a normal return is treated as a successful action. Reserve bare errors for unexpected internal faults.
 - **Do** use `fail()` rather than a bare `Error` for caller-readable failures. It carries the action's message, `errorCode`, and `details` to the browser and to agents; unexpected errors become a generic 500. Reserve bare throws for internal faults.
 - **Do** give `fail()` the status that matches the cause: it defaults to `400`, and `useActionQuery` retries only `429`, `502`, `503`, and `504`. Mutations do not retry; use transient statuses only for retryable failures.
+- **Do** throw `NoWriteError(message, { errorCode, statusCode })` instead of `fail()` for a rejection raised before the action's first write, such as an edit that matches nothing or a missing target. The agent then retries with corrected arguments instead of stopping on a write whose outcome is unknown. Throw it only before the first write: the framework rejects the claim when a nested write action ran, but it cannot see the handler's own writes.
 - **Do** render `actionErrorMessage(error) ?? yourCopy` in UI, never bare `error.message`. The message keeps an `Action <name> failed:` prefix that belongs in a console, so a toast built from it reads "Action update-brand-kit failed: That name is taken." The helper returns only what the action wrote, and `undefined` when nothing did (network drop, proxy HTML page), which is why the fallback is not optional.
 - **Do** pass a real `errorCode` when the agent should branch on the failure rather than re-read it. Codes other than the default `action_failed` are appended to the tool result as `(errorCode: not_found)`, on both the in-app agent and MCP. `details` follow as an `Error details: {...}` JSON line, and as `structuredContent.error` over MCP, capped at 2,000 characters, so keep them to what the agent acts on next: ids, limits, field names. The status never reaches either.
 - **Don't** re-export actions as REST — `/_agent-native/actions/:name` is already the REST surface; duplicating it under `/api/*` hides the operation from agents.

package/src/templates/workspace-core/.agents/skills/external-agents/references/mcp-apps-embedding.md

@@ -162,8 +162,15 @@ actions for Forms, Content, Clips, Slides, and Design. The action should return
 concise structured content plus the link; it should not dump large catalogs or
 HTML.
 
-Compatibility target: build to the standard once, not per-client shims. MCP
-Apps-capable hosts should include Claude/Claude Desktop/Claude Code, ChatGPT
-custom MCP apps, VS Code GitHub Copilot, Goose, Postman, MCPJam, Cursor, and
-any future host that follows the extension negotiation. Host support varies by
-plan, release channel, and client version, so keep the deep link fallback.
+Compatibility target: build to the standard once, not per-client shims.
+Hosts that render MCP Apps inline today include Claude chat on web, desktop, and
+mobile, plus the Claude Desktop Code tab; ChatGPT; VS Code GitHub Copilot (1.109+);
+Microsoft 365 Copilot; Cursor (2.6+); Goose; Postman; MCPJam; Codex Desktop (26.616+);
+and T3 Code (in Codex threads). Desktop Code rendering is observed in
+[widget bug reports](https://github.com/anthropics/claude-code/issues/103809).
+Treat the Claude Code terminal, Cowork, and Code on claude.ai web as link-out hosts.
+[Cowork doesn't declare MCP Apps yet](https://github.com/anthropics/claude-code/issues/103924),
+and using it on the same connector can make inline apps disappear in Chat until
+you reconnect the connector. Host support varies by plan, release channel, and client version,
+so keep the deep link fallback. See the community-maintained
+[MCP client matrix](https://modelcontextprotocol.io/extensions/client-matrix).