copilotkit 4.9.31 → 4.9.47

package/README.md

@@ -175,9 +175,18 @@ For a coding agent that needs an agent-readable sign-in flow, use:
 copilotkit login --json
 ```
 
-The command prints JSON lines for the sign-in URL, the action to take, and the
-final result. It does not open a browser. A failed sign-in prints one final
-failure object and exits nonzero.
+The command prints JSON lines for the sign-in URL, an instruction for the
+machine reader, and the final result. It does not open a browser. Every JSON
+login URL carries the `agent_onboarding` display hint because JSON mode is the
+machine-readable login contract. A machine reader should open the first
+`authentication_url` once with the operating system's default browser, then
+keep reading the same process until its terminal event. If the opener fails,
+show the URL for manual sign-in instead of retrying it. A failed sign-in prints
+one final failure object and exits nonzero.
+
+The bundled onboarding prompt gives one short explanation before it opens the
+page: sign-in lets the coding agent create a project and API key, and the user
+can remove the key later to disconnect the workspace.
 
 The onboarding commands are:
 
@@ -550,6 +559,7 @@ anything else:
 copilotkit verify
 copilotkit verify --json                                    # machine-readable output
 copilotkit verify --runtime-url http://localhost:8080/copilotkit
+copilotkit verify --frontend-url http://127.0.0.1:3000      # check that host's assets
 copilotkit verify --round-trip                              # also run the agent
 copilotkit verify --expect-runtime oss --round-trip --agent incident_triage
 ```
@@ -566,8 +576,13 @@ The selected project is read from the nearest `.copilotkit/project.json` at or
 above the current directory, stopping at the repository root, so running from
 one half of a repository finds the project the repository is bound to. `verify`
 names the directory it read the project from, and names where it searched when
-it found none. The API key is searched for the same way: `.env` and `.env.local`
-from the current directory up to the repository root.
+it found none. The API key is searched for the same way, plus one directory
+down: `.env` and `.env.local` from the current directory up to the repository
+root, and in the one package below it that depends on CopilotKit. That last part
+is what lets a run from the repository root of a two-half repository find a key
+in `web/.env.local`, which is the file the app loads. Two such packages below, or
+none, adds nothing to the search, because a credential resolved from the wrong
+half is worse than one reported as absent.
 
 Being found is not the same as being loadable. A framework's env loader does not
 walk up — Next.js, Vite, Nuxt and Astro all read env files from the application's
@@ -597,7 +612,7 @@ piping is safe.
 Use `--expect-runtime oss` to prove an open-source runtime instead. In this
 mode, hosted project, key, and thread-route checks do not apply. The command
 exits zero only when `/info` is valid, declares the agent named by `--agent`,
-omits `licenseStatus`, and `--round-trip` passes. Both `--round-trip` and
+reports no Intelligence entitlement, and `--round-trip` passes. Both `--round-trip` and
 `--agent` are required for an OSS pass.
 
 ### Which runtime URL gets probed
@@ -627,11 +642,49 @@ with the two ways to tell the command where to look — a working application on
 another port is not a wiring failure, and reporting it as one is how a developer
 ends up undoing correct work.
 
+An answer at the assumed default is read the same way. The runtime check passes,
+because a runtime did reply, but the line says which project answered is
+unverified. So do the declared agent names and `--round-trip`. Another checkout
+serving that port answers exactly the same, and the runtime version, the agent
+names, and the round trip are all read off whatever replied. Pass
+`--runtime-url`, or record `"runtimeUrl"`, to make the report name your project.
+
 The mount path is not discovered: every first-party starter serves the runtime
 at `/api/copilotkit`, and reading a framework's routing conventions to find out
 otherwise is the kind of check that drifts and starts reporting confident
 nonsense. Where yours is elsewhere, use option 1 or 2.
 
+### Which frontend URL you should open
+
+`verify` also reports `frontendUrl`: the origin to open in a browser, resolved
+from the same web dev server port as option 4 above and always written with
+`localhost`. It is reported so a caller has a URL handed to it rather than one it
+builds from a dev server's startup banner. `--frontend-url` overrides it, and the
+field is absent — never guessed — when the project named no port.
+
+It is a separate field from `runtimeUrl` and is not derived from it. The two are
+the same origin only when one dev server serves the page and mounts the runtime
+on it. A project whose runtime runs as a process of its own puts that runtime on
+port 8200, where no page is served.
+
+Pass `--frontend-url <the url you opened>` to add one more check,
+`frontend_assets_served`. It asks that origin for its page and then for one of
+the page's own scripts or stylesheets, read off the returned HTML, and compares
+the two answers:
+
+- Both served: `PASS`. That host is one the dev server serves assets on.
+- Page served, asset refused with `401` or `403`: `FAIL`. The dev server refuses
+  its own static assets on that host. A page that renders without its own chunks
+  leaves the CopilotKit control dead, which reads as a broken integration rather
+  than as the host name you used. On an IP literal the check names the
+  `localhost` URL to open instead.
+- Anything else: `UNKNOWN`, including a dev server that is not running.
+
+Without the flag the check is absent rather than `UNKNOWN`. A frontend dev
+server is not a surface `verify` requires to be running, so reporting "could not
+prove it" would sink the verdict of a correctly wired project whose browser is
+closed.
+
 A runtime mounted `mode: "single-route"` refuses `GET /info`, so `verify` asks
 the same question again through the POST envelope that mount does answer.
 Reaching it that way counts as reachable, and the report says which shape

package/cli-build-info.json

@@ -2,20 +2,20 @@
   "schemaVersion": 1,
   "package": {
     "name": "copilotkit",
-    "version": "4.9.31"
+    "version": "4.9.47"
   },
   "intelligence": {
-    "commit": "5f88d6f4e26b643eb1223b12cc05dad94055b5ef"
+    "commit": "85f6b2eb2b4c8fef747bbfb0e3f5991b196ecc43"
   },
   "copilotKit": {
-    "submittedInput": "c2038cf52ced16dc814e2ff0bd60894f2a53f5c1",
-    "commit": "c2038cf52ced16dc814e2ff0bd60894f2a53f5c1"
+    "submittedInput": "380ad1220a7bc78104baedc469c4d086c8910494",
+    "commit": "380ad1220a7bc78104baedc469c4d086c8910494"
   },
   "channel": "production",
-  "triggeringActor": "BenTaylorDev",
+  "triggeringActor": "MikeRyanDev",
   "workflow": {
-    "runId": "33679806270",
-    "runUrl": "https://github.com/CopilotKit/Intelligence/actions/runs/33679806270"
+    "runId": "34279600219",
+    "runUrl": "https://github.com/CopilotKit/Intelligence/actions/runs/34279600219"
   },
   "validationResult": "passed",
   "ag2": {
@@ -24,5 +24,5 @@
     "revision": "main",
     "pinned": false
   },
-  "builtAt": "2026-09-02T20:33:23Z"
+  "builtAt": "2026-09-08T21:17:26Z"
 }