@openape/nest 0.3.0 → 1.1.0

package/README.md

@@ -18,6 +18,45 @@ apes nest authorize    # set the YOLO policy — covers the inner
                        # `apes agents spawn` calls the daemon makes
 ```
 
+Set the bridge default model at install time so every spawn uses the
+same one without `--bridge-model` repetition:
+
+```bash
+apes nest install --bridge-model gpt-5.4    # ChatGPT-only LiteLLM proxy
+apes nest install --bridge-model claude-haiku-4-5  # Anthropic
+```
+
+This writes `APE_CHAT_BRIDGE_MODEL=<value>` to `~/litellm/.env`,
+which `resolveBridgeConfig()` reads at every `apes [nest|agents] spawn
+--bridge`. Re-run with a different value to overwrite.
+
+### Optional: privilege isolation with a dedicated service user
+
+By default, `apes nest install` configures the daemon as a user-domain
+`LaunchAgent` running under your own Mac user account, with state at
+`~/.openape/nest`. That works fine for personal use. For a more
+hardened setup the daemon can be promoted to a system-domain
+`LaunchDaemon` running under a dedicated `_openape_nest` macOS service
+user (uid 481, hidden, no shell, no GUI session) with state under
+`/var/openape/nest`.
+
+To migrate an existing user-domain install:
+
+```bash
+apes run --as root --wait -- bash apps/openape-nest/scripts/migrate-to-service-user.sh
+```
+
+The script creates the user/group, copies your data dir to
+`/var/openape/nest`, and swaps the plist. The Nest's IdP identity is
+bound to its ssh keypair (which moves with the data dir), so the same
+`nest-…@id.openape.ai` identity continues to work — no re-enroll
+needed, all existing approved delegations / grants stay valid.
+
+After migration you may want a fresh `apes login --key` for the Nest
+to refresh the access token (the migrated `auth.json` carries the
+old token; `cli-auth`'s challenge-response refresh handles it on
+expiry, but a manual login also works).
+
 After that, day-to-day lifecycle goes through `apes nest`:
 
 ```bash