## Release angular v0.5.1
**Scope:** `angular` | **Bump:** `patch`
---
### How this release process works
1. **This PR was created automatically** by the "release / create-pr"
workflow.
It bumped the `angular` packages to `0.5.1`
and generated AI-enhanced release notes.
2. **CI runs on this PR** — the full test suite (unit tests, lint, type
checks, build)
must pass before merging. This is the review gate.
3. **Review the release notes** in `release-notes.md` in this PR.
If a Notion draft was created, you can edit the release notes there
before merging.
4. **When this PR is merged**, the `release / publish` workflow
automatically:
- Builds all packages
- Publishes the `angular` packages to npm at version `0.5.1`
- Creates git tag `angular/v0.5.1`
- Creates a GitHub Release with the final release notes
### Before merging
- [ ] CI is green (tests, lint, types, build)
- [ ] Version bumps look correct
- [ ] Release notes are accurate (edit in Notion if a draft was created)
---
> **Do not merge until CI is fully green.** The full test suite runs
automatically on this PR.
The Intelligence overview is now a landing page. Open
`/intelligence/overview` to see a sizzle video, copy the onboarding
prompt, and jump into threads, analytics, learning, self-hosting, or the
Intelligence quickstart.
## What does this PR do?
Replace the text-only CopilotKit Intelligence overview with a landing
page:
1. Full-width hero, video, and copy-onboarding prompt
2. "What the platform adds" table, including analytics and automatic
learning
3. Feature cards for Rich Threads, Analytics, Automatic Learning, and
Self-hosting
4. A quickstart link to `/intelligence/quickstart` (page ships in a
sibling PR)
`/premium/overview` already redirects here.
## Related PRs and Issues
- Linear:
https://linear.app/copilotkit/issue/OSS-1075/add-a-new-landing-page-for-intelligence
- Sibling: Intelligence quickstart (`OSS-1076`)
## Checklist
- [ ] 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)
## Testing
1. **Commands run.** `npx vitest run` on
`intelligence-overview.test.tsx`, `hero-start-commands.test.tsx`, and
`intelligence-landing.test.ts` in `showcase/shell-docs`. All passed. I
did not run `pnpm test:pr`.
2. **Manual test.**
1. From `showcase/shell-docs`, run `npx next dev --port 3004 --hostname
127.0.0.1`
2. Open http://127.0.0.1:3004/intelligence/overview
3. Confirm the hero, video, copy prompt, Connect an app, feature cards,
and quickstart link
4. `/intelligence/quickstart` 404s until the sibling PR merges
3. **How this PR makes testing easy.** Unit tests pin the hero, CTAs,
video, table rows, and section order.
## Risk / rollback
Low. Docs-only. Revert the PR to restore the old overview.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added an Intelligence overview landing page with a demo video,
onboarding prompt, quickstart link, and feature cards for key platform
capabilities.
- Added support for custom text on quickstart links.
- Added reduced-motion support for the landing-page video.
- Added an option to hide documentation page headers when configured.
- **Documentation**
- Expanded Intelligence documentation with platform capabilities,
feature cards, and quickstart guidance.
- Added guidance for keeping Intelligence documentation and landing-page
content synchronized.
- **Tests**
- Added coverage for Intelligence page content, navigation, video
configuration, documentation rendering, and custom quickstart labels.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Two legacy docs URLs have been dead ends for six months. Neither has
anything to do with the recent `premium/` → `intelligence/` rename —
they are older, and the rename only moved where they fail.
## `/premium/inspector` — 404
`cc8c945893` ("refactor(docs): optimize structure, content and
navigability", 2026-02-23) renamed `(root)/premium/inspector.mdx` to
`(root)/inspector.mdx` as an `R100` rename — identical content. The page
still exists and `/inspector` serves it. Only the old URL was left
behind, and it has 404'd ever since. It shows up in
`analytics_postgres_contacts.hs_analytics_source_data_1` as a HubSpot
first-touch page, so it had real traffic.
## `/direct-to-llm/guides/premium/*` — wrong page, 200
All four pages under that path (overview, headless-ui, observability,
inspector) were deleted in the same commit. The `R16`
`/direct-to-llm/:path*` wildcard strips the prefix and the remainder
falls through to the docs home, so the reader gets a 200 and the wrong
page. That is why it went unnoticed longer than a 404 would have —
nothing looks broken. `/direct-to-llm/guides/premium/headless-ui` is
also in the HubSpot first-touch data.
`cc8c945893` had no redirect config to update: `seo-redirects.ts` did
not exist yet. The gap is that nobody back-filled these when it was
built.
## What this adds
33 exact entries:
- `INTEL-inspector-root`: `/premium/inspector` → `/inspector`
- `INTEL-inspector×<fw>`: `/<fw>/premium/inspector` →
`/<canonical-fw>/inspector`, expanded over `PREMIUM_URL_FRAMEWORKS`
exactly as the observability entries are
- `INTEL-d2l-guides-*`: the four `/direct-to-llm/guides/premium/*`
pages, each to its current equivalent (the retired observability page
goes to the overview, matching `INTEL-observability-*`)
Both hosts get them, plus the harness copy. `P7` renames `/premium/*` to
a docs-host `/intelligence/*` on the way across, so without the shell
entry the legacy shell URL would 301 into a docs-host 404 — the same
reasoning the `INTEL-observability-root` comment already spells out. The
harness driver is the declared intentional copy of the shell list and
moves with it.
## Why exact entries
Middleware builds `exactMap` from every source without `:path*` and
checks it before the wildcard list. `INTEL-rename-wild` would otherwise
rewrite `/premium/inspector` to a nonexistent `/intelligence/inspector`.
Same mechanism that makes the observability entries work today.
## Verification
- All 24 distinct destinations probed against staging: 22 return 200.
`/langroid/inspector` and `/spring-ai/inspector` 404 — those two
framework surfaces are not served at all, their bare roots and
quickstarts 404 too, and the existing observability entries carry the
same property. No reachable URL changes behavior.
- Catalogue check over all 463 exact sources: no duplicate source, no
self-loop, no wildcard among the new entries.
- `showcase-harness`: 177 test files, 3728 tests pass.
`showcase-scripts`: 78 files, 2543 tests pass. shell-docs lint and
typecheck clean; its redirect suite goes from 10 to 13 tests.
- Decommission fixtures regenerated through the CLI with
`--events-json`, not through the core module, so the byte-for-byte
cross-check between CLI and core keeps its meaning. The diff is 390 →
395 defined, 377 → 382 zero-hit, plus the five new ids.
## Not verifiable in production yet
`docs.copilotkit.ai` has not been promoted since #6818 merged, so
production has no `/intelligence/*` tree and serves `/premium/*`
directly. Everything above was measured on staging, where the rename and
its redirects are live. Reviewing these URLs against production will
show the old behavior until `shell-docs` is promoted.
## Left alone
- `/integrations/direct-to-llm/guides/premium/headless-ui` also 404s,
but there is no `/integrations/direct-to-llm/:path*` rule at all, so
that is a wider gap about the `/integrations/*` prefix rather than this
one.
- `docs/superpowers/plans/2026-08-03-ent-1173-…md` still names the old
content path. It is a record of a finished plan and describes what was
true then.
## Summary
- Add a focused one-click prompt CTA at the top of the WebMCP guide.
- Hide the generic onboarding prompt action on the WebMCP page only.
## Why
The WebMCP launch CTA needs a short, standalone prompt that sends
developers directly to the WebMCP guide without funneling them through
the broader CopilotKit onboarding flow.
## How
- Add a Setup with a coding agent section modeled on the compact prompt
row used in the supplied reference.
- Copy the approved WebMCP setup prompt verbatim and expose clear copied
and error states.
- Keep the existing Copy Markdown and Open actions while suppressing
Copy agent prompt for every WebMCP route.
- Verify shell-docs lint, typecheck, prompt interaction, desktop and
mobile rendering, and the Impeccable design scan.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a copyable WebMCP setup prompt with success and error feedback.
* Added a dedicated “Setup with a coding agent” section to the WebMCP
documentation.
* **Documentation**
* Reorganized the WebMCP page with an Overview section and clearer setup
guidance.
* The onboarding prompt is now hidden on the WebMCP documentation page
while remaining available elsewhere.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
- give locked Threads and Learning a shared conversion-focused layout
- add streamlined Loom demos, setup and engineer CTAs, and detailed
capability sections
- remove the disabled Threads preview so both locked experiences use the
same full-page treatment
## Why
Users without Intelligence enabled should immediately understand what
each feature provides and have clear paths to configure it or talk with
the team.
## How
- render both gates through one responsive locked-feature surface
- use minimal Loom embeds with feature-specific videos
- align content on a single centered rail with theme-aware styling
- add product-specific copy, capability icons, accessibility labels,
telemetry coverage, and fixture assertions
- verify with `pnpm nx run @copilotkit/web-inspector:test` and `pnpm nx
run @copilotkit/web-inspector:check-types`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added unified locked views for Threads and Learning with feature
videos, capability outlines, setup guidance, and a “Talk to an Engineer”
call to action.
* Added responsive and dark-theme styling for locked-feature overviews.
* Updated self-hosted and setup messaging.
* **Bug Fixes**
* Prevented unavailable Threads content, examples, controls, and
metadata actions from appearing.
* Removed legacy runtime entitlement diagnostics from the interface.
* Standardized locked-state telemetry and CTA behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
- Add one framework-agnostic WebMCP guide at `/webmcp`.
- Make the page available through every visible frontend and
agent-framework route.
- Add WebMCP to the shared docs navigation.
## Why
Developers need an accurate launch reference that explains WebMCP
without assuming they already understand CopilotKit frontend tools.
WebMCP is page-level rather than agent-specific, so one universal guide
should follow the selected frontend and backend instead of maintaining
duplicated variants.
## How
- Document existing-tool and agentless setup paths, lifecycle behavior,
annotations, security boundaries, experimental browser requirements, and
React Native limitations.
- Mark the guide `frontend: universal`; the existing docs router then
serves the same source at the bare, frontend-scoped, backend-scoped, and
combined URLs.
- Verified lint, typecheck, build, visual rendering, and all 152 route
combinations across 7 frontends and 18 visible agent frameworks.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Added documentation for WebMCP support in CopilotKit, including setup
examples for React and core-only usage.
- Documented how frontend tools are exposed to browser agents through
`document.modelContext`.
- Added guidance on deciding when to use an agent, designing reliable
tools, testing, and understanding experimental limitations.
- Added the WebMCP page to the documentation navigation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Ports
[CopilotKit/website#556](https://github.com/CopilotKit/website/pull/556)
to the docs site.
## Summary
Adds `enableThirdPartyTracking: true` to the existing `Reo.init()` call
in the shell-docs root layout. This activates Reo's enhanced visitor
identification, which uses their data partner network to identify more
anonymous visitors.
The Reo dashboard toggle was already enabled on Sep 3. The marketing
site half shipped in website#556. This is the docs-site half.
## GTM impact
**Modifies:** the Reo.dev visitor-identification script
(`reo-init-script` in `showcase/shell-docs/src/app/layout.tsx`).
- No events renamed or removed
- No other tracking script (PostHog, RB2B, Scarf, HubSpot) is affected
- Adds one configuration property to the existing `Reo.init({})` call
- Reo docs:
https://docs.reo.dev/integrations/input-sources/website-visitor-insights/website-visitor-identification/enhanced-website-visitor-identification
## Changes
```diff
- window.Reo.init({ clientID: e });
+ window.Reo.init({ clientID: e, enableThirdPartyTracking: true });
```
The script block is gated on `REO_KEY`, so environments without the key
are unaffected.
## Testing
- `Reo.init` appears exactly once in the repo, so there is no second
call site to update:
```
$ grep -rn "Reo.init" showcase/shell-docs/src/
showcase/shell-docs/src/app/layout.tsx:140: window.Reo.init({ clientID:
e, enableThirdPartyTracking: true });
```
- `oxfmt --check` on the changed file:
```
All matched files use the correct format.
Finished in 20ms on 1 files using 18 threads.
```
- `oxlint` on the changed file:
```
Found 0 warnings and 0 errors.
Finished in 204ms on 1 file using 18 threads.
```
- No test asserts the `Reo.init` argument string, so no test needed
updating.
- Visual artifacts: N/A. This is a one-property config change to an
inline analytics script, with no visual or layout impact.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Enabled third-party tracking for Reo analytics integration.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
`new CopilotKitIntelligence({ apiKey })` performed no validation. The
constructor assigned the value (`client.ts:683`) and every authenticated
call sent it verbatim as a Bearer credential (`:822`, `:934`, `:1006`,
`:1401`). An empty string produced `Authorization: Bearer ` and failed
later as a 401 with nothing pointing back at the missing environment
variable.
`apiKey: string` is required on the config type, so TypeScript catches a
*missing* property. It does not catch an empty one, and it does not
catch the shape that actually happens — a `process.env` read TypeScript
is told to trust:
- `process.env.CPK_INTELLIGENCE_API_KEY!` — what this file's own JSDoc
examples use (`client.ts:619`, `:640`)
- `process.env.CPK_INTELLIGENCE_API_KEY ?? ""` — what the canonical
starter wiring block uses
When the variable is unset, both are blank at runtime and typed as
`string`. Construction succeeds, and the failure appears later, in a
different place, wearing a different name.
## Change
Throw from the constructor when `apiKey` is absent, empty, or
whitespace-only. A runtime with no credential cannot serve managed
Intelligence, and every caller constructs the client during boot, so the
error lands at startup rather than on a user's first message.
The message names `CPK_INTELLIGENCE_API_KEY` and tells the reader that
`copilotkit project select` provisions a key. It echoes **none** of the
key value — the same rule `parseProjectIdFromApiKey` follows for a
malformed key, since the whole `cpk-…` string is a secret.
This mirrors `configuredUrl`, which already treats a blank
`apiUrl`/`wsUrl` as unset for exactly the same `?? ""` reason.
## Acceptance criteria
- [x] Constructing with an absent, empty, or whitespace-only `apiKey`
throws
- [x] The message names `CPK_INTELLIGENCE_API_KEY` and the command that
provisions it
- [x] The error does not include the key value, blank or not
- [x] A test covers each of the three rejected inputs and one accepted
one
- [x] No existing test constructs the client with a blank key and
expects it to succeed
On the last point: the two `apiKey: ""` hits in the repo are a string
literal fed to a static source-contract checker
(`integration-intelligence-migration.test.ts:2837`) and unrelated
LangGraph agent state (`scene-creator`). Neither constructs a real
client.
## Blast radius
Every production construction site is already safe — the starter block
and the AgentCore/Angular runtimes gate on the key or the license token,
and the Slack/Teams examples call a `requiredIntelligenceKey()` helper.
That helper is itself evidence for this change: developers keep
hand-rolling the check the platform should perform.
No documentation teaches a blank-tolerant Intelligence key. The seven
`apiKey: … ?? ""` hits in docs are all `OPENAI_API_KEY` or a generic
name.
## Verification
- `vitest run …/client.test.ts -t "apiKey validation"` — RED `5 failed |
1 passed` before the fix, every failure the constructor not throwing;
GREEN `6 passed` after
- `nx test @copilotkit/runtime` — 152 files, **2262 passed**, exit 0
- `nx check-types @copilotkit/runtime` — clean
- `vitest run` over the three `scripts/__tests__` suites that touch this
client — **171 passed**
- `oxfmt --check`, `oxlint`, `pnpm check:intelligence-env-names` — clean
- All five lefthook gates green on commit (`test`, `publint`, `attw`
across 7 projects)
## Follow-up, deliberately not in this PR
The canonical starter wiring block still reads `apiKey:
process.env.CPK_INTELLIGENCE_API_KEY ?? ""`, which now reads as if blank
were acceptable. Changing it touches 21 byte-identical starters plus
`validate-intelligence-wiring-block`, so it belongs in its own change.
Related: OSS-1091 settled `CPK_INTELLIGENCE_API_KEY` as the canonical
name. This is the second half — the naming fix removed the common way to
end up with an empty key, not the reason an empty key is expensive.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Added early validation for the Intelligence API key during startup.
* Blank, missing, or whitespace-only keys now produce a clear error with
setup guidance instead of causing a later authorization failure.
* Error messages do not expose the rejected key value.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
`CopilotKitIntelligence` performed no validation on `apiKey`. It assigned the
value and sent it verbatim as a Bearer credential, so a blank key produced
`Authorization: Bearer ` and surfaced much later as a 401 that named nothing.
`apiKey: string` is required on the config type, so TypeScript catches a missing
property. It does not catch an empty one, and the shape that actually happens is
a `process.env` read TypeScript is told to trust: `?? ""` in the starter wiring
block, `!` in this file's own JSDoc examples. Both yield a blank key when the
variable is unset.
Throw at construction instead. Every caller builds the client during boot, so the
error lands at startup rather than on a user's first message. The message names
`CPK_INTELLIGENCE_API_KEY` and `copilotkit project select`, and echoes none of the
key value — the rule `parseProjectIdFromApiKey` already follows for a malformed
key.
This mirrors `configuredUrl`, which already treats a blank `apiUrl`/`wsUrl` as
unset for the same `?? ""` reason.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Release monorepo v1.70.1
**Scope:** `monorepo` | **Bump:** `patch`
---
### How this release process works
1. **This PR was created automatically** by the "release / create-pr"
workflow.
It bumped the `monorepo` packages to `1.70.1`
and generated AI-enhanced release notes.
2. **CI runs on this PR** — the full test suite (unit tests, lint, type
checks, build)
must pass before merging. This is the review gate.
3. **Review the release notes** in `release-notes.md` in this PR.
If a Notion draft was created, you can edit the release notes there
before merging.
4. **When this PR is merged**, the `release / publish` workflow
automatically:
- Builds all packages
- Publishes the `monorepo` packages to npm at version `1.70.1`
- Creates git tag `monorepo/v1.70.1`
- Creates a GitHub Release with the final release notes
### Before merging
- [ ] CI is green (tests, lint, types, build)
- [ ] Version bumps look correct
- [ ] Release notes are accurate (edit in Notion if a draft was created)
---
> **Do not merge until CI is fully green.** The full test suite runs
automatically on this PR.
## Release channels v0.9.2
**Scope:** `channels` | **Bump:** `patch`
---
### How this release process works
1. **This PR was created automatically** by the "release / create-pr"
workflow.
It bumped the `channels` packages to `0.9.2`
and generated AI-enhanced release notes.
2. **CI runs on this PR** — the full test suite (unit tests, lint, type
checks, build)
must pass before merging. This is the review gate.
3. **Review the release notes** in `release-notes.md` in this PR.
If a Notion draft was created, you can edit the release notes there
before merging.
4. **When this PR is merged**, the `release / publish` workflow
automatically:
- Builds all packages
- Publishes the `channels` packages to npm at version `0.9.2`
- Creates git tag `channels/v0.9.2`
- Creates a GitHub Release with the final release notes
### Before merging
- [ ] CI is green (tests, lint, types, build)
- [ ] Version bumps look correct
- [ ] Release notes are accurate (edit in Notion if a draft was created)
---
> **Do not merge until CI is fully green.** The full test suite runs
automatically on this PR.
Adds enableThirdPartyTracking to the Reo.init call in shell-docs so the
docs site matches the marketing site (CopilotKit/website#556). The Reo
dashboard toggle was already enabled on 2026-09-03; this completes the
activation.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
## What does this PR do?
Hooks can now expose a frontend tool to browser agents through the
WebMCP browser API, next to the normal agent registration. Set `webmcp:
true`, or pass `{ annotations }` for WebMCP hints:
```ts
useFrontendTool({
name: "searchOrders",
description: "Search the signed-in user's orders by status",
parameters: z.object({ status: z.enum(["open", "shipped", "delivered"]) }),
handler: async ({ status }) => searchOrders(status),
webmcp: { annotations: { readOnlyHint: true } },
});
```
How it works:
1. `FrontendTool` in `@copilotkit/core` gains the `webmcp` option. A new
`WebMCPRegistry` registers the tool on `document.modelContext` with its
name, description, input schema, and annotations. `execute` runs the
tool's own handler. The handler context has no `agent` there.
2. Every tool registry change in `RunHandler` reconciles the WebMCP
registrations. The same availability rules apply as for the agent tool
list. Removing a tool aborts its registration signal, and the browser
then unregisters it.
3. Each adapter picks the option up from core: v2 `useFrontendTool`
(React, Vue, React Native), the v1 `useCopilotAction` and
`useFrontendTool` wrappers (React, Vue), and Angular's
`registerFrontendTool`. Where WebMCP is not available (SSR, React
Native, browsers without the API), registration is a no-op.
The `webmcp` prop is documented on the React, Vue, and Angular reference
pages in shell-docs.
## Related PRs and Issues
- None.
## 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
- [ ] "Allow edits by maintainers" is checked (lets us help iterate on
your PR directly — faster turnaround for everyone)
## Testing
**Commands run**
- `pnpm nx run-many -t check-types
--projects=@copilotkit/core,@copilotkit/react-core,@copilotkit/vue,@copilotkit/angular`
— all pass.
- Full test suites: core (829 tests), vue (103), and angular pass.
react-core passes standalone (1589 tests). Under the lefthook pre-commit
hook, react-core flakes on pre-existing e2e tests (A2UI, MCP Apps) that
do not touch this code. Those tests pass when run alone.
**Manual test**
Requires Chrome 149+ with the WebMCP origin trial, or the testing flag.
1. Enable `chrome://flags/#enable-webmcp-testing`, then relaunch Chrome.
2. In an app that uses CopilotKit, register a tool with `webmcp: true`.
3. Run `await document.modelContext.getTools()` in DevTools. The tool is
listed with its schema and annotations.
4. Unmount the hook. Run the command again. The tool is gone.
**How this PR makes testing easy**
The behavior has automated tests on this branch:
- `packages/core/src/core/__tests__/run-handler-webmcp.test.ts` — 15
tests with a `document.modelContext` stub: registration, annotations,
unregistration, availability rules, name collisions, stale-rejection
races, and handler execution.
-
`packages/react-core/src/v2/hooks/__tests__/use-frontend-tool-webmcp.test.tsx`
and the mirrored
`packages/vue/src/v2/hooks/__tests__/use-frontend-tool-webmcp.test.ts` —
pass-through, re-registration, and agent-scoped cases at the hook level.
- `packages/vue/src/hooks/__tests__/use-frontend-tool-webmcp.test.ts` —
reactive `webmcp` getters through the v1 Vue API.
## Risk / rollback
Low. The feature is opt-in per tool. Without `webmcp`, no code path
changes. Where WebMCP is unsupported, registration is a no-op. Revert
this PR to roll back.
## Public API change
New optional `webmcp` prop on frontend tool registrations. Existing call
sites do not change.
**Before**
```ts
useFrontendTool({
name: "searchOrders",
description: "Search orders by status",
parameters: z.object({ status: z.string() }),
handler: async ({ status }) => searchOrders(status),
});
```
**After**
```ts
useFrontendTool({
name: "searchOrders",
description: "Search orders by status",
parameters: z.object({ status: z.string() }),
handler: async ({ status }) => searchOrders(status),
webmcp: { annotations: { readOnlyHint: true } },
});
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Tools can now be exposed to browser agents through WebMCP.
* Added support for custom annotations and automatic parameter schema
generation.
* WebMCP registrations stay synchronized as tools are added, removed,
enabled, or updated.
* Available across Angular, React, and Vue tool APIs.
* WebMCP reuses existing handlers and safely does nothing when
unavailable.
* **Documentation**
* Added usage guidance and examples for configuring WebMCP-enabled
tools.
* Documented that WebMCP invocations do not include an agent context.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Adds a five-minute quickstart for connecting an existing CopilotKit app
to Intelligence. Developers can use a coding-agent prompt or follow
framework-specific manual steps. The guide ends with a saved-thread
check in Inspector.
Linear:
[OSS-1076](https://linear.app/copilotkit/issue/OSS-1076/add-a-quickstart-for-intelligence)
## What changed
- Added the Intelligence quickstart to the docs navigation and overview.
- Added setup examples for React, Vue, Angular, and React Native.
- Added Inspector checks for browser apps and a hosted-project check for
React Native.
- Updated the coding-agent prompt with route, identity, and
authorization requirements.
- Updated Next.js and TanStack Start adapters to forward thread mutation
methods.
## Testing
Commands run:
- `npm exec -- vitest run
src/lib/__tests__/intelligence-quickstart-docs.test.ts
src/lib/__tests__/docs-render.test.ts
src/lib/__tests__/rich-threads-setup-docs.test.ts
src/components/__tests__/rich-threads-setup-prompt.test.tsx`: 39 tests
passed.
- `npm run typecheck`: passed.
- `npm run lint`: passed with existing warnings in unrelated files.
- `npm run build`: passed.
- The pre-commit package, binary, environment-name, lint, and commit
checks passed.
The full shell-docs test run still has unrelated Windows failures in
asset, generated Angular content, and LLM text tests.
Manual test:
1. Start shell-docs and open `/intelligence/quickstart`.
2. Select React, Vue, Angular, and React Native in the frontend
selector.
3. Check that each frontend shows its matching provider example.
4. Check that browser frontends use Inspector to find the new thread.
5. Check that React Native uses the hosted Intelligence project instead.
The new contract test checks the route, navigation, framework examples,
agent prompt, and Inspector completion path.
## Risk / rollback
Risk is low because this PR changes documentation and examples only.
Revert the commit to remove the quickstart and restore the prior adapter
examples.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added an Intelligence quickstart guide covering project setup,
authentication, thread authorization, runtime integration, frontend
configuration, and connection verification.
- Added the quickstart to Intelligence documentation navigation and
linked to it from the overview page.
- Expanded setup guidance with browser and React Native steps for
creating threads and sending messages.
- **Documentation**
- Updated Next.js and TanStack Start examples to forward all Runtime
methods, including `PATCH` and `DELETE`.
- Clarified authentication and thread ownership requirements for Runtime
routes and operations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The onboarding prompt copied from the docs already names the agent
framework the page is scoped to. The docs have a second selector in the
top left, though, and the CLI's prompt graph has a matching set of
frontend nodes — so it was still asking a question the page could
already answer.
The prompt now names the frontend too:
> … Follow the Markdown instructions it prints until onboarding is
complete. The developer selected the Mastra agent framework (`mastra`).
**The developer selected the React frontend (`nextjs`).** The developer
copied this prompt from
https://docs.copilotkit.ai/mastra/generative-ui.mdx.
Closes OSS-1071.
## How the mapping was established
`react → nextjs` is not inferred by elimination. Each frontend prompt
the graph ships names the docs page it belongs to, and `nextjs.md` is
the only one pointing at the unprefixed root quickstart — which is
exactly what the docs' default `react` frontend serves. It also states
"Record Next.js as the selected frontend" in its own body. Every other
frontend points at its own prefixed page and maps one to one:
| docs | graph |
| --- | --- |
| react | `nextjs` |
| react-spa | `react-spa` |
| vue | `vue` |
| angular | `angular` |
| react-native | `react-native` |
| slack, teams | *nothing* |
Slack and Teams are chat channels, not application frontends; the graph
has no node for either, so the sentence is omitted rather than naming a
path the CLI cannot walk — the same rule the framework sentence follows
for `langroid` and `spring-ai`.
A guard test walks the docs frontend registry and fails when a frontend
is neither mapped nor listed as deliberately unmapped, so adding one
forces a decision instead of silently dropping the sentence. The
framework-side equivalent of that guard originally read the raw registry
JSON and was blind to docs-only entries; this one reads the same source
the app itself uses.
## Shape and wording
The sentence sits between the framework sentence and the page sentence,
matching the order the graph works in — it settles the agent framework
first, then the frontend. All four combinations of present/absent
neighbours are asserted as whole strings, so a stray separator fails a
test.
It pairs the docs display name with the graph slug, exactly as the
framework sentence does. For `react`/`nextjs` those two are further
apart than elsewhere and read a little oddly to someone who knows the
docs list "React" and "React SPA" separately. Kept deliberately: the
sentence reports what the developer selected, and that option is
labelled React. The graph keys on the backtick slug.
The frontend is resolved from the URL, never from a stored preference —
choosing another frontend navigates, so the URL is what asserts the
selection. It is resolved server-side and passed down like
`onboardingFramework`; nothing reads `usePathname()` in the client
component for this.
## Telemetry
`docs.intelligence_onboarding_prompt_copied` gains a `frontend` property
carrying the graph slug, omitted entirely when there is no equivalent —
same treatment as `agent_framework`. The name matches the field on the
graph's own `OnboardingClassification`, so the two join without
translation.
## Testing
`npm run typecheck` clean. `npm run lint` byte-identical to the
`origin/main` baseline. `npm run test`: 632 passing with the same 6
pre-existing failures as main (`public-assets` ×3,
`angular-docs-content` ×2, `llm-text` ×1); 36 new tests.
Verified in a running dev server across every branch of the mapping:
`/mastra/generative-ui` (React), `/vue/mastra`,
`/angular/mastra/quickstart`, `/react-native/mastra`, `/faq` (root
surface, Built-in Agent + React), `/slack/connect` (frontend sentence
correctly absent) and `/a2a/quickstart` (framework sentence absent,
frontend present). Double-click still produces exactly one clipboard
write and one event.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Onboarding prompts now include the relevant frontend context,
alongside framework and page details.
- Frontend context is detected automatically from documentation URLs,
including Vue, Angular, React, React Native, Slack, and Teams pages.
- Unscoped documentation and Cookbook pages default to the React
frontend.
- Frontend information is included in onboarding tracking when a
supported frontend is identified.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The "Copy agent prompt" button already told the CLI's onboarding graph
which agent framework the reader had selected. The docs carry a second
selector — Frontend — whose choice the prompt dropped, so the graph still
had to ask which frontend to configure.
Add a frontend sentence built exactly like the framework one and placed
between it and the page sentence, which is the order the graph works in:
it settles the agent framework first, then the frontend. Each sentence
leads with its own subject and can be empty independently, so all four
combinations read correctly.
The docs frontend is resolved from the URL, never from a stored
preference — choosing a frontend navigates to another URL, so the URL is
what asserts the selection. This is the rule the selector itself applies
(`urlFrontend ?? "react"`), and the same standard the framework sentence
already holds to. Resolution happens server-side and reaches the button
as a prop, so it cannot drift from the page being rendered.
Why `react` maps to the graph's `nextjs`: every frontend prompt under
`apps/cli/onboarding-prompts/frontend/` names the docs page it belongs
to, and `nextjs.md` is the only one whose documentation link is the
UNPREFIXED https://docs.copilotkit.ai/quickstart.md — the docs' default
`react` frontend, served at the root. Every other prompt points at its
own prefixed page (`/vue.md`, `/angular.md`, `/react-spa.md`,
`/react-native.md`). Same frontend, spelled differently on each side.
Slack and Teams stay deliberately unmapped. They are chat channels, not
application frontends; the graph has no node for either, so naming one
would promise a path the CLI cannot walk. The analytics `frontend`
property follows the same rule as `agent_framework`: the graph slug, and
the key omitted entirely when there is no equivalent.
A guard test over the docs frontend registry reads `FRONTEND_OPTIONS` —
the same list the app itself renders — so adding a frontend forces a
mapping decision instead of silently producing no sentence.
#6818 renamed the Intelligence docs from `/premium/` to `/intelligence/`
and left the published packages alone. This cleans them up.
## The console notice
`@copilotkit/shared` printed this to every developer who used
`useCopilotChatHeadless_c` without a license key:
> To enable this **premium** feature, add your public license key…
> To learn more about **premium** features, read the documentation here:
docs.copilotkit.ai/**premium**/overview
"Premium" is not a tier we have. The notice now uses the sentence the
Headless UI docs page already uses — "Headless UI requires a CopilotKit
Intelligence license key" — so a developer who reads the notice and then
opens the docs finds the same words.
## One link was broken, not just stale
The "Show me how" button on the missing-public-API-key error opened
`/premium/overview#getting-access`. That heading was deleted on
2026-06-16 in 449237af0c, so the redirect carried the fragment to a page
that has no such anchor and the button landed at the top. It had been
doing that for two and a half months. It now points at
`#plans-and-access`, the section that answers how to get a key.
This was not in the ticket. It came out of tracing the links rather than
replacing them.
## The rest
Stale but working links move from `/premium/*` to `/intelligence/*` in
`react-core`, `web-inspector` and the runtime skill reference (two
byte-identical copies). Every one of them resolved through the redirects
from #6818; each cost a hop and named a retired tier. Four test files
assert these hrefs, so they move with the strings.
Not touched: `seo-redirects.ts` in `showcase/` keeps `/premium/`, since
those entries are what makes the old links work. `user_type: 'premium'`
in the provider examples is invented customer metadata, not a tier.
## Verification
- `nx run-many -t check-types,test` for `shared`, `react-core`,
`web-inspector`, `runtime`, `runtime-client-gql`: all green (17, 33,
152, 138 and 5 test files)
- On a cold worktree, `nx affected` first reported
`runtime-client-gql:check-types`, `runtime:check-types`, `runtime:test`
and `runtime:generate-graphql-schema` as failures. Cause: `check-types`
runs `tsc` concurrently with the `build` that generates
`src/graphql/@generated/*`, so the first run type-checks against files
that do not exist yet. Running `build` first makes all of them pass, and
Nx labels the same four as flaky. Unrelated to this change.
## Blocked on the docs promote
`docs.copilotkit.ai` has not been promoted to production since #6818
merged. Right now production serves `/premium/*` directly with a 200 and
returns 404 for every `/intelligence/*` path. Staging serves the new
paths with a 200 and redirects `/premium/overview` to
`/intelligence/overview` in one hop, so the code is right and the deploy
is pending.
CodeRabbit flagged this and it is correct. Promote `shell-docs` to
production before the next monorepo release, or these links 404 for
anyone who clicks them. Merging is safe on its own, because the packages
only reach users through a release.
## Companion change
The Intelligence repo carries the same rename for the CLI onboarding
prompt and the verify hint: CopilotKit/Intelligence#1117. The two ship
independently.
Refs OSS-1085
Adds a **Copy agent prompt** button to the docs page-tools row, so a
reader can hand the CopilotKit onboarding flow to their coding agent
from any docs page instead of only from the three hero placements.
Closes OSS-1074.
## What it does
The button copies the canonical onboarding prompt
(`INTELLIGENCE_ONBOARDING_PROMPT`) with a freshly minted run id, plus
two factual sentences:
> … Follow the Markdown instructions it prints until onboarding is
complete. **The developer selected the Mastra agent framework
(`mastra`). The developer copied this prompt from
https://docs.copilotkit.ai/mastra/generative-ui.mdx.**
Both are statements of fact, never instructions — the CLI's prompt graph
stays in charge of the path, exactly as `frameworkPromptSuffix` already
established for the hero button. The framework sentence reuses that
helper verbatim; the page sentence is new and is what distinguishes this
placement from the hero one.
The canonical prompt constant is untouched, and a test asserts the
copied string is exactly `createIntelligenceOnboardingPrompt(runId)`
plus those suffixes, so nobody can quietly rewrite the shared text
through this path.
## Coverage
The button appears on every docs page that has a page-tools row and
resolves to an agent framework:
- all framework-scoped pages (`/<framework>/…`)
- the whole root surface, which is the Built-in Agent lens on those same
pages (`/quickstart`, `/backend/copilot-runtime`, `/faq`, `/concepts/…`,
`/troubleshooting/…`)
- the cookbook
- the frontend surfaces (`/vue/…`, `/angular/…`, `/react-native/…`),
where a missing backend segment *is* how the Built-in Agent is spelled
Deliberately excluded: the API reference (`/reference/…`, no
framework-prefixed variant exists, so the exclusion is consistent) and
the AG-UI docs (a separate protocol with its own brand — offering
CopilotKit setup there is the wrong offer; those pages have no
page-tools row at all).
Earlier revisions of this branch gated the root surface on a
content-resolution signal (`snippet_cell` / a Built-in-Agent override
file). That made identical pages behave differently depending on which
URL the reader arrived through — `/mastra/faq` had the button, `/faq`
did not. The gate is gone; the rule is now simply "does this page
resolve to a framework".
## Fixes a slug rename missed in OSS-1073
`DOCS_SLUG_RENAMES` in `intelligence-onboarding-framework.ts` claimed
`built-in-agent` was a framework the onboarding graph does not know, and
therefore stayed silent for it. The graph does know it — it spells it
`built-in` (`ONBOARDING_AGENT_FRAMEWORKS` in Intelligence
`apps/cli/src/services/onboarding-classification.ts`, and
`onboarding-prompts/framework/built-in.md`). Same shape as the
`crewai-crews` and `strands` renames already in the map.
**This also fixes the existing hero button**, which was dropping the
framework sentence on every Built-in Agent page — `/slack`, `/teams` and
the channel guides with no backend selected. Flagging it here rather
than burying it, since it changes behaviour outside this ticket's scope.
The display name is overridden to "Built-in Agent" at a single shared
call site; the registry name ("CopilotKit's Built-in Agent") would
produce "the CopilotKit's Built-in Agent agent framework".
## Telemetry
Reuses the existing `docs.intelligence_onboarding_prompt_copied` event
rather than adding one, with `surface:
"docs_page_tools_onboarding_prompt"` and `agent_framework` set to the
graph slug (omitted when there is none, matching the hero button). The
run id is minted per click and travels into the CLI, so a copy and the
onboarding run it starts can be joined — the gap OSS-1060 describes. The
button also carries `data-docs-copy-surface`, so the global copy tracker
reports it alongside the other conversion surfaces.
## Known, deliberate
- On the ~21 quickstart pages that embed
`<IntelligenceOnboardingPrompt>`, and on the ten framework roots with a
hero button, two affordances now copy an onboarding prompt. They do not
contradict each other — the page-tools one is a strict superset (it also
names the page). Which one should win is a product call, not made here.
- `/agent-spec/*` and `/a2a/*` get no button: they have no registry
record, so there is no framework to name. Naming nothing would be worse
than staying silent.
## Testing
`npm run typecheck`, `npm run lint` clean. `npm run test`: 568 passing,
with the same 6 pre-existing failures as `main` (`public-assets` ×3,
`angular-docs-content` ×2, `llm-text` ×1) — none related to these files.
Verified in a running dev server, not only in unit tests: the copied
string on framework, Built-in Agent and frontend pages; a fresh run id
per click matching the CLI's `/^[A-Za-z0-9_-]{12}$/`; three rapid clicks
producing exactly one clipboard write and one event; the icon swapping
without the row reflowing; light and dark themes; the mobile wrap; and
the absence of the button on `/reference/…` and `/ag-ui/…`.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a “Copy agent prompt” action to documentation pages.
* Prompts include relevant framework context and a direct link to the
page’s Markdown content.
* Framework-aware onboarding now works across framework docs, cookbook
pages, quickstarts, and other documentation surfaces.
* Added Built-in Agent support for onboarding prompts.
* **Improvements**
* Documentation action controls are presented consistently across
supported pages.
* Copy actions provide clearer loading, success, and error feedback.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
The stable Channels release publishes its dependency packages and
immediately runs the registry-backed umbrella verification. npm can
accept a publish while still returning a transient 404 for that exact
package version, which caused the 0.9.1 release to stop before
publishing `@copilotkit/channels`.
## Why
The verifier treated every npm 404 as a permanent missing-package error.
In the failed run, npm explicitly reported that
`@copilotkit/channels-whatsapp@0.9.1` was still being processed, and
verification began immediately afterward.
## Fix
Retry only npm E404 responses every 10 seconds for up to five minutes.
Keep all non-404 registry failures fail-fast, and retain the existing
release guidance if the package never appears.
Adds focused regression coverage for transient visibility, non-retryable
errors, and retry exhaustion.
Verification:
- `pnpm run verify:channels-umbrella:registry`
- `pnpm exec vitest run --config scripts/release/vitest.config.mts`
- targeted TypeScript, oxlint, and oxfmt checks
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added automatic retries when published channel manifests are
temporarily unavailable.
- Added release guidance when required channel packages remain
unavailable after the retry period.
- **Bug Fixes**
- Channel verification now handles temporary registry visibility delays
without failing immediately.
- Non-availability errors continue to fail without unnecessary retries.
- **Tests**
- Added coverage for retry behavior, non-retryable registry errors, and
exhausted retry attempts.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Release channels v0.9.1
**Scope:** `channels` | **Bump:** `patch`
---
### How this release process works
1. **This PR was created automatically** by the "release / create-pr"
workflow.
It bumped the `channels` packages to `0.9.1`
and generated AI-enhanced release notes.
2. **CI runs on this PR** — the full test suite (unit tests, lint, type
checks, build)
must pass before merging. This is the review gate.
3. **Review the release notes** in `release-notes.md` in this PR.
If a Notion draft was created, you can edit the release notes there
before merging.
4. **When this PR is merged**, the `release / publish` workflow
automatically:
- Builds all packages
- Publishes the `channels` packages to npm at version `0.9.1`
- Creates git tag `channels/v0.9.1`
- Creates a GitHub Release with the final release notes
### Before merging
- [ ] CI is green (tests, lint, types, build)
- [ ] Version bumps look correct
- [ ] Release notes are accurate (edit in Notion if a draft was created)
---
> **Do not merge until CI is fully green.** The full test suite runs
automatically on this PR.
## Summary
- replace unsupported v2 `useAgent` state props in shared-state
integration guides
- initialize missing UI-owned state after the agent is ready while
preserving existing state
- add source guards and rendered-route coverage for FAC-190 and FAC-194
## Tests
- `pnpm --dir showcase/shell-docs exec vitest run
src/lib/__tests__/legacy-useagent-state-docs.test.ts`
- `pnpm --dir showcase/shell-docs exec vitest run
src/lib/__tests__/llm-text.test.ts -t "renders supported state
initialization"`
- `pnpm --dir showcase/shell-docs exec tsc --noEmit`
## Summary
- mark the canonical hook-based React example as a client component
- remove the obsolete LangGraph-specific copy so generated routes have
one source
- add a regression test for the client boundary and single-source
invariant
## Test plan
- `npm exec -- vitest run src/lib/__tests__/llm-text.test.ts -t "keeps
programmatic control|renders a complete programmatic-control"`
- `npm run typecheck`
Linear:
https://linear.app/copilotkit/issue/FAC-170/consolidate-programmatic-control-react-examples-and-document-the
## Summary
- expand the Claude SDK Python shared-state setup with its actual
Messages API tool registration, state update, and route wiring
- document the TypeScript SDK selection and MCP tool registration path
for `set_notes`
- add runtime and rendered-doc regressions for both public framework
routes
Closes FAC-175 and FAC-178.
## Tests
- `npm run typecheck` and focused Vitest coverage in
`showcase/integrations/claude-sdk-typescript`
- `pytest tests/python/` in `showcase/integrations/claude-sdk-python`
- focused setup-content, visual setup, and LLM-text tests in
`showcase/shell-docs`
- `npm run typecheck` in `showcase/shell-docs`
Tyler Slaton