copilotkit 4.9.2 → 4.9.4

package/onboarding/prompts/proof/complete.md

@@ -45,7 +45,7 @@ Name the debugging surface this journey's frontend can reach, rather than the on
 of the documentation leads with. For a web frontend it is the CopilotKit Inspector. For
 React Native there is no Inspector: it is a browser overlay built on a DOM custom element,
 and `@copilotkit/react-native` does not ship it. Give a mobile developer
-`npx --yes copilotkit@4.9.2 verify --round-trip`, the runtime's own log, the AG-UI
+`npx --yes copilotkit@4.9.4 verify --round-trip`, the runtime's own log, the AG-UI
 Event Inspector in the CopilotKit VS Code extension, and the Intelligence thread view
 instead. Naming the Inspector to a developer who cannot open it costs them the time it
 takes to conclude their own wiring is broken.
@@ -57,7 +57,7 @@ the friction commands without another developer question. The CLI telemetry gate
 whether the report is sent.
 
 ```text
-npx --yes copilotkit@4.9.2 onboard friction --category <slug> --cost-seconds <seconds>
+npx --yes copilotkit@4.9.4 onboard friction --category <slug> --cost-seconds <seconds>
 ```
 
 Write one or two sentences on the command's standard input. Pick one category from
@@ -74,14 +74,14 @@ Tell the developer when you send a friction report. Do not quote or summarize th
 unless the developer asks. If the CLI says that telemetry is disabled or unavailable,
 state that the report was not sent and continue without another question.
 
-When the evidence is gathered, run `npx --yes copilotkit@4.9.2 onboard complete`, carrying
+When the evidence is gathered, run `npx --yes copilotkit@4.9.4 onboard complete`, carrying
 the surface-check outcome the proof subagent returned. Pass exactly one flag, and pass the
 one that matches this journey's surface.
 
 For a web frontend -- React SPA, Next.js, Angular, Vue:
 
 ```text
-npx --yes copilotkit@4.9.2 onboard complete --visual-check <outcome>
+npx --yes copilotkit@4.9.4 onboard complete --visual-check <outcome>
 ```
 
 The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`.
@@ -89,7 +89,7 @@ The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`.
 For React Native:
 
 ```text
-npx --yes copilotkit@4.9.2 onboard complete --device-check <outcome>
+npx --yes copilotkit@4.9.4 onboard complete --device-check <outcome>
 ```
 
 The outcome is one of `performed`, `skipped-no-device`, or `failed`.
@@ -102,3 +102,20 @@ Pass the outcome you were given rather than the one you wanted. Anything but `pe
 prints what the missing check leaves unverified and ends this run as blocked. That output
 is the developer's finding, so carry it into the summary rather than restating it as a
 smaller caveat.
+
+If the round trip proved and something after it still blocked this run, add `--blocked-by`
+to the same command:
+
+```text
+npx --yes copilotkit@4.9.4 onboard complete --visual-check performed --blocked-by <cause>
+```
+
+The cause is one of `hosted-dashboard` for a managed dashboard that did not load or refused
+a sign-in, `inspector` for a debugging surface that did not open, `plan-excluded-capability`
+for a capability the approved plan had already excluded for this framework, and `other` for
+anything else. Pick `other` rather than leaving the flag off. The command ends the run as
+blocked and prints what the blocker leaves unverified.
+
+This is the flag for a journey that worked. It is not a way to report an unsupported path,
+and a blocked run here is still owed the full handoff above: the URL, the start command,
+the process IDs, and the versions this conversion changed.

package/onboarding/prompts/proof/oss-baseline.md

@@ -10,11 +10,11 @@ processes and their ignored runtime files is allowed.
 
 If the subagent proves the `both-oss` predicate, keep its evidence with the plan. If it
 proves another supported starting state, record that state. In either case, run
-`npx --yes copilotkit@4.9.2 onboard read credentials/plan`.
+`npx --yes copilotkit@4.9.4 onboard read credentials/plan`.
 
 If it cannot identify the running process safely, exposes a secret, or finds a baseline
 failure that cannot be classified, run
-`npx --yes copilotkit@4.9.2 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
 
 ## Baseline proof subagent brief
 
@@ -40,7 +40,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 --yes copilotkit@4.9.2 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   `npx --yes copilotkit@4.9.4 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/proof/round-trip.md

@@ -4,30 +4,41 @@ Do not do the proof work yourself. Spawn one proof subagent.
 
 Give the subagent the full text of the proof brief at the end of this prompt, the selected
 framework, frontend, model, approved plan, selected documentation URLs, and validation
-evidence.
+evidence. Give it the documentation policy recorded during framework selection.
 
 Give it the browser or device control you recorded in the preflight as well. The subagent
 drives the surface and cannot see your environment, so without that finding it spends the
 step discovering what you already know. A subagent told it has no control for the surface
 this frontend needs reports the skip outcome rather than looking for a way around it.
 
-Wait for the subagent to finish.
-
 Give the subagent this guide for continued-development tools:
 https://docs.copilotkit.ai/build-with-agents.md
 
+Wait for the subagent to finish.
+
 If the subagent proves the complete round trip, run
-`npx --yes copilotkit@4.9.2 onboard read proof/complete`. The round trip proves core success
+`npx --yes copilotkit@4.9.4 onboard read proof/complete`. The round trip proves core success
 even if a continued-development tool fails. Keep the Skills and MCP results separate from
 the proof result.
 
+If the round trip proves and something after it blocks this run anyway -- the managed
+Intelligence dashboard, the debugging surface, or a capability the approved plan already
+excluded for this framework -- read `proof/complete` all the same, with the command above,
+and carry the blocker there with `--blocked-by`.
+The stop terminal is for a journey this release cannot carry. It is
+not for a journey that worked and then hit a wall: routing a proved run there tells the
+developer that a framework and frontend that just worked are unsupported, and hands them a
+stop report instead of the application they now have.
+
 If the round trip fails, decide which kind of failure it is before you route. A failure
 caused by a file this run created or changed is a defect in the new work. Send it back to
 the proof subagent to fix and prove again, at most three attempts.
 
 Route out only when the failure is not yours to fix, when the same proof still fails after
 three attempts, or when no evidence of the round trip can be produced. In those cases run
-`npx --yes copilotkit@4.9.2 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`. All three are
+about the round trip itself. A round trip that proved is not one of them, whatever failed
+after it.
 
 ## Proof subagent brief
 
@@ -37,9 +48,8 @@ Everything below the rule is the subagent's prompt. Give it verbatim.
 
 # Prove the complete round trip
 
-Use the proof steps and documentation URLs from the approved plan. Fetch every selected
-URL in one step before you start, rather than one after another.
-Do not use remembered CopilotKit instructions.
+Use the proof steps and documentation URLs from the approved plan. Follow the documentation
+policy the main coding agent gives you before you start.
 
 Run the steps below in the order they appear. They are the proof. Do not design a
 different sequence of your own, and do not drop a step because an earlier one looked
@@ -52,11 +62,6 @@ the record. That directory holds regenerable evidence rather than application co
 a browser or device tool writes to a location of its own, keep that location and record
 it instead.
 
-A fetch tool that refuses a URL, or fails to reach it, reports a limit of the tool and
-not a fact about the page. Retrieve the same URL a second way before you judge it. Run
-`curl -fsSL <url>`, or read the same page without the `.md` suffix. Report a
-documentation gap only after a second method also fails.
-
 Gather what you need in as few commands as possible. Combine independent reads into one
 command rather than running them one at a time. Split a command only when its result decides
 what you run next.
@@ -145,7 +150,7 @@ IPv6 only, so an IPv4 literal fails against the correct port.
 ## Step 4 -- Check the wiring
 
 With both running, check the wiring in one command before you open a browser:
-`npx --yes copilotkit@4.9.2 verify --json`. Add `--runtime-url` when the runtime is not at
+`npx --yes copilotkit@4.9.4 verify --json`. Add `--runtime-url` when the runtime is not at
 `http://localhost:3000/api/copilotkit`. Read the individual checks rather than the summary
 alone: a check reported `undetermined` did not run, and that is not a pass. Fix anything
 that is not a pass before the browser, because a browser failure stacked on broken wiring
@@ -165,7 +170,7 @@ Record that and move on -- there is nothing to repair.
 
 ## Step 5 -- Prove that the agent runs
 
-Run `npx --yes copilotkit@4.9.2 verify --round-trip --json`. It sends one request through
+Run `npx --yes copilotkit@4.9.4 verify --round-trip --json`. It sends one request through
 the runtime and reads the answer back from the thread, so it separates an agent that is
 configured from an agent that works. Use `--agent <id>` when the runtime declares more
 than one. If it reports `user-not-identified`, this project's `identifyUser` reads a
@@ -184,20 +189,20 @@ generative UI component actually rendering, and no command-line check reaches an
 It is not optional polish: a run that skips it has proven the agent and not the journey,
 and the graph ends such a run as blocked rather than complete.
 
-Use the surface control the main coding agent recorded for your environment. Do not add a
-browser driver or a device tool to this project: a devDependency and a browser download
-land in the diff and tax a repository that never asked for one. If nothing in your
-environment can drive the surface this journey needs, skip this step rather than
-installing one, and report the skip outcome named below.
+Use the surface control the main coding agent recorded for your environment. It either had
+one already or registered one before this step, so that finding is the answer and there is
+nothing here for you to go looking for. Do not add a browser driver or a device tool to this
+project: a devDependency and a browser download land in the diff and tax a repository that
+never asked for one, which is a different thing from the server registered against the
+coding agent. If nothing in your environment can drive the surface this journey needs, skip
+this step rather than installing one, and report the skip outcome named below.
 
 Never report a result you did not see, on either surface.
 
 ### Step 6a -- Web frontends: React SPA, Next.js, Angular, Vue 3
 
 The surface is a browser, and it also covers browser-origin CORS and CSP, which a CLI
-request never exercises. Use a browser MCP server already configured for the coding agent
-you are running as, the same way step 9 configures the CopilotKit documentation MCP
-server.
+request never exercises. Drive it with the browser control step 6 named.
 
 1. Open the frontend URL from step 2 and wait for the page to finish loading.
 2. Take one page snapshot. Record whether the CopilotKit surface is on the page. A page

package/onboarding/prompts/starter/clone.md

@@ -36,7 +36,7 @@ instruction in this prompt.
 
 If the developer did not name an Intelligence project, list the available projects:
 
-`npx --yes copilotkit@4.9.2 project list --json`
+`npx --yes copilotkit@4.9.4 project list --json`
 
 Ask the developer to select a project or give a name for a new project. If the developer
 already gave this answer, do not ask again. Do not read a secret value. Do not show or
@@ -46,7 +46,7 @@ Run the command from the parent directory. Do not inspect another entry in the p
 directory. Replace each placeholder with the recorded value. Do not run a placeholder as
 a shell argument.
 
-`npx --yes copilotkit@4.9.2 init --name <project-name> --framework <framework-id> --channel none --no-banner --project <slug-or-id> --install`
+`npx --yes copilotkit@4.9.4 init --name <project-name> --framework <framework-id> --channel none --no-banner --project <slug-or-id> --install`
 
 If the developer wants a new project, use `--create <name>` instead of
 `--project <slug-or-id>`. If the developer asked to skip the dependency install, use
@@ -60,8 +60,8 @@ account. The command does not need terminal input.
 If the command succeeds, do not rebuild the starter by hand. Inspect only the generated
 paths inside the target directory. Record the files, install result, project connection,
 and validation commands. Then run
-`npx --yes copilotkit@4.9.2 onboard read proof/round-trip`.
+`npx --yes copilotkit@4.9.4 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 --yes copilotkit@4.9.2 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.

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

@@ -1,20 +1,13 @@
 # Create the onboarding plan
 
 Use the selected framework, frontend, model, repository findings, and documentation URLs
-from the main coding agent. Fetch every selected URL in one step rather than one after
-another. Do not use remembered CopilotKit instructions.
-
-A fetch tool that refuses a URL, or fails to reach it, reports a limit of the tool and
-not a fact about the page. Retrieve the same URL a second way before you judge it. Run
-`curl -fsSL <url>`, or read the same page without the `.md` suffix. Report a
-documentation gap only after a second method also fails.
+from the main coding agent. Follow the documentation policy it gives you.
 
 Name the application the project asks for, and plan that application. Each documentation
 page teaches through one worked example, and that example carries a domain of its own.
-The domain belongs to the page. The project's purpose from the repository findings
-decides what gets built. Where the two differ, the project wins. Where the repository
-never states a purpose, say so in the plan and ask the developer before you adopt the
-domain of an example.
+The domain belongs to the page. Use the purpose from the repository findings, or the
+developer outcome if the repository purpose was unproved. Do not ask for it again. Where
+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.

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

@@ -1,13 +1,7 @@
 # Implement and validate the approved plan
 
-Use only the approved plan and the selected documentation URLs. Fetch every URL in one
-step, before you change the project, rather than one after another.
-Do not use remembered CopilotKit instructions.
-
-A fetch tool that refuses a URL, or fails to reach it, reports a limit of the tool and
-not a fact about the page. Retrieve the same URL a second way before you judge it. Run
-`curl -fsSL <url>`, or read the same page without the `.md` suffix. Report a
-documentation gap only after a second method also fails.
+Use only the approved plan and the selected documentation URLs. Follow the documentation
+policy the main coding agent gives you before you change the project.
 
 Add only the props, options, and imports that appear in the fetched documentation. A
 remembered API from an earlier CopilotKit version will fail type checking against this

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

@@ -3,14 +3,20 @@
 Inspect the repository without changing it. Find evidence for:
 
 - what the project is for, in the project's own words
-- any existing agent framework
-- any existing frontend
-- current CopilotKit packages and configuration
+- the target app or runtime directory that owns `.env` and the CopilotKit setup
+- whether the target project directory contains any entries
+- any existing agent framework and frontend
+- current CopilotKit integration and configuration, including whether
+  `.copilotkit/project.json` has `projectId`, `projectSlug`, and `clerkOrgId`
 - authentication boundaries
-- names of required credential variables, without reading their values
+- names of required credential variables and whether `.env` has a non-empty
+  `INTELLIGENCE_API_KEY`
+- retain the `.env` modification time for a later comparison without returning it
 - package manager and lockfile
 - required toolchains and their installed versions
 - declared ports and whether each port is available
+- whether the runtime constructor uses a `runner` option, an `intelligence` option, or
+  neither can be proved from project files
 - CopilotKit package versions and package compatibility risks
 
 For the CopilotKit versions, report the exact installed version of every `@copilotkit/*`
@@ -29,6 +35,7 @@ what you run next. Keep this preflight read-only. Do not install packages, stop
 or change a port. Check only the toolchains and ports that repository files require.
 
 Return the file paths and a short finding for each item. State each absent or unproved item.
-Do not read, print, or return secret values. Do not read a file outside the project
-directory. Do not run or return another onboarding command. Stop after returning the
-findings to the main coding agent.
+Do not read, print, or return secret values. For `.env` and `.copilotkit/project.json`
+checks, return only paths, presence checks, and missing field names. Do not read a file
+outside the project directory. Do not run or return another onboarding command. Stop after
+returning the findings to the main coding agent.

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

@@ -16,7 +16,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 --yes copilotkit@4.9.2 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   `npx --yes copilotkit@4.9.4 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

@@ -1,8 +1,7 @@
 # Prove the complete round trip
 
-Use the proof steps and documentation URLs from the approved plan. Fetch every selected
-URL in one step before you start, rather than one after another.
-Do not use remembered CopilotKit instructions.
+Use the proof steps and documentation URLs from the approved plan. Follow the documentation
+policy the main coding agent gives you before you start.
 
 Run the steps below in the order they appear. They are the proof. Do not design a
 different sequence of your own, and do not drop a step because an earlier one looked
@@ -15,11 +14,6 @@ the record. That directory holds regenerable evidence rather than application co
 a browser or device tool writes to a location of its own, keep that location and record
 it instead.
 
-A fetch tool that refuses a URL, or fails to reach it, reports a limit of the tool and
-not a fact about the page. Retrieve the same URL a second way before you judge it. Run
-`curl -fsSL <url>`, or read the same page without the `.md` suffix. Report a
-documentation gap only after a second method also fails.
-
 Gather what you need in as few commands as possible. Combine independent reads into one
 command rather than running them one at a time. Split a command only when its result decides
 what you run next.
@@ -108,7 +102,7 @@ IPv6 only, so an IPv4 literal fails against the correct port.
 ## Step 4 -- Check the wiring
 
 With both running, check the wiring in one command before you open a browser:
-`npx --yes copilotkit@4.9.2 verify --json`. Add `--runtime-url` when the runtime is not at
+`npx --yes copilotkit@4.9.4 verify --json`. Add `--runtime-url` when the runtime is not at
 `http://localhost:3000/api/copilotkit`. Read the individual checks rather than the summary
 alone: a check reported `undetermined` did not run, and that is not a pass. Fix anything
 that is not a pass before the browser, because a browser failure stacked on broken wiring
@@ -128,7 +122,7 @@ Record that and move on -- there is nothing to repair.
 
 ## Step 5 -- Prove that the agent runs
 
-Run `npx --yes copilotkit@4.9.2 verify --round-trip --json`. It sends one request through
+Run `npx --yes copilotkit@4.9.4 verify --round-trip --json`. It sends one request through
 the runtime and reads the answer back from the thread, so it separates an agent that is
 configured from an agent that works. Use `--agent <id>` when the runtime declares more
 than one. If it reports `user-not-identified`, this project's `identifyUser` reads a
@@ -147,20 +141,20 @@ generative UI component actually rendering, and no command-line check reaches an
 It is not optional polish: a run that skips it has proven the agent and not the journey,
 and the graph ends such a run as blocked rather than complete.
 
-Use the surface control the main coding agent recorded for your environment. Do not add a
-browser driver or a device tool to this project: a devDependency and a browser download
-land in the diff and tax a repository that never asked for one. If nothing in your
-environment can drive the surface this journey needs, skip this step rather than
-installing one, and report the skip outcome named below.
+Use the surface control the main coding agent recorded for your environment. It either had
+one already or registered one before this step, so that finding is the answer and there is
+nothing here for you to go looking for. Do not add a browser driver or a device tool to this
+project: a devDependency and a browser download land in the diff and tax a repository that
+never asked for one, which is a different thing from the server registered against the
+coding agent. If nothing in your environment can drive the surface this journey needs, skip
+this step rather than installing one, and report the skip outcome named below.
 
 Never report a result you did not see, on either surface.
 
 ### Step 6a -- Web frontends: React SPA, Next.js, Angular, Vue 3
 
 The surface is a browser, and it also covers browser-origin CORS and CSP, which a CLI
-request never exercises. Use a browser MCP server already configured for the coding agent
-you are running as, the same way step 9 configures the CopilotKit documentation MCP
-server.
+request never exercises. Drive it with the browser control step 6 named.
 
 1. Open the frontend URL from step 2 and wait for the page to finish loading.
 2. Take one page snapshot. Record whether the CopilotKit surface is on the page. A page

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

@@ -18,13 +18,13 @@ Mark each step that the selected pages do not prove. Do not treat the documentat
 proof that the requested integration is unsupported.
 
 After the developer approves the best-effort plan, run
-`npx --yes copilotkit@4.9.2 onboard read fallback/best-effort`.
+`npx --yes copilotkit@4.9.4 onboard read fallback/best-effort`.
 
 Send one short report. Run the feedback command without another developer question. The
 CLI telemetry gate decides whether the report is sent.
 
 ```text
-npx --yes copilotkit@4.9.2 onboard feedback
+npx --yes copilotkit@4.9.4 onboard feedback
 ```
 
 Write the feedback message to the command's standard input, in at most four lines.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "copilotkit",
-  "version": "4.9.2",
+  "version": "4.9.4",
   "type": "module",
   "repository": {
     "type": "git",

package/release/release-tool.js

@@ -14698,7 +14698,7 @@ import * as path4 from "node:path";
 
 // apps/cli/src/config.ts
 function getTemplateRef() {
-  return true ? "e432fd161b9114fb15080dbd9d9208e29f5e8960" : "main";
+  return true ? "f6f2dc4bb62b50d2f09384619f5b9e8fe7edde02" : "main";
 }
 
 // apps/cli/src/services/agentcore-config.ts