Reason: Add the current MiniMax text models to BuiltInAgent model
resolution.
- Register MiniMax-M3 and MiniMax-M2.7 as built-in model identifiers.
- Resolve MiniMax model strings through the global endpoint with API key
and regional base URL configuration.
- Document both model specifiers and cover global and China endpoint
selection.
Checks:
- `node_modules/.bin/nx run @copilotkit/runtime:test --
src/agent/__tests__/resolve-model-baseurl.test.ts`
- `node_modules/.bin/nx run @copilotkit/runtime:check-types`
- `pnpm validate:model-names`
- `node_modules/.bin/nx format:check
--files=packages/runtime/src/agent/index.ts,packages/runtime/src/agent/__tests__/resolve-model-baseurl.test.ts`
- `git diff --check`
Fifteen defects in the shell-docs tree, each verified against the
running site or the source of truth rather than pattern-matched. Found
while root-causing
[PDX-313](https://linear.app/copilotkit/issue/PDX-313).
Scoped deliberately: this is content only. The checker changes that
surfaced these follow separately.
## Snippet components used with props but never imported (7)
The subtlest item here, and invisible to anyone skimming the source.
`<FrontendTools components={…} framework="pydantic-ai" />` without an
import falls through to `stubWithPartial` in the global mdx-registry,
which drops props "on the floor" by design. So `framework` never reached
the partial and the shared snippet rendered **untailored** — the reader
got generic content on a framework-specific page.
The `mastra` and `ag2` siblings were already correct. All seven broken
ones are in authored trees, matching the template-residue pattern from
OSS-777.
## Tutorial cross-links that land on the homepage (4)
`/tutorials/ai-todo-app` and `/tutorials/ai-powered-textarea` have no
`index.mdx`, so they `307 -> /`. A reader clicking "next: the todo app
tutorial" gets the docs homepage. The pages are at `/overview`.
## Dead `YouTubeVideo` imports (2)
The component is provided globally by `mdx-registry.tsx`, and four other
pages render it with no import at all. These two imported a module that
has never existed in the repo.
## Stale `byoc-*` demo ids (2)
Renamed to `declarative-*` in 70e2fb31 (2026-05-10, *"rename byoc-\*
slugs to declarative-\*"*); the docs were never updated, so the ids
resolve against nothing in the registry. Only the three registry ID
references per page change — `snippet_cell`, `InlineDemo`,
`IntegrationGrid`.
## What was cut, and why
An earlier revision of this PR also rewrote nine `/integrations/<fw>/*`
links to their canonical URLs. Checking production, those were never
broken:
```
/integrations/adk/quickstart -> 301 /google-adk/quickstart
```
`seo-redirects.ts` keeps that retired surface alive for inbound SEO
traffic, so readers always landed correctly. Canonicalizing them is
still worth doing — a 301 costs a round trip and couples internal
navigation to a legacy surface — but it is cosmetic, and it was padding
a diff whose value is the defects above. Dropped; tracked separately.
## Left alone deliberately
The `runtimeUrl` / `agent` code samples on `generative-ui/hashbrown.mdx`
and `generative-ui/json-render.mdx`. The API routes were renamed to
`copilotkit-declarative-*`, but the agent ids were **not** renamed
consistently:
| demo | agent id |
| --- | --- |
| `declarative-hashbrown` | `agent="declarative-hashbrown-demo"`
(renamed) |
| `declarative-json-render` | `AGENT_ID = "byoc_json_render"` (not
renamed) |
A blind find-and-replace over `byoc-` would have shipped a broken
copy-paste sample. Needs an owner's call.
## Review notes
15 files, +17/-12. The seven import additions are the only changes that
affect what renders; the rest are identifier strings and link targets.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What does this PR do?
`@copilotkit/react-native` maintained a **private tool-call render
registry** (`hooks/RenderToolContext.tsx`) alongside the canonical one
that `CopilotKitCoreReact` already provides — and which every React
Native app already ships, unused. This PR deletes the fork and points
React Native at the shared registry.
That fork caused three bugs:
| Bug | Symptom | Cause |
|---|---|---|
| **Tool renders never streamed** | A component registered with
`useRenderTool` / `useComponent` painted nothing until the tool call
completed | `CopilotChat` used `JSON.parse` on the argument buffer.
While a model writes a tool call that buffer is *invalid JSON by design*
— AG-UI delivers `TOOL_CALL_ARGS` deltas that are concatenated
client-side — so the parse threw on every delta, warned, and fell back
to `{}` |
| **`useComponent` rendered nowhere** | Silently, with no error | It
writes to core's registry; React Native's chat read React Native's
private `Map` |
| **Chat history degraded** | Navigating away from the registering
screen turned earlier tool calls into a `Called: <name>` placeholder |
The private `Map` deleted renderers on unmount; core deliberately keeps
them |
`@copilotkit/react-core` has used `partialJSONParse` on this path since
v2 shipped. React Native diverged because `useRenderToolCall` was
excluded from its re-exports on the stated grounds that it "depends on
DOM elements via `DefaultToolCallRenderer`" — a claim that was never
true of the hook itself. It was only ever reachable through the fat
`/v2` entry, whose weight is the real hazard (#4893). #5883 moved it
into `/v2/headless` on 2026-07-23; the exclusion comment was rewritten
the next day without revisiting the reason.
### What changed
- **One registry.** `useRenderTool` registers through `useFrontendTool`
into `CopilotKitCoreReact.renderToolCalls`. `CopilotChat` and any custom
surface consume react-core's `useRenderToolCall`.
- **Types are derived, not declared.** `RenderToolProps` is now
`React.ComponentProps<ReactToolCallRenderer<T>["render"]>`, so React
Native cannot drift from `ReactToolCallRenderer` — the contract every
registered renderer is actually invoked against. Change that contract
and `check-types` names every React Native renderer the change breaks.
React Native narrows only the *return* type to `ReactElement | null`,
which `FlatList`'s `renderItem` genuinely requires.
_Scope of that guarantee (corrected during review):_ it does **not**
extend to the type react-core publicly exports under the same name.
Web's `RenderToolProps<S>`
(`react-core/src/v2/hooks/use-render-tool.tsx`) is a separate
hand-declared union, generic over a schema, carrying arguments under
`parameters` (not `args`) and declaring `status` as string literals
rather than `ToolCallStatus` members. Both divergences are live today
and nothing type-checks them shut — the one place the shapes meet,
react-core's own bridge, compiles because a string-enum member is
assignable to its own literal type but not the reverse. Aligning web's
alias is a breaking web API change, filed separately.
- **`RenderToolContext.tsx` deleted** (−150 lines), along with 15 tests
that described the removed subsystem. One of them — `unregisters the
render function on unmount` — asserted the chat-history bug as a
requirement.
- **Two structural CI guards for #4893**, in opposite directions: a test
failing if any React Native source imports the fat `/v2` entry, and a
script failing if react-core's `/v2/headless` or `/v2/context` chunks
ever link shiki/mermaid/cytoscape/katex/streamdown. Both were verified
able to fail by deliberately introducing the regression. These are
*structural* assertions, not size budgets — `dev-docs/bundle-size.md`
freezes `limit` fields until OSS-122.
- **`react-native` added to the bundle-size glob**, which it had never
been in, plus a `size:headless` measurement.
React Native also gains capabilities it lacked: render props inferred
from your schema, `name`/`toolCallId` on render props, and `result` on
completed calls.
**Corrected during review — two capabilities this originally claimed are
not delivered:**
- **Wildcard (`"*"`) renderers do not work on React Native.** Because
`useRenderTool` routes through `useFrontendTool` (which calls
`addTool`), `name: "*"` registers a frontend tool literally named `*` —
advertised to the model, and colliding with core's separate
wildcard-executable-tool path. react-core's `useRenderTool` is
renderer-only and special-cases the wildcard; React Native's is not. The
guide now advises against it.
- **`followUp` (and `available`) are not forwarded**, and the handler's
`context` argument is dropped, so `stopAgent()`'s abort signal is
unreachable from an RN handler.
Both are tracked in § Known limitations for the follow-up that converges
React Native onto react-core's hooks — deleting RN's `useRenderTool` in
favour of re-exporting `useFrontendTool` (tool + renderer) and
react-core's `useRenderTool` (renderer-only, wildcard-capable). That is
an API change with its own migration note, so it is not in this PR.
### ⚠️ Breaking (in a minor)
`useRenderToolRegistry` and `RenderToolProvider` are **removed**. Both
are documented on the docs site, so this is a real break — see the
`BREAKING CHANGE:` footer on `db67ccf`, which is what the release notes
derive from, plus the rewritten reference pages.
```diff
- const registry = useRenderToolRegistry();
- const renderer = registry.get(toolCall.function.name);
- return renderer ? renderer({ args, status }) : null;
+ const renderToolCall = useRenderToolCall();
+ return renderToolCall({ toolCall });
```
Also note two semantic changes: `args` is `Partial<T>` **only** while
`status` is `"inProgress"`, and a render function is now captured at
registration — if it closes over changing values you must declare them
in `deps` (React Native previously refreshed the closure on every
render).
**Known limitation:** agent-scoped renderer resolution does not take
effect on React Native. `CopilotChatConfigurationProvider` is not in
RN's provider tree, so `agentId` always resolves to the default.
Renderers still resolve by name; two agents registering the same tool
name resolve arbitrarily. Filed separately.
### A data point worth recording
Adding `useRenderToolCall` to the measured headless entry moved the
bundle **92.8 kB → 92.7 kB**. Flat. The hook React Native spent months
not using was already inside the chunk every RN app resolves whole —
Metro doesn't tree-shake, so the fork never saved a byte. It cost them.
### Testing
- `@copilotkit/react-native`: **253 passing / 22 files** ·
`@copilotkit/react-core`: **1480 passing / 123 files** · `check-types`
and `build` green for both.
- Each of the three bugs has a deterministic test driving a real
`CopilotKitCoreReact` — no mocking of the code under test.
- Both #4893 guards carry mutation evidence: introduce the regression,
watch them fail, revert, watch them pass.
### Follow-up
`useRenderTool`'s JSDoc is split across two blocks, which orphans the
primary description from IDE hover (the `@param deps` warning still
surfaces). One-line fix, deliberately left out of the final fix wave.
## Related PRs and Issues
- **Supersedes #6346** (@davidmckayv) — its diagnoses were correct and
its test assertions are ported here, re-driven through the real registry
rather than a mocked local one. Credited via `Co-Authored-By` on
`4104bd1`.
- Addresses the React Native half of **#4893**.
- Builds on **#5883**, which created the lean `/v2/headless` entry this
PR consumes.
## Checklist
- [x] I have read the Contribution Guide
- [x] If the PR changes or adds functionality, I have updated the
relevant documentation
- [x] "Allow edits by maintainers" is checked
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The PR's reviewer asked that the `RenderToolProps` shape change be covered where upgraders
actually read it. A `BREAKING CHANGE:` footer on ec42161670 already describes it, but that
footer reaches no reader: `scripts/release/lib/changes.ts:43` collects commits with
`--format=%H %s`, and `grep -rn "BREAKING" scripts/release/` returns zero hits, so no footer
in this repo has ever reached generated release notes. The docs page is the destination that
does reach users. (The collector is a release-pipeline bug, filed separately.)
Checked every item in ec42161670's inventory against the page. All were present and accurate
except one: the page said renderers "must now tolerate missing fields while in progress" and
stopped there, naming no error code and never mentioning `check-types`. That is the half of
the change most existing renderers trip over, and it breaks the build, not the screen.
Added to the migration section: on the un-narrowed union `args` is `Partial<T> | T`, so
`args.foo` reads as `T["foo"] | undefined` and a strict `tsc --noEmit` rejects any use needing
the field present — TS18048 when dereferencing or calling it, TS2322/TS2345 when passing it
into a slot typed without `undefined`. Deliberately NOT claimed as a blanket "every read
fails": a bare JSX interpolation still compiles because an element accepts `undefined`
children, and the page's own Usage example does exactly that, so the blanket form would have
contradicted a working example on the same page. Added a fix diff narrowing on `status`, and
a cross-link to the two Behavior-section breaks a migration-only reader would otherwise
miss (render captured at registration, unmount keeping the renderer).
Verified against source, not just the footer: the three-arm union in
react-core/src/v2/types/react-tool-call-renderer.ts, the effect keyed on
JSON.stringify(deps) and the cleanup that removes only the tool in use-frontend-tool.tsx,
and `"strict": true` plus `check-types` in the react-native package.
Docs only; one file, no restructuring, nothing removed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The guide told readers that a `"*"` entry resolves as a renderer-only wildcard
on React Native "exactly as it does on the web", and framed the one difference
as an ergonomic tax (a `"*"` entry "still needs `parameters`"). That is false,
and the real consequence is not ergonomic.
react-core's `useRenderTool` is renderer-only: its body's sole registration is
`addHookRenderToolCall` (use-render-tool.tsx:190), and it special-cases
`name === "*" && !parameters` into a schema-less fallback renderer
(use-render-tool.tsx:166) which `useRenderToolCall` resolves last
(use-render-tool-call.tsx:151). React Native's hook instead delegates wholesale
to `useFrontendTool` (useRenderTool.ts:53), which calls `addTool`
unconditionally (use-frontend-tool.tsx:23). So on RN `name: "*"` registers a
frontend tool literally named `*`. `buildFrontendTools` has no wildcard
exclusion (run-handler.ts:1236), so that tool is advertised to the model in the
run's tool list, and it occupies core's separate wildcard-executable-tool slot
(run-handler.ts:610, 626) whose handler is invoked for every unmatched tool call
with args wrapped as `{ toolName, args }` (run-handler.ts:988) rather than in
the caller's declared shape.
- Rewrote the bullet to advise against `"*"` on React Native and state the
mechanism. Also completed its requirements list: `description` is as
non-optional as `parameters` (useRenderTool.ts:13), and react-core's hook
takes no `description` at all.
- Fixed the example's `status !== "complete"`, which was a web-shaped parity
assumption that does not compile: RN's props derive from
`ReactToolCallRenderer`, whose `status` is the `ToolCallStatus` enum, not
web's string literals. Branches on `ToolCallStatus.Complete` now, and notes
the `args`-vs-`parameters` difference alongside it.
- Added a Known limitations entry, in the voice of the `threadId` one, covering
the wildcard gap plus two more the audit turned up: `followUp` and
`available` are accepted by `useFrontendTool` and not forwarded, and the
`handler` type drops the `context` argument core does pass at runtime
(run-handler.ts:821). All tracked for the convergence follow-up.
No `followUp` claim was present on the page to correct — the gap is real, so it
is documented as a limitation rather than a retraction. No behaviour change:
`packages/react-native/src/hooks/useRenderTool.ts` is untouched, the
convergence is its own PR.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
An earlier commit rewrote the useRenderTool reference to say that comparing a render prop's
`status` against a raw string no longer type-checks, and called that a breaking change. That
was wrong, and it made upgraders believe working code was broken.
`ToolCallStatus` is a string enum, and TypeScript relates an enum literal type to a
same-valued plain string literal (not the reverse). Equality tests comparability both ways, so
`status === "complete"` compiles AND narrows. Only two forms fail: comparing against a string
that matches no member (TS2367), and assigning a raw string to a `status`-typed variable
(TS2322) — assignment, never comparison.
Corrected all three sites that claimed otherwise (the RenderToolProps narrative, the `status`
PropertyReference, and the migration section's "both halves are breaking"). The enum-based
examples stay, now framed as recommended style — self-documenting, and loud if a member's
value changes — rather than a compilation requirement. The migration section now names the
added `InProgress` arm as the one genuinely breaking half.
Also fixed a separate false claim in the same file: the out-of-chat rendering example said
that without a `toolMessage` the status "stays InProgress ... forever". `useRenderToolCall`
reads `executingToolCallIds` from the provider and branches toolMessage -> Complete, else
isExecuting -> Executing, else InProgress, so the Executing arm is reachable with no tool
message at all.
Docs only; no source behaviour changes.
## What does this PR do?
Fixes stale Copilot Runtime documentation links that still point to
`/concepts/copilot-runtime` and now route users to the existing
`/backend/copilot-runtime` page.
This updates both the source JSDoc and the generated reference MDX so
the current docs content and future regenerated reference docs stay
aligned.
## Related PRs and Issues
- Closes#2082
## Testing
- `rg -n "concepts/copilot-runtime" packages
showcase/shell-docs/src/content` returns no matches
- `rg -n "backend/copilot-runtime"
packages/runtime/src/lib/runtime/copilot-runtime.ts
packages/react-core/src/components/copilot-provider/copilotkit-props.tsx
showcase/shell-docs/src/content/reference/v1/classes/CopilotRuntime.mdx
showcase/shell-docs/src/content/reference/v1/components/CopilotKit.mdx`
- `git diff --check`
## Checklist
- [x] I have read the [Contribution
Guide](https://github.com/copilotkit/copilotkit/blob/master/CONTRIBUTING.md)
- [x] If the PR changes or adds functionality, I have updated the
relevant documentation
- [x] "Allow edits by maintainers" is checked (lets us help iterate on
your PR directly — faster turnaround for everyone)
## Summary
This establishes a stronger machine-readable source of truth for agents
choosing and implementing CopilotKit:
- lock production docs canonicals, Open Graph URLs, robots, sitemap, and
LLM artifacts to `https://docs.copilotkit.ai`, with deploy smoke
coverage that fails loudly on hostname leakage
- add a versioned, generated public API manifest covering 26 packages,
92 public import paths, runtime adapters, host factories, compatibility
ranges, and source-backed deprecations
- add manifest drift detection to the release suite and root
generate/check commands
- update the public setup/debug/package skills and their deterministic
evals to current package names, factories, repository paths, and
`1.67.1` metadata
- keep package-owned skills and top-level public mirrors in sync
## Growth impact
Agents should encounter one consistent answer across docs metadata,
LLM-facing artifacts, release metadata, and executable skills. That
reduces hallucinated imports and stale setup paths while giving crawlers
and coding agents a concrete reason to select CopilotKit for
agent-native application experiences—including agent-to-agent
interaction, shared state, human-in-the-loop workflows, tool rendering,
and generative UI.
## Validation
- frozen lockfile install passed
- changed-file formatting passed
- repository lint passed with existing warnings only
- full Nx typecheck passed: 32 projects plus dependencies
- focused docs/manifest/skill suites passed: 4 files, 113 tests
- shell-docs typecheck passed; shell-docs lint passed with existing
warnings
- plugin skill mirrors and public API manifest drift checks passed
- affected commit hook matrix passed tests, publint, and
are-the-types-wrong checks
- full package test matrix passed except two contention timeouts; both
failed projects then passed uncached in isolation:
- `@copilotkit/react-core`: 123 files, 1,481 tests
- `@copilotkit/vue`: 100 files, 1,074 tests
- corrected sequential Nx build passed for all 26 package projects
## Notes
- the repository-wide formatter currently reports 25 pre-existing files
on `main`; every file changed by this PR passes formatting
- deployed docs will continue exposing the old showcase hostname until
this change is promoted; the new production verification will block
future canonical, OG, robots, sitemap, `llms.txt`, or `llms-full.txt`
leakage
- no redirect is included for `docs.showcase.copilotkit.ai` because
ownership of that host is outside this repository's source of truth
Linear: PDX-316, PDX-318, PDX-319
The status PropertyReference declared a string-literal union while the usage
example below it compared against ToolCallStatus. The example was right: RN's
RenderToolProps is derived from ReactToolCallRenderer["render"], whose arms are
typed ToolCallStatus.InProgress/.Executing/.Complete, so a reader who followed
the type= attribute and wrote status === "executing" got TS2322.
Fixed both places that stated the type rather than the values: the
PropertyReference, and the migration section, which described the NEW status as
a literal union and so buried the actual breaking change (RN's old union really
was "executing" | "complete", so existing string comparisons stop compiling).
Added a diff showing that migration. Also aligned the value-naming prose and the
useRenderToolCall example comment on enum members, and recorded in the
RenderTool*Props comparison list that react-core's own props types do declare
status as string literals -- that contrast is real, not an error on this page.
Note: the example needs ToolCallStatus as a value, but react-native/headless.ts
currently re-exports it under `export type`. That export fix is owned elsewhere.
The `deps` array was documented as "similar to `useEffect`" in both the
PropertyReference and the Behavior list. It is not: `useEffect` compares
elements with `Object.is`, while this hook serialises the whole array with
`JSON.stringify` and compares the string
(packages/react-core/src/v2/hooks/use-frontend-tool.tsx:45).
That difference is load-bearing now that React Native's `useRenderTool`
registers through `useFrontendTool` and the documented remedy for its
capture-at-registration semantics is "declare changing values in deps".
Both sites now state the real comparator and link a new "Dependency
comparison" section that tabulates the measured consequences: functions,
`undefined` and symbols serialise to `null`; `Map`/`Set` and instances
whose state is in `#private` fields or prototype getters collapse to `{}`
(own enumerable fields do compare); key order is significant; circular
values and `BigInt` throw during render. The section closes with the two
patterns that work -- a derived primitive, or a latest-value ref.
The react-core/web copy of this page has the same defect and is deferred
to a follow-up.
The React Native guide still described the pre-convergence world: it listed
`useRenderToolCall` among the hooks React Native does not export, and told
readers React Native keeps a render registry separate from react-core's.
Both are now false.
- `useRenderToolCall` IS exported (`src/headless.ts`), along with the
`ReactToolCallRenderer` type. The remaining three web rendering hooks
(`useDefaultRenderTool`, `useRenderCustomMessages`,
`useRenderActivityMessage`) are still genuinely absent, and stay listed with
the reason each one is held back.
- Wildcard resolution now applies on React Native. `useRenderTool` registers
through `useFrontendTool` into `CopilotKitCoreReact.renderToolCalls`, and
`useRenderToolCall` falls back to a renderer named `"*"`. Noted the one
remaining asymmetry: React Native's hook always registers a tool too, so a
`"*"` entry still needs `parameters`, where web has a renderer-only overload.
- The "two different registries" callout is rewritten. There is one registry,
so a `render` passed to `useFrontendTool` does draw in the React Native chat;
the reason to prefer `useRenderTool` is now its `ReactElement | null` return
type, not registry separation.
Left the same bullet's "requires `parameters`" claim alone — still true.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The migration note said only that `args` is partial while `status` is
"inProgress", with no before side. Read as a migration instruction it
implied the opposite of the real change: the old RN `RenderToolProps`
declared `args: T` (never partial) and `status: "executing" | "complete"`,
so the change ADDS an "inProgress" state in which `args` is `Partial<T>`
rather than narrowing a partiality that already existed.
Spell out old -> new for `status`, `args` and `result`, and name
"inProgress" as a newly-introduced status value.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The "Rendering a tool call outside the chat" snippet called the hook at
module top level, had a `return` at module scope (a syntax error), and
referenced an undefined `toolCalls` binding, so it could not be pasted.
Wrap it in a real component, source the tool calls from `useAgent()`'s
message list, and correlate each call with its tool-result message the way
the prebuilt RN chat does — without `toolMessage`, `status` stays
"inProgress" and `result` is `undefined` forever.
Hooks bypassed: this worktree has no node_modules, so the commitlint
commit-msg hook cannot resolve its binary. Subject follows the convention.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The useRenderTool page's Usage example compared `status` to the string
literal `"executing"`. `status` is typed as the `ToolCallStatus` enum
member union (`ReactToolCallRenderer["render"]` in react-core, which RN's
`RenderToolProps` derives from), so that comparison is TS2367 — the
snippet as printed does not compile.
Compare against `ToolCallStatus.Executing` and import the enum in the
snippet so the example is genuinely compilable.
Depends on `ToolCallStatus` being re-exported as a runtime VALUE from
packages/react-native/src/headless.ts (it currently sits inside an
`export type { … }` block, which strips the enum value). That export fix
is a separate change; both must land together for this snippet's import
to resolve.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The primary Usage example on the useRenderTool reference page never imported
CopilotChat, and the barrel specifier it implied resolves to the headless
component (packages/react-native/src/CopilotChat.tsx), which returns a bare
context provider around {children} and paints no message list. The page's
headline example therefore rendered nothing at all.
Import CopilotChat from @copilotkit/react-native/components -- the prebuilt UI
that calls useRenderToolCall and renders tool calls inline -- and state the
subpath requirement under the block so the distinction is not silent.
agentName is kept: it is the current, non-deprecated prop on the /components
chat (the deprecation and dev console.warn live on the headless component's
agentName), and it matches the prebuilt-UI usage on the CopilotChat page.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The deps guidance told readers that a render closure over changing values
is fixed by listing those values in deps. That remedy is inert for the
value types most likely to appear in a render closure.
react-core's useFrontendTool compares deps by serializing the whole array
(packages/react-core/src/v2/hooks/use-frontend-tool.tsx:45, via
JSON.stringify(extraDeps)), not by reference identity like useEffect. In
an array a function or symbol serializes to null, and a Map, a Set, or a
class instance holding state in private fields serializes to {} -- the
same string forever, so such a dep never re-registers the tool. A
circular dep additionally throws while the hook renders.
State the comparator's actual semantics, name the three consequences
(inert non-serializable deps, circular deps throwing, key order
counting), and document what does work: a primitive derived from the
changing value, or a ref the captured render dereferences at call time.
Docs-only. Core's comparator is deliberately unchanged -- it is shared by
every platform and is out of scope for this finding.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The documented signature dropped the hook's generic constraint and default
(`T extends Record<string, unknown> = Record<string, unknown>`) and rendered the
required `options` argument as optional.
The render-prop semantics were wrong in two ways verified against the types:
`args` is not "fully parsed" on the executing/complete arms — every arm receives
the same `partialJSONParse` of the raw argument string and the `parameters`
schema is never applied before `render`, so widening `Partial<T>` to `T` is a
type-level assertion only. And `result` is the tool result message's `content`
correlated by `toolCallId`, not the handler's return value: the complete arm is
selected because that message exists, handler returns arrive serialized
(`undefined`/`null` -> `""`, else `JSON.stringify`), a thrown handler yields the
string `Error: <message>`, a render-only tool completes with `""`, and on reload
the value replays from stored history.
Also document that the RN entry's re-exported `RenderToolInProgressProps` /
`RenderToolExecutingProps` / `RenderToolCompleteProps` are NOT arms of RN's
`RenderToolProps<T>`: they are schema-generic, `parameters`-shaped arms of
react-core's own union for the web hook. They sit next to `RenderToolProps` on
the public barrel, so the resemblance is a real trap worth naming.
Commit hook note: the commit-msg commitlint hook cannot run in this worktree
(no node_modules, `commitlint` binary unresolvable), so the message was
validated by hand against commitlint.config.js — conventional type+scope,
77-char header under the 120 limit, blank-line-separated body and footer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Final review fix wave for the RN render-tool convergence branch.
Substantive:
- Extend packages/react-core/scripts/assert-headless-purity.mjs to also scan the
built /v2/context chunk (context.mjs/context.cjs), not just /v2/headless.
/v2/context carries CopilotKitCoreReact and is imported by react-native, so a
future shiki/mermaid/katex leak through it would bloat RN bundles (#4893) while
neither hard-fail guard fired. Comment and failure message updated to name both
RN-reachable entries. Mutation-verified against context.mjs.
- Document the closure-staleness convergence: render is now captured at
registration (passed into useFrontendTool) and only refreshed when deps change,
no longer re-read every render. Consumers whose render closes over changing
state must now pass deps. Documented in the useRenderTool JSDoc, the
useRenderTool.mdx reference, and the changeset migration notes.
Minor sweep:
- CopilotChat extraData now lists what renderItem actually reads
({ isRunning, renderToolCall, toolMessages }); drop unused executingToolCallIds.
- headless-type-exports.test-d.ts imports React explicitly instead of relying on
the ambient UMD global.
- useRenderTool.mdx migration heading no longer names the uncut 1.67.0 version.
- Changeset marks @copilotkit/react-core minor (new public type export), matching
its body.
Co-Authored-By: Claude <noreply@anthropic.com>
useRenderTool.mdx and CopilotKitProvider.mdx described the removed React
Native render-tool registry as if it still existed. Correct the three
false statements on useRenderTool.mdx (cleanup unregisters the renderer;
RenderToolProvider auto-installed; useRenderToolRegistry live Map) and the
false CopilotKitProvider bullet (wraps children in a RenderToolProvider).
Document useRenderToolCall for rendering on any surface, note that
arguments stream on status "inProgress", and add a migration section for
the removed useRenderToolRegistry. Also fix the stale Callout that listed
useRenderToolCall as not exported on React Native.
Co-Authored-By: Claude <noreply@anthropic.com>
New export from Figma: two runner paths (managed Intelligence runner or
build your own), durable-data emphasis, Any Agent framework list, and
channel platforms with the +4 more row. Used for both themes until a
dark export exists.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Note in the Channels overview and package READMEs that building your own
channel runner on the open-source SDK primitives is a supported path with
no CopilotKit Intelligence dependency; teams choosing it own their state,
persistence, concurrency, locking, retries, and race-condition handling.
Intelligence remains the managed runner, with analytics, learning, and
governance in addition.
Also updates the production self-hosting note: Enterprise Intelligence can
be fully self-hosted today, onboarding guides are still to come.
Refs FAC-155
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
## What does this PR do?
Adds the CopilotKit consumer side of ENT-1173 across Shared, Runtime,
Core, Web Inspector, and the existing Shell Docs pages.
- Defines and parses optional trusted Inspector metadata for identity,
plan, license, action, usage, and expiry. Runtime proxies it through a
private, failure-isolated route, and Core refreshes it without changing
connection state.
- Groups Inspector navigation into Threads, Agents, and Learning.
Threads renders finite, unlimited, unknown, overage, and expiring usage
states plus matching trusted plan or license actions.
- Keeps explicit `threadEndpoints` as the only authority for Thread
requests. Locked or absent capability states make no list, subscription,
detail, message, event, or state calls.
- Keeps the zero-thread video, three example Threads, detail tabs, and
guided tour in empty and locked states. General Intelligence remains the
default onboarding path; only trusted `team_self_hosted` metadata uses
self-hosted onboarding.
- Gives an active license with missing Runtime routes a short **Finish
setting up Rich Threads** state. Users can copy a safe coding-agent
prompt or open the public Runtime setup guide. The same copy control
appears in that guide, and raw Markdown/LLM views include the full
prompt.
- Keeps finite usage green below 90%, orange from 90% to the limit, and
red at or above the limit. At 90%, a trusted plan action changes from
**Manage Your Plan** to a purple **Upgrade Your Plan** without changing
its trusted URL, action kind, or telemetry contract.
- Adds a deterministic 33-state loopback lab for CopilotKit developers.
It has no production route or export, is absent from public docs and
package metadata, and is excluded from the npm tarball.
`Expiring Soon` is display-only; this PR does not enable the thread
culler. Managed Enterprise receives no manage-plan action, and Team
Self-Hosted receives no hosted plan action. Optional metadata and the
additive expiry field remain compatible across mixed producer, Runtime,
Core, and Inspector versions.
A small Channels test-only change updates fetch mocks for current
TypeScript types. It changes no Slack or Teams docs or runtime behavior.
## Related PRs and issues
- Refs
[ENT-1173](https://linear.app/copilotkit/issue/ENT-1173/ship-plg-ready-inspector-navigation-metadata-and-locked-threads)
- Producer:
[CopilotKit/Intelligence#696](https://github.com/CopilotKit/Intelligence/pull/696)
## Validation
- `@copilotkit/web-inspector`: 20 files and 372 tests passed; typecheck
and production build passed.
- Shell Docs: 57 files and 383 tests passed; lint, typecheck, and
production build passed. The build generated all 222 static pages.
- Browser checks cover the copy-prompt flow, unchanged white **Manage
Your Plan**, purple **Upgrade Your Plan**, orange 4,500/5,000 usage, and
red 5,000/5,000 usage.
- Independent review found no Critical or Important issues.
- The broader Runtime, React Native, Channels, package-quality,
compatibility, and Node-version checks from the prior pushed head remain
green.
## Checklist
- [x] I have read the [Contribution
Guide](https://github.com/copilotkit/copilotkit/blob/master/CONTRIBUTING.md)
- [x] I updated the relevant documentation
- [ ] "Allow edits by maintainers" is checked
Fixes#261 (open since March 2024). Supersedes #4622 — @ashish4143
diagnosed the same wrappers and is credited as co-author on the commit.
## The bug
`CopilotSidebar` wraps consumer content in two divs:
- `.copilotKitSidebarContentWrapper` (`Sidebar.tsx`) — only sets
`overflow`, `margin-right`, `transition`
- `.copilotKitModalChildrenWrapper` (`Modal.tsx`) — **has no CSS rule
anywhere in the repo**
Both are auto-height blocks, so a child's `height: 100%` has no definite
containing block to resolve against and collapses to content height.
## The fix
An opt-in `fullHeightChildren` prop on `CopilotSidebar` that adds a
modifier class to the content wrapper. Two deliberate choices, both from
the review on #4622:
- **Opt-in, not default.** The content wrapper wraps the *entire*
consumer app. Making it a fixed-height flex column for everyone would
reflow apps that never asked for it.
- **A viewport unit, not `height: 100%`.** `100%` only resolves if every
ancestor (`html`/`body`/`#root`) also declares a height — react-ui
neither sets that nor can guarantee it, so `100%` would silently no-op
in a stock Next.js app. `min-height: 0` on the children wrapper clears
the flex-item `min-height: auto` floor so tall content scrolls inside
the child rather than stretching the wrapper past the viewport.
```tsx
<CopilotSidebar fullHeightChildren>
<div style={{ height: "100%" }}>...</div>
</CopilotSidebar>
```
## Testing
**Unit** — `packages/react-ui/src/css/sidebar-full-height.test.ts` (4
tests), in the repo's existing CSS-contract style. Guards both halves:
the escape hatch's rules, and that the default wrapper stays
auto-height. Also asserts the height is *not* `100%`, since that's the
regression that would make the whole feature a silent no-op.
```
✓ src/css/sidebar-full-height.test.ts (4 tests)
Test Files 9 passed (9) Tests 58 passed (58) # full react-ui suite
```
`npx tsc --noEmit` → exit 0. `oxlint` on changed files → 0 warnings, 0
errors.
**Live in Chrome** — the acceptance criterion from the #4622 review: a
stock app where **nothing** declares a height on `html`/`body`/`#root`,
loading the real built `dist/index.css` (not the source CSS), standards
mode, 762px viewport. DOM per `Sidebar.tsx:92` + `Modal.tsx:143`.
| case | child `height:100%` measures |
|---|---|
| default (no opt-in) | **17px** — collapsed, i.e. behavior unchanged
for existing consumers |
| `fullHeightChildren` | **762px** — exactly the viewport |
| `fullHeightChildren`, content 3000px tall | **762px**, scrolls inside
the child (`min-height: 0` holds) |
Also confirmed on the opt-in path: `.copilotKitSidebar` stays `position:
fixed`, and the expanded push-aside `margin-right` is still `448px`
(28rem), so the sidebar's own layout is untouched.
**Docs** — `CopilotSidebar.mdx` is auto-generated from `Sidebar.tsx`;
regenerated via `scripts/docs/gen.ts` and committed only the new
`fullHeightChildren` entry (the generator also surfaces unrelated
pre-existing drift in other reference pages, left out of this PR).
## Not covered
The issue mentions a "works in Safari, not Chrome" symptom. I verified
in Chromium only — the mechanism above is spec behavior rather than a
Chrome quirk, but I haven't measured WebKit.
Fixes#5961 (OSS-609).
## The bug
Both LangGraph auth pages told self-hosted readers to wrap their graph
in `CopilotKitRemoteEndpoint`. That path is retired and fails two ways
against the stack the reporter used (`copilotkit==0.1.94`,
`ag-ui-langgraph==0.0.4x`, Python 3.12):
```
import LangGraphAgent -> ImportError: cannot import name 'LangGraphAgent' from 'copilotkit'
execute_agent -> AgentExecutionException: Agent 'sample_agent' failed to execute:
'LangGraphAGUIAgent' object has no attribute 'execute'
```
(Reproduced locally against the `langgraph-fastapi` example's venv —
output above is verbatim.)
## The fix
`showcase/shell-docs/src/content/docs/auth.mdx` (Self-hosted tab of the
`auth_pattern: langgraph` section) and
`showcase/shell-docs/src/content/docs/integrations/langgraph/auth.mdx`
now document the supported pattern: **serve the AG-UI endpoint
yourself**, validate in a FastAPI dependency (401 before the graph
runs), and bake the resolved user into a **per-request**
`LangGraphAGUIAgent(config={"configurable": {"auth_user": user}})` so
nodes read an already-verified identity off `RunnableConfig` — no raw
token in the graph, no shared agent carrying another request's identity.
The gate-only variant (`FastAPI(dependencies=[Depends(current_user)])` +
`add_langgraph_fastapi_endpoint`) is documented for readers who only
want unauthenticated traffic rejected.
Two adjacent bugs on the same pages, fixed here because they break the
same walkthrough:
- **The frontend channel was wrong.** The pages said to pass
`properties={{ authorization: userToken }}` and claimed it "is forwarded
as a Bearer token". Nothing in `packages/` converts properties into
headers — `properties` reach the agent as AG-UI `forwardedProps` (run
payload data). The v2 runtime *does* forward the inbound `authorization`
header (and custom `x-*`) onto the agent call, so `headers={{
Authorization: ... }}` is the channel that actually works, for both
Platform and self-hosted.
- **The Platform user key was wrong.**
`config["configuration"]["langgraph_auth_user"]` →
`config["configurable"]["langgraph_auth_user"]` (matches
`langgraph/pregel/main.py` and `langgraph_api/worker.py`).
## Testing
**1. Doc snippets extracted verbatim from the MDX and executed** (a
script pulls the `main.py` + node code blocks out of each page, stubs
only `validate_your_token`, and drives them with `TestClient`; run under
the `examples/integrations/langgraph-fastapi` venv — `copilotkit
0.1.94`, `ag-ui-langgraph 0.0.41`, Python 3.12):
```
# docs/auth.mdx
PASS no header -> 401 {"detail":"Missing bearer token"}
PASS bad token -> 401 {"detail":"Invalid token"}
PASS valid token -> 200
PASS no RUN_ERROR
PASS node read user_123 off RunnableConfig
PASS node read role 'member'
PASS run completed
MESSAGES_SNAPSHOT: [{"id": "None", "role": "assistant", "content": "hello user_123"}]
ALL DOC-SNIPPET CHECKS PASSED
# docs/integrations/langgraph/auth.mdx — same script, same 7 checks
ALL DOC-SNIPPET CHECKS PASSED
```
**2. Gate-only variant**
(`FastAPI(dependencies=[Depends(current_user)])` + stock
`add_langgraph_fastapi_endpoint`):
```
no token -> 401 {"detail":"Missing bearer token"}
valid token -> 200 True True
PASS gate-only pattern (401 without token, run proceeds with token; identity NOT injected)
```
The trailing `True True` is `RUN_FINISHED` present **and** the node
seeing `nobody` — i.e. the gate works but no identity lands on the
config, exactly as the docs now say.
**3. Header forwarding actually reaches a LangGraph deployment** — the
claim behind the new `headers` guidance. Pointed a real
`@ag-ui/langgraph` `LangGraphAgent` at a local stub server, set
`agent.headers` the way `configureAgentForRequest` does, and recorded
what arrived:
```
[ { "url": "/assistants/search", "auth": "Bearer end-user-token", "apiKey": "server-side-key" } ]
PASS: authorization forwarded to the deployment
```
Both the end-user token and the server-side key arrive, which is why the
"server-configured headers win on collision" note is accurate.
Runtime-side breadth is already covered by
`packages/runtime/src/v2/runtime/__tests__/agent-utils-header-forwarding.test.ts`
("authorization header IS forwarded").
**4. Docs render checks** — both pages compile as MDX (`@mdx-js/mdx`
`compile()`), and every `python` block on both pages parses
(`ast.parse`), including the ones I didn't touch.
## Follow-up
**The DIY endpoint is deliberate but temporary.**
`add_langgraph_fastapi_endpoint` exposes no per-request seam (no
`dependencies` passthrough, no config/agent factory), and `endpoint.py`
is byte-identical in 0.0.41 and 0.0.42 — so owning the route is
currently the only way to get a verified identity onto
`config["configurable"]`. Adding that seam upstream in
`ag-ui-protocol/ag-ui` is tracked as **OSS-760**; when it lands, both
pages collapse back to the helper form and the DIY route stays only as
an escape hatch.
The broader "document request-scoped auth for
`add_langgraph_fastapi_endpoint`" ask in #3177 is now substantively
answered by these pages; leaving that issue open pending a maintainer's
call on whether it wants an SDK-level hook rather than the DIY endpoint.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Nine /integrations/<fw>/* links were rewritten to their canonical URLs.
Checking production, they were never broken — seo-redirects.ts 301s that
whole retired surface, so a reader always landed on the right page. That
made them cosmetic, and cosmetic changes do not belong in a PR whose
value is the defects around them.
Removing them takes this from 22 files to 15, all of which are things a
reader actually hits. The canonicalization is still worth doing; the
checker now reports it as its own advisory (legacy-redirect-links) so it
is tracked rather than lost.
Twenty-four defects a reader would hit, each verified against the tree
rather than pattern-matched. Found while root-causing PDX-313.
Links written as filesystem paths instead of served URLs (9). The docs
router serves integration pages at /<framework>/<slug>; the
/integrations/ prefix is the content directory, not a route. All nine
corrected URLs were confirmed to resolve.
Tutorial cross-links to directories with no index.mdx (4). loadDoc
resolves <slug>.mdx or <slug>/index.mdx, so /tutorials/ai-todo-app was a
404 — the page is at /overview.
Snippet components used with props but never imported (7). These fall
through to stubWithPartial in the global mdx-registry, which drops props
"on the floor" by design, so framework="pydantic-ai" never reached the
partial and the shared snippet rendered untailored. Importing the
partial restores prop flow. The mastra and ag2 siblings were already
correct; the seven broken ones are all in authored trees.
Dead YouTubeVideo imports (2). The component is provided globally by
mdx-registry.tsx and four other pages render it with no import at all;
these two imported a module that has never existed in the repo.
Stale byoc-* demo ids (2). Renamed to declarative-* in 70e2fb13c8
(2026-05-10, "rename byoc-* slugs to declarative-*"); the docs were
never updated. Only the three registry ID references per page change
here — snippet_cell, InlineDemo, IntegrationGrid.
Left alone deliberately: the runtimeUrl/agent code samples on the
hashbrown and json-render pages. The API routes were renamed to
copilotkit-declarative-*, but the agent ids were not renamed
consistently — declarative-hashbrown's demo uses
agent="declarative-hashbrown-demo" while declarative-json-render's still
exports AGENT_ID = "byoc_json_render". Guessing would ship a broken
copy-paste sample, so that needs an owner.
Mechanical repairs found while auditing the pydantic-ai docs. Each was
verified against the tree; nothing here is a content rewrite.
- Delete `quickstart/pydantic-ai.mdx` + its `meta.json`. `seo-redirects.ts`
already routes `/pydantic-ai/quickstart/pydantic-ai` ->
`/pydantic-ai/quickstart` (rule F6), and adk got the same treatment (F7).
pydantic-ai was the only framework still carrying a `quickstart/`
subdirectory alongside the canonical `quickstart.mdx`.
- `human-in-the-loop/agent.mdx`: link to the canonical quickstart directly
instead of the redirected legacy path, and point the starter link at
`examples/integrations/pydantic-ai` — `examples/coagents-starter-pydantic-ai`
does not exist.
- `docs-links.json`: `subagents.shell_docs_path` was `/multi-agent/subagents`,
which has no page. The real page is `/multi-agent-flows`, which the
entry's own `og_docs_url` already pointed at.
- `headless-simple/chat.tsx`: the console tag said `langgraph-python` inside
the pydantic-ai package. This sits in an `@region` block, so it is pulled
into docs as a snippet. 11 other integrations carry the same copy-paste;
they are left for the fleet sweep.
- `examples/showcases/pydantic-ai-todos/README.md`: `uv run src/main.py` ->
`uv run main.py` (there is no `src/main.py` in that tree), and the stated
Python floor now matches `agent/pyproject.toml` (`>=3.13`).
- `examples/canvas/pydantic-ai/README.md`: Python 3.8+ was unrunnable —
`agent/agent.py` uses PEP 604 unions. Aligned to the sibling tree that
pins the same `pydantic-ai-slim==2.22.0`.
Children of `CopilotSidebar` cannot use `height: 100%`. Both wrappers the
sidebar puts around your app -- `.copilotKitSidebarContentWrapper` and
`.copilotKitModalChildrenWrapper` (which had no CSS rule at all) -- are
auto-height blocks, so a percentage height on a child has no definite
containing block and collapses to content height.
Add an opt-in `fullHeightChildren` prop that gives the content wrapper a
one-viewport height and lets the children wrapper fill it. It is opt-in
because the content wrapper wraps the entire consumer app, and giving
every react-ui sidebar user a flex column with a fixed height would
reflow apps that never asked for it.
The height is a viewport unit, not `100%`: `100%` only resolves when
every ancestor (html/body/#root) also declares a height, which react-ui
neither sets nor can guarantee, so it would silently no-op in a stock
Next.js app. `min-height: 0` on the children wrapper clears the flex-item
`min-height: auto` floor so tall content scrolls inside the child instead
of stretching the wrapper past the viewport.
Fixes#261
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Ashish Shaw <77574570+ashish4143@users.noreply.github.com>
## Summary
`mcpApps.servers` entries that carry `includeTools` or `excludeTools`
are currently accepted even though the pinned
`@ag-ui/mcp-apps-middleware` package has no option for them. The runtime
then ignores the keys, so tools an operator intended to restrict remain
available. This change rejects that configuration instead of allowing a
silent no-op.
## What CopilotKit owns
- `mcpApps.servers` configuration and `agentId` scoping.
- Projection of selected servers into `MCPAppsMiddleware`.
- Reporting unsupported configuration before middleware construction.
Discovery, model-emitted tool execution, frontend-proxied execution,
server identity, and tool provenance belong to
`@ag-ui/mcp-apps-middleware`.
## Changes
- Extract the server projection into `resolveMcpAppsServers`, which
scans all configured entries for defined policy keys, filters by
`agentId`, strips only `agentId`, and forwards other fields unchanged.
- Return a configuration error naming the unsupported key, server,
pinned middleware version, owning package, and issue when a policy key
is supplied.
- Add tests for agent scoping, field forwarding, malformed and empty
values, undefined spread values, constructor avoidance, and the existing
HTTP error path.
- Document the ownership boundary and add a runtime changeset.
## Why the filter stays external
The pinned package is version `0.0.3`. It owns the private server maps,
UI-tool discovery, model-emitted execution, and frontend proxy
execution. A CopilotKit middleware could observe only one of those paths
and would have to duplicate private server identity and tool provenance.
The complete `includeTools` and `excludeTools` implementation belongs in
the external package, where one predicate can cover discovery and both
execution paths.
## Current behavior
Plain JavaScript or JSON configuration can supply `excludeTools:
["delete_account"]` without a TypeScript excess-property check. The
runtime currently accepts the configuration, constructs
`MCPAppsMiddleware`, and leaves the tool available. The new behavior
returns an HTTP 500 through the existing runtime error path, names the
unsupported key and dependency, and does not construct the middleware.
## Follow-up
The counterpart change in `@ag-ui/mcp-apps-middleware` should add the
fields to the per-server configuration, preserve absent versus empty
include lists, resolve server identity through its existing maps, and
apply one predicate after UI-resource discovery and before model-emitted
and proxied tool execution. Once that version is released, CopilotKit
can remove the rejection and pass the fields through unchanged.
## Related issue
Refs #5930.
The cross-repository ownership split follows the proposal in
https://github.com/CopilotKit/CopilotKit/issues/5930#issuecomment-5128722524.
This PR does not close the issue.
## Test plan
- [x] `pnpm -C packages/runtime exec vitest run
src/v2/runtime/__tests__/mcp-apps-servers.test.ts
src/v2/runtime/__tests__/mcp-apps-middleware-integration.test.ts`
passed, 2 files and 20 tests
- [x] `pnpm -C packages/runtime exec vitest run` passed, 129 files and
1,836 tests
- [x] `pnpm exec nx run @copilotkit/runtime:check-types` passed
- [x] `pnpm exec oxlint` and `pnpm exec oxfmt --check` passed on changed
TypeScript files
- [x] `pnpm check:plugin-skills` passed
- [ ] `CI green for static / quality and test / unit on Node 20, 22, and
24`
Ran Shemtov