@kinlab/kin 0.5.45 → 0.5.47

package/README.md

@@ -21,6 +21,36 @@ No native Windows ARM64 archive is published. An x64 Node process under Windows
 emulation can provision the x86_64 archive; use WSL2 for the repository workflow
 documented below.
 
+## If the global install is refused
+
+On a machine whose global npm prefix is root-owned, and where you are not root and have no
+`sudo`, that first line fails before Kin runs:
+
+```
+npm error code EACCES
+npm error syscall mkdir
+npm error path /usr/local/lib/node_modules/@kinlab
+npm error Error: EACCES: permission denied, mkdir '/usr/local/lib/node_modules/@kinlab'
+```
+
+Containers whose default user is not root are the common case. Two ways out. The
+zero-install path above needs no writable prefix and is the shorter one. Or move the prefix
+somewhere you own, and put it on your `PATH`:
+
+```sh
+npm config set prefix ~/.npm-global
+export PATH="$HOME/.npm-global/bin:$PATH"   # add this to your shell profile too
+npm install -g @kinlab/kin
+```
+
+A user prefix is read by your interactive shell and by nothing else. Scripts, CI steps,
+`docker exec`, and agent clients do not inherit it, so register `kin` with those by its
+absolute path (`$(npm prefix -g)/bin/kin`, or `~/.kin/bin/kin` after `kin setup`) rather
+than by name. Installing as root does not fix that on an image where every user shares one
+`HOME`: root's npm reads the same `.npmrc`, reinstalls into the user prefix, and reports
+success. Pass `npm install -g --prefix /usr/local @kinlab/kin` when you want the system
+prefix.
+
 ## What it does
 
 `@kinlab/kin` ships two thin launchers, not a JavaScript reimplementation:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kinlab/kin",
-  "version": "0.5.45",
+  "version": "0.5.47",
   "description": "Canonical installer and launcher for Kin, the system of record for AI-written software. Provisions and runs the managed kin + kin-daemon release. MCP is one included mode (kin mcp start).",
   "license": "Apache-2.0",
   "type": "module",