copilotkit 4.9.50 → 4.9.60

package/README.md

@@ -72,6 +72,22 @@ copilotkit project select --create "My App" --json # create one and select it
 against the organization's real projects, so a typo fails with the available
 slugs instead of recording a selection that points at nothing.
 
+A `--create` name that an existing project already uses is refused, and the
+refusal names a free name computed from the list the CLI already holds, so a
+caller retries once rather than guessing. Under `--json` the same name is
+carried as `suggested_name`:
+
+```json
+{
+  "error": "You already have a project named \"My App\". \"My App-2\" is free.",
+  "suggested_name": "My App-2",
+  "type": "failed"
+}
+```
+
+The interactive picker offers the same name and never applies it silently:
+press Enter again to take it, or type a different one.
+
 `--json` emits one object on stdout:
 
 ```json
@@ -402,6 +418,7 @@ Run the Learning commands from a directory with a selected hosted project:
 copilotkit learning containers list
 copilotkit learning containers get support-quality
 copilotkit learning containers create
+copilotkit learning containers select
 copilotkit learning containers update support-quality
 copilotkit learning containers delete support-quality
 ```
@@ -410,6 +427,17 @@ The create and update commands prompt for missing fields in a human terminal.
 The delete command shows the exact container and asks for approval. The CLI
 cannot delete a container with bound Threads or Learning history.
 
+`select` offers the containers this project already has and prints the one you
+pick, and its create form opens on an id derived from the project slug, because
+one container per project is the default scope. Route runs to different
+containers per user or per tier from `getLearningContainerId` in your own
+runtime, which receives the resolved application user; a container per user
+rarely reaches the 15 distinct conversations a first Learning run needs. Choose `Create a new container` to make one instead. It reads the first
+page before it draws the list and reads a later page only when you choose
+`Show more`, so a project with one container costs one read. `select` needs a
+terminal: with `--json`, or with no TTY, it refuses and names `list` and
+`create` instead.
+
 Pass flags for a script or coding agent:
 
 ```bash
@@ -722,7 +750,11 @@ present** says the credential exists somewhere in this repository, and **The app
 can load the project API key** says the directory the app runs in supplies it.
 The second is `UNKNOWN` rather than `FAIL` wherever it cannot decide: no package
 declaring a `@copilotkit/*` dependency was found, more than one was, or a script
-in the app names an env file itself with `dotenv`, `env-cmd`, or `--env-file`.
+in the app — or in any package above it, up to the project root — names an env
+file itself with `dotenv`, `env-cmd`, or `--env-file`. It is also `UNKNOWN` when
+a runtime answered and reported an Intelligence entitlement, because a runtime
+cannot report one without having loaded a key: the report then names the
+disagreement instead of claiming the app cannot load a key the runtime is using.
 
 That last check is the one a passing build cannot give you. A key in `.env`
 proves only that one was provisioned: the runtime reads no environment variable
@@ -818,9 +850,17 @@ 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
-answered. That mount carries no thread or memory route, though, so a licensed
-project on it fails the thread-route check with the mount named as the cause.
-Removing `mode: "single-route"` fixes it.
+answered.
+
+That mount serves its thread and memory routes too, inside the same envelope as
+the `resource/request` method, and the client rewrites every such fetch into it.
+So the thread-route check passes there and says the routes were served that way,
+rather than as REST paths. It reads the `singleRoute` block of `/info` to decide,
+because the top-level `threadEndpoints` block reports the routes absent on that
+mount whatever it serves: the runtime resolves that block from whether the
+request in hand is a `resource/request`, and an `info` call never is. A runtime
+below `@copilotkit/runtime` 1.70.2 reports no `singleRoute` block and therefore
+cannot say, so the check is `UNKNOWN` there and names the upgrade.
 
 ### Proving the agent runs, not just that it is configured
 

package/cli-build-info.json

@@ -2,20 +2,20 @@
   "schemaVersion": 1,
   "package": {
     "name": "copilotkit",
-    "version": "4.9.50"
+    "version": "4.9.60"
   },
   "intelligence": {
-    "commit": "1e703c3c476af7d0a52f801e34fbce2997f6a926"
+    "commit": "5f0f9a7cf15492544f1341f562fa5cd55387099c"
   },
   "copilotKit": {
-    "submittedInput": "380ad1220a7bc78104baedc469c4d086c8910494",
-    "commit": "380ad1220a7bc78104baedc469c4d086c8910494"
+    "submittedInput": "d1584b840f904674b470be5d2b16c4ccca99c4f4",
+    "commit": "d1584b840f904674b470be5d2b16c4ccca99c4f4"
   },
   "channel": "production",
   "triggeringActor": "BenTaylorDev",
   "workflow": {
-    "runId": "34486444519",
-    "runUrl": "https://github.com/CopilotKit/Intelligence/actions/runs/34486444519"
+    "runId": "34616405214",
+    "runUrl": "https://github.com/CopilotKit/Intelligence/actions/runs/34616405214"
   },
   "validationResult": "passed",
   "ag2": {
@@ -24,5 +24,5 @@
     "revision": "main",
     "pinned": false
   },
-  "builtAt": "2026-09-10T14:04:08Z"
+  "builtAt": "2026-09-11T15:30:58Z"
 }