kylon-cli 0.3.1 → 0.3.3-next.535

package/README.md

@@ -6,13 +6,31 @@ Requires Node.js 22.15.0 or newer.
 
 ## Install
 
-The CLI is published to npm as
+The recommended install is the hosted script (macOS/Linux):
+
+```bash
+curl -fsSL https://api.kylon.io/install.sh | sh
+```
+
+It installs the pinned CLI bundle under `~/.kylon` (no sudo; a machine
+without Node.js gets a private, checksum-verified runtime under
+`~/.kylon/runtime` that only Kylon uses), puts `kylon` on your PATH, records
+the serving environment as the default `--server-url`, and chains straight
+into `kylon login`. Rerunning it is safe. Non-production deployments serve
+the same script from their own API origin (for example
+`https://api.purework.ai/install.sh` installs `@next` and logs into dev).
+`KYLON_INSTALL_NO_LOGIN=1` installs without starting the login;
+`KYLON_INSTALL_NO_MODIFY_PATH=1` leaves shell profiles untouched.
+
+The CLI is also published to npm as
 [`kylon-cli`](https://www.npmjs.com/package/kylon-cli). The Web UI provides
 two distinct copy-paste entry points:
 
 - **Settings → Developer tools → Kylon CLI** shows
   `npx --yes kylon-cli@<tag> auth login --workspace <id>` — authorizes this
-  installation for human workspace commands. Its **Use with Your Agents**
+  installation for human workspace commands. Once installed, `kylon login`
+  with no flags does the same and lets the browser approval page choose the
+  workspace. Its **Use with Your Agents**
   prompt teaches Claude Code, Codex, Hermes, or OpenClaw to discover and use
   `kylon workspace` commands without assuming a provider-specific interface.
 - **An external agent's Profile** shows
@@ -37,8 +55,13 @@ never do, even though they serve the same workspace ids as dev. Run
 local runtime registration; it revokes nothing or changes any workspace-side
 agent configuration.
 
-`auth login` browser-authenticates the human operator for `kylon workspace`
-commands. `agent link` authenticates only the link operation with its embedded
+`kylon login` (alias `auth login`) browser-authenticates the human operator for
+`kylon workspace` commands. `--workspace <id>` pins the workspace up front;
+without it the browser approval page asks the user to choose one, defaulting to
+the workspace they most recently worked in. The default API server resolves
+from `--server-url`, then the server env vars, then the URL recorded by the
+hosted install script in `~/.kylon/server-url`, then production.
+`agent link` authenticates only the link operation with its embedded
 credential; it never creates a human CLI session. Linking mints or reuses an
 installation credential stored locally with mode `0600` and starts the local
 agent runtime. In release builds on supported environments a user-level
@@ -151,9 +174,11 @@ command, or run:
 npx --yes kylon-cli@latest auth login --workspace <WORKSPACE_ID>
 ```
 
-The CLI opens Kylon in your browser. After you sign in, confirm the installation
-and workspace shown on the authorization page, and verify that its confirmation
-code matches the one printed in your terminal. The browser approves a short-lived
+(or, once `kylon` is installed, just `kylon login` — the browser page then asks
+which workspace to authorize). The CLI opens Kylon in your browser. After you
+sign in, confirm the installation and workspace shown on the authorization
+page, and verify that its confirmation code matches the one printed in your
+terminal. The browser approves a short-lived
 request but never receives the credential. The CLI proves possession of its PKCE
 verifier while polling Kylon over HTTPS, receives the credential directly from
 the API, and saves it in the versioned credential collection at