copilotkit 4.22.0 → 4.23.1

package/onboarding/prompts/research/route.md

@@ -9,7 +9,7 @@ sends the run down one path.
 Before you route on, run this from the target app directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect
 ```
 
 It reads the working tree itself, records every changed or untracked path with a digest,
@@ -31,28 +31,36 @@ route at the end of this prompt.
 
 ## Route a named Channel before the findings
 
-The prompt the developer copied names the docs page it came from. A Slack or Teams docs
-page names the surface this run is for. So does a developer who has already said Slack or
-Microsoft Teams. Either one settles the frontend.
+The prompt the developer copied names the docs page it came from. A CopilotKit docs page
+under `/channels`, `/slack`, or `/teams` names a Channel. So does a run that follows the
+`channels-setup` skill, which `copilotkit channels setup` installs in the project. The
+prompt that command prints names no page. So does a developer who asks for a Channel,
+Slack, or Microsoft Teams in their own words. Any one of these settles the frontend.
 
-Record that docs page and give it to every later node and subagent. The copied prompt is
-the only carrier of the surface the developer wants, and no flag states it.
+Record that page or request and give it to every later node and subagent. No flag states
+the surface the developer wants, so this record is its only carrier.
 
-On either, run this before you read the three findings below, and without asking the
-purpose question:
+On any one of them, run this before you read the three findings below, and without asking
+the purpose question:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/channels/start
+npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/channels/start
 ```
 
-Name the provider to that node so it does not ask again. A Slack page names Slack. A Teams
-page names Teams.
+Name the provider to that node so it does not ask again. A `/slack` page names Slack. A
+`/teams` page names Teams. A request that names no provider leaves that question to the
+node.
 
 Take this route whatever the three findings prove. An agent, a frontend and a CopilotKit
 integration are a valid start for a Channel, not a reason to convert the application: the
 run keeps that code as it is and wires a managed Channel onto it. Do not send a Channel
 request to the conversion route.
 
+Nothing else names a Channel. A project with its own channels, bots, or coworkers does not
+ask for one. A repository the developer asked you to clone does not ask for one either.
+Without one of the requests above, read the findings below. `frontend/plan` offers Slack
+and Microsoft Teams when the project has no frontend.
+
 ## What the merged findings must contain
 
 If a repository file exists, each finding must cite it. For an empty project, the subagents
@@ -97,7 +105,7 @@ settle these three from your own reading of the project. Each one comes from the
 packets or it is not proved.
 
 If all three are proved, prove the live starting state before any project file changes. Run
-`npx --prefer-offline --yes copilotkit@4.22.0 onboard read proof/oss-baseline`.
+`npx --prefer-offline --yes copilotkit@4.23.1 onboard read proof/oss-baseline`.
 
 Route there before you ask the developer anything else. The questions after this prompt
 select a framework and a frontend that the findings already name, so a developer who
@@ -110,7 +118,7 @@ developer nor the repository findings prove what the project is for, ask one gui
 question about the user outcome. This asks what the developer wants to build before you
 select a framework. Give two or three short examples. Record the answer and give it to
 each later subagent. Then run
-`npx --prefer-offline --yes copilotkit@4.22.0 onboard read credentials/plan`.
+`npx --prefer-offline --yes copilotkit@4.23.1 onboard read credentials/plan`.
 
 Do not ask that question on the route above. A project carrying all three states its
 purpose in the application it already serves.
@@ -124,5 +132,5 @@ A purpose question here names a domain before that choice.
 Take the same read named above without asking.
 
 If authentication, inspection, or the baseline capture stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.22.0 onboard read stopped/run-failed`. None of them says anything
+`npx --prefer-offline --yes copilotkit@4.23.1 onboard read stopped/run-failed`. None of them says anything
 about whether this project's stack is supported, which is not yet known at this point.

package/onboarding/prompts/starter/clone.md

@@ -55,7 +55,7 @@ the derived name.
 Only if the developer asks for an existing project, or asks to see the projects they have,
 read the choices:
 
-`npx --prefer-offline --yes copilotkit@4.22.0 project list --json`
+`npx --prefer-offline --yes copilotkit@4.23.1 project list --json`
 
 Then ask which one to use. Do not order the projects by creation time. If the developer
 already gave this answer, do not ask again. Do not read a secret value. Do not show or
@@ -84,7 +84,7 @@ Do not inspect another entry in the parent directory. Replace each placeholder w
 recorded value. Do not run a placeholder as a shell argument. If the path holds a space,
 put it in double quotes.
 
-`npx --prefer-offline --yes copilotkit@4.22.0 init --dir <absolute-target-directory> --framework <framework-id> --channel none --no-banner --no-key-prompt --create <name> --install`
+`npx --prefer-offline --yes copilotkit@4.23.1 init --dir <absolute-target-directory> --framework <framework-id> --channel none --no-banner --no-key-prompt --create <name> --install`
 
 `--dir` is always the absolute path of the target directory. `init` builds the app in that
 directory and gives the app the directory's name. Do not add `--name`: `init` refuses
@@ -144,7 +144,7 @@ When you ask, name each variable and the file it goes in, and say that the run c
 when they reply or resume this session. Then report the pause and end your turn:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard checkpoint --phase awaiting-model-credential
+npx --prefer-offline --yes copilotkit@4.23.1 onboard checkpoint --phase awaiting-model-credential
 ```
 
 This is a pause, not a stop. Do not send a stop report, and do not take a stop route.
@@ -155,10 +155,10 @@ call.
 
 If no credential is missing, report no pause and continue.
 
-Then run `npx --prefer-offline --yes copilotkit@4.22.0 onboard read proof/round-trip`.
+Then run `npx --prefer-offline --yes copilotkit@4.23.1 onboard read proof/round-trip`.
 
 If the command fails, report its exact error and do not claim that the starter is ready.
 Then run
-`npx --prefer-offline --yes copilotkit@4.22.0 onboard read stopped/run-failed`. The starter is one this
+`npx --prefer-offline --yes copilotkit@4.23.1 onboard read stopped/run-failed`. The starter is one this
 graph ships and the stack was chosen from its own supported list, so a command that
 returned an error is a run that broke, not a setup this release does not support.

package/onboarding/prompts/stopped/run-failed.md

@@ -41,7 +41,7 @@ put to them, stop here and send the report below.
 If they approve it, make that one fix and nothing else. Then come back into this run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard resume --message "<approval>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard resume --message "<approval>"
 ```
 
 Put the developer's approval in `--message`, in one or two sentences: the fix they
@@ -64,7 +64,7 @@ Send one short report. The friction command follows the telemetry setting the de
 already chose, so it needs no separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped

package/onboarding/prompts/subagent/create-plan.md

@@ -12,6 +12,13 @@ the documentation example differs from that purpose, the project wins.
 Read only inside the project directory. Answer an API question from the documentation
 URLs you were given, not from another checkout on this machine.
 
+The main coding agent also gives you the findings of the framework route, such as how the
+agent connects or whether a subclass needs a `clone()` override. Some of those rules, such
+as the `clone()` override, are on no documentation page. Use the findings of the framework
+route as they are. Do not confirm them again from the source of an installed package. Read
+the project's own code only to apply them, for example to find the fields that a `clone()`
+override copies.
+
 List the required credential variable names. Do not read or return credential values.
 Preserve each agent or frontend that already exists.
 
@@ -87,7 +94,7 @@ against a dead host, and the failure arrives as an empty-body 404 with no cause
 Ask the CLI for the dependency upgrade, from the target directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard upgrade-plan --json
+npx --prefer-offline --yes copilotkit@4.23.1 onboard upgrade-plan --json
 ```
 
 It reads the installed tree and the registry. Read `status`:
@@ -169,7 +176,7 @@ here is work the developer did not ask for.
 Plan the threads drawer itself: add it from the selected drawer page, where this frontend
 does not already render one. Where this journey's frontend framework ships no threads
 drawer -- React Native --, plan that the thread is proved by
-`npx --prefer-offline --yes copilotkit@4.22.0 verify --round-trip`, which needs no browser. Do not plan a
+`npx --prefer-offline --yes copilotkit@4.23.1 verify --round-trip`, which needs no browser. Do not plan a
 step that opens the managed Intelligence dashboard.
 
 ## Name the files the run writes itself

package/onboarding/prompts/subagent/implement-and-validate.md

@@ -115,7 +115,7 @@ Intelligence: declare each exact version in its app's manifest, then install wit
 project's package manager. Then check the installed tree:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard upgrade-plan --check --json
+npx --prefer-offline --yes copilotkit@4.23.1 onboard upgrade-plan --check --json
 ```
 
 `single` means every direct dependency resolved to one version. `duplicates` names each
@@ -130,7 +130,7 @@ If the check finds duplicates or the baseline regresses, put the manifests and l
 back, leave Intelligence unwired, and report what failed:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard upgrade-plan --revert --json
+npx --prefer-offline --yes copilotkit@4.23.1 onboard upgrade-plan --revert --json
 ```
 
 Then end your turn. Never add an `overrides`, `resolutions`, or `pnpm.overrides` block to
@@ -169,6 +169,38 @@ constructor for it, and never write an id the plan does not name: a selector poi
 id the platform does not hold answers `LEARNING_CONTAINER_NOT_FOUND` on every thread create.
 Where the plan names no container, write no selector.
 
+## Install the CopilotKit Skills
+
+The main coding agent gives you the developer's answer on the Skills install. Where the
+whole-plan implementation handoff carries no answer, read the approved plan. Approving the
+plan without a word on the Skills approves the install. A repair handoff that carries no
+Skills answer never installs them.
+
+Where `.agents/skills` already holds the CopilotKit skills, do not install them again.
+Report that they are in place.
+
+Install the Skills only when the developer approved them. Where the developer declined
+them, do not install them, and do not call that a change from the plan. Report in the
+Validation section that the developer declined them.
+
+Install them after you run the full validation list. Tell the developer what the skills
+install writes into this project before you run it: a `.agents/skills` directory holding
+one folder per CopilotKit skill, linked into `.claude/skills`. Both sit in the working tree,
+so the install shows up in `git status` and can land in a commit. You cannot know whether
+this project keeps those directories in version control, so name them before you write them
+rather than after.
+
+Then run `npx skills add CopilotKit/CopilotKit/skills -y` in the target app directory.
+
+The plan names both directories under `Files the run writes itself`, so they are not
+departures. Name them under Files changed. Do not register an MCP server: the Skills read
+the CopilotKit documentation without one.
+
+Check whether the install succeeded, and record the command result in the Validation
+section. A failed install does not change your status. Report it and continue.
+
+## Report the result
+
 Report the runtime constructor you wrote. Name whether it passes `intelligence` or
 `runner`, and whether it carries `getLearningContainerId`, with the id it returns.
 A runtime built with `runner` is the SSE runtime and never reads the credential,

package/onboarding/prompts/subagent/inspect-repository.md

@@ -7,7 +7,7 @@ Work only on the packet you were assigned. Inspect the repository without changi
 Run this first, from the target project directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard inspect --json
+npx --prefer-offline --yes copilotkit@4.23.1 onboard inspect --json
 ```
 
 It answers the deterministic half of both packets exactly, from the same code

package/onboarding/prompts/subagent/prove-oss-baseline.md

@@ -32,7 +32,7 @@ Prove the live runtime in this order:
 4. Confirm from project files that the runtime constructor passes a `runner` option rather
    than an `intelligence` option. A package, import, project file, or key is not use proof.
 5. Run
-   `npx --prefer-offline --yes copilotkit@4.22.0 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   `npx --prefer-offline --yes copilotkit@4.23.1 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
    with the runtime URL or auth header options that this project needs. Require exit zero
    and the JSON `ok` field to be `true`.
 6. Drive one real request through the existing frontend, CopilotKit runtime, and expected

package/onboarding/prompts/subagent/prove-round-trip.md

@@ -78,7 +78,7 @@ about the failure it was spawned to clear.
 Run this from the target app directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard proof-check --json
+npx --prefer-offline --yes copilotkit@4.23.1 onboard proof-check --json
 ```
 
 It starts each app's `dev` script unless a server from that app already listens, and
@@ -107,13 +107,14 @@ the proof. Then go to Step 5a.
 
 Otherwise sort `firstFailure`, and run the command again after each repair:
 
-- `runtime-answers`: nothing answered, or the project records no runtime URL. Read the
+- `runtime-answers`: nothing answered, or the project records no runtime URL. When the
+  record holds no URL, the command records one itself if exactly one port in the project
+  answers as a runtime. So this failure means it found none, or more than one. Read the
   server log it names. A dev server whose port is taken moves to the next free one without
-  asking, and a starter's project records no URL until its server binds a port. Read the
-  port from the log, not from the plan, and record it:
+  asking. Read the port from the log, not from the plan, and record it:
 
   ```text
-  npx --prefer-offline --yes copilotkit@4.22.0 onboard runtime-url --url <runtime-url>
+  npx --prefer-offline --yes copilotkit@4.23.1 onboard runtime-url --url <runtime-url>
   ```
 
   `<runtime-url>` is the project's runtime URL, or the plan's, with its port replaced by the
@@ -171,14 +172,19 @@ record it invented, and the first thing to notice is a card in a screenshot.
 Where this journey shares page data with the agent, prove that path here. Read the context
 entries this project's frontend publishes, from its own context call. Read the tool
 declarations it registers as well, and carry both the way the page carries them, so that
-the agent sees the request the browser sends rather than a thinner one. Send the same run
+the agent sees the request the browser sends rather than a thinner one. Read them from the
+files the main coding agent named in the handoff, and search the project only for a file it
+did not name. Do not search the dependencies for the shape of an entry: the page's own call
+shows it. Send the same run
 body twice, to `<runtime>/agent/<agent id>/run`: once carrying the context entries the page
 publishes, and once carrying the same entries with one value changed. Use the step 1
 request both times. Record the streamed events from each, and name both capture paths.
 
 For the changed run, pick one record the step 1 request matches. Add a marker to a text
-field that the answer repeats, such as its title or name:
-` [probe-<8 random hex characters>]`. Choose a new marker for each run, record it, and
+field that the answer repeats and that the step 1 request does not quote, such as its title
+or name: ` [probe-<8 random hex characters>]`. A model can copy text the request carries
+from the request rather than from the context, so a marker there proves nothing. Where the
+request quotes every text field of that record, add the marker to its id. Choose a new marker for each run, record it, and
 change nothing else. Do not remove the entry or send `context: []` instead. The page always
 sends its entries. A model with a request about records, a tool that needs them, and
 nothing to copy invents records. That failure belongs to the probe, not to the integration.
@@ -208,9 +214,14 @@ frontend does not know falls to a surface nothing draws. Neither writes anything
 browser console, so the browser step reports a finished turn, a blank card, and no error
 to read.
 
-Read the registrations this project's frontend declares, by name. Send the step 1 request
-to the route step 5a used, carrying those declarations, and read the tool calls out of
-that run's own events. The agent has to call one of the names the frontend registered. An
+Read the registrations this project's frontend declares, by name. Step 5a already sent the
+step 1 request with those declarations, so read the tool calls out of the events Step 5a
+captured for the run carrying the page's unchanged context. Do not send that request again.
+Where Step 5a sent no run, because this journey shares no page data, send the step 1 request
+to `<runtime>/agent/<agent id>/run`, carrying those declarations, and read the tool calls out
+of that run's own events. Where the Step 5a run carried none of those declarations, send
+that run once more with them, and read that run instead. Never report a wiring gap from a run
+that carried no declarations: the agent has no component to call in it. The agent has to call one of the names the frontend registered. An
 agent that calls nothing, or calls a name no registration matches, is a wiring gap for
 implementation to close rather than a proof repair. Return the name and the frontend file
 you read, before the browser.
@@ -238,7 +249,7 @@ For a recorded `both-oss` starting state, this step has no component to render.
 same request the baseline recorded, require the same kind of user-visible result the
 baseline produced, and require that the thread for that request is listed in the drawer.
 Where this journey's frontend framework ships no threads drawer -- React Native --, prove
-that thread with `npx --prefer-offline --yes copilotkit@4.22.0 verify --round-trip`, which reads the
+that thread with `npx --prefer-offline --yes copilotkit@4.23.1 verify --round-trip`, which reads the
 answer back off the thread and needs no browser. Record which of the two you proved.
 
 Use the surface control the main coding agent recorded for your environment. That finding
@@ -266,7 +277,7 @@ limit can be ten minutes. You cannot interrupt a call while it runs, so the limi
 what you do after one. If a browser call took longer than 60 seconds to return, the browser
 control is unresponsive. Do not call the browser again in this attempt. A second call to a
 hung tool waits as long as the first one did. Run
-`npx --prefer-offline --yes copilotkit@4.22.0 verify --frontend-url <the frontendUrl the proof checks resolved> --json` once,
+`npx --prefer-offline --yes copilotkit@4.23.1 verify --frontend-url <the frontendUrl the proof checks resolved> --json` once,
 and record the `frontend_assets_served` result. Report the outcome `failed` with the cause
 `browser-control-unresponsive`. The application is not at fault on this evidence: every
 step before the browser proved the runtime without one, and no repair to the project can
@@ -276,7 +287,7 @@ reach the tool.
    the page to finish loading. Do not retype the host, and do not substitute a URL a tool
    offers you by default. Where the page loads but its styling is missing or the chat
    control is dead, run
-   `npx --prefer-offline --yes copilotkit@4.22.0 verify --frontend-url <the url you opened> --json`
+   `npx --prefer-offline --yes copilotkit@4.23.1 verify --frontend-url <the url you opened> --json`
    before you diagnose anything else. A dev server can serve its page and refuse every
    static chunk behind it, and on screen that is indistinguishable from a broken
    integration. The `frontend_assets_served` check tells the two apart.
@@ -388,18 +399,25 @@ Step 9 can write only the tool files named by its guide or by this step.
 Fetch the continued-development guide from the main coding agent with the proof
 documentation. Try the continued-development tools after the application passes proof.
 
+The implementation subagent installs the Skills when the developer approved them. Check that
+it did. Look for the `.agents/skills` directory and the `.claude/skills` links in this
+project, and read the Skills result the implementation reported. Do not install them again.
+
+Where the developer declined them, do not install them, and do not call that a change from
+the plan. Report the command for them to run later instead:
+`npx skills add CopilotKit/CopilotKit/skills -y`.
+
+Where the developer approved them and they are missing, install them as a recovery step.
 Tell the developer what the skills install writes into this project before you run it: a
 `.agents/skills` directory holding one folder per CopilotKit skill, linked into
 `.claude/skills`. Both sit in the working tree, so the install shows up in `git status`
 and can land in a commit. You cannot know whether this project keeps those directories in
-version control, so name them before you write them rather than after.
-
-Install the Skills only when the approved plan includes them. Where the developer declined
-them, do not install them, and do not call that a change from the plan. Report the command
-for them to run later instead: `npx skills add CopilotKit/CopilotKit/skills -y`.
+version control, so name them before you write them rather than after. Then run
+`npx skills add CopilotKit/CopilotKit/skills -y` to install the
+project-scoped CopilotKit Skills. Record that the proof ran the install because the
+implementation did not.
 
-Use it to install the project-scoped CopilotKit Skills. Do not register an MCP server: the
-Skills read the CopilotKit documentation without one.
+Do not register an MCP server: the Skills read the CopilotKit documentation without one.
 
 Check whether the install succeeded and record what you found. Record the command result.
 Report the Skills result separately from the proof result. A tool error does not change the

package/onboarding/prompts/unsupported/no-validated-path.md

@@ -30,13 +30,13 @@ Before you show the best-effort plan, require this complete packet:
 - Give the ordered proof rules.
 
 After the developer approves the best-effort plan, run
-`npx --prefer-offline --yes copilotkit@4.22.0 onboard read fallback/best-effort`.
+`npx --prefer-offline --yes copilotkit@4.23.1 onboard read fallback/best-effort`.
 
 Send one short report. The friction command follows the telemetry setting the developer
 already chose, so it needs no separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "copilotkit",
-  "version": "4.22.0",
+  "version": "4.23.1",
   "type": "module",
   "engines": {
     "node": ">=20.9.0"
@@ -16,5 +16,8 @@
   "optionalDependencies": {
     "@microsoft/teams.cli": "3.0.3"
   },
+  "dependencies": {
+    "oidc-provider": "9.12.2"
+  },
   "license": "SEE LICENSE IN LICENSE"
 }