kylon-cli 0.3.1 → 0.3.2-next.534
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +15 -6
- package/dist/kylon-bundle.mjs +1 -1
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -12,7 +12,9 @@ two distinct copy-paste entry points:
|
|
|
12
12
|
|
|
13
13
|
- **Settings → Developer tools → Kylon CLI** shows
|
|
14
14
|
`npx --yes kylon-cli@<tag> auth login --workspace <id>` — authorizes this
|
|
15
|
-
installation for human workspace commands.
|
|
15
|
+
installation for human workspace commands. Once installed, `kylon login`
|
|
16
|
+
with no flags does the same and lets the browser approval page choose the
|
|
17
|
+
workspace. Its **Use with Your Agents**
|
|
16
18
|
prompt teaches Claude Code, Codex, Hermes, or OpenClaw to discover and use
|
|
17
19
|
`kylon workspace` commands without assuming a provider-specific interface.
|
|
18
20
|
- **An external agent's Profile** shows
|
|
@@ -37,8 +39,13 @@ never do, even though they serve the same workspace ids as dev. Run
|
|
|
37
39
|
local runtime registration; it revokes nothing or changes any workspace-side
|
|
38
40
|
agent configuration.
|
|
39
41
|
|
|
40
|
-
`auth login` browser-authenticates the human operator for
|
|
41
|
-
|
|
42
|
+
`kylon login` (alias `auth login`) browser-authenticates the human operator for
|
|
43
|
+
`kylon workspace` commands. `--workspace <id>` pins the workspace up front;
|
|
44
|
+
without it the browser approval page asks the user to choose one, defaulting to
|
|
45
|
+
the workspace they most recently worked in. The default API server resolves
|
|
46
|
+
from `--server-url`, then the server env vars, then the URL recorded by the
|
|
47
|
+
hosted install script in `~/.kylon/server-url`, then production.
|
|
48
|
+
`agent link` authenticates only the link operation with its embedded
|
|
42
49
|
credential; it never creates a human CLI session. Linking mints or reuses an
|
|
43
50
|
installation credential stored locally with mode `0600` and starts the local
|
|
44
51
|
agent runtime. In release builds on supported environments a user-level
|
|
@@ -151,9 +158,11 @@ command, or run:
|
|
|
151
158
|
npx --yes kylon-cli@latest auth login --workspace <WORKSPACE_ID>
|
|
152
159
|
```
|
|
153
160
|
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
161
|
+
(or, once `kylon` is installed, just `kylon login` — the browser page then asks
|
|
162
|
+
which workspace to authorize). The CLI opens Kylon in your browser. After you
|
|
163
|
+
sign in, confirm the installation and workspace shown on the authorization
|
|
164
|
+
page, and verify that its confirmation code matches the one printed in your
|
|
165
|
+
terminal. The browser approves a short-lived
|
|
157
166
|
request but never receives the credential. The CLI proves possession of its PKCE
|
|
158
167
|
verifier while polling Kylon over HTTPS, receives the credential directly from
|
|
159
168
|
the API, and saves it in the versioned credential collection at
|