@hydra-acp/cli 0.1.201 → 0.1.203

package/README.md

@@ -710,6 +710,16 @@ hydra-acp extension start hydra-acp-archiver
 
 See the [package README](https://github.com/smagnuso/hydra-acp-archiver#readme) for backend setup (Drive OAuth, filesystem path).
 
+**[`@hydra-acp/ahp`](https://github.com/smagnuso/hydra-ahp) — VS Code agent host.** Serves hydra sessions over the [Agent Host Protocol](https://github.com/microsoft/agent-host-protocol) so VS Code's agent UI can list, watch, and drive them. VS Code connects to it like any remote agent host, while every session stays live and shared with the TUI, browser, and Slack. Start a turn in the TUI and watch it stream in VS Code, or start a session in VS Code and pick it up later from the terminal. It listens on `127.0.0.1:55590` and mints its own token for VS Code, so hydra's tokens never leave the daemon.
+
+```sh
+npm install -g @hydra-acp/ahp
+hydra-acp extensions add hydra-ahp
+hydra-acp extensions start hydra-ahp
+```
+
+See the [package README](https://github.com/smagnuso/hydra-ahp#readme) for connecting VS Code and minting a token (`/hydra ahp token mint`).
+
 **[`@hydra-acp/planner`](https://github.com/smagnuso/hydra-acp-planner) — multi-agent project orchestrator.** Invoked via `/hydra planner create <description>` from any session: asks the host agent to decompose the project into a task DAG, then spawns N worker sessions and drives them in parallel by prompt management, with progress streaming back into your original chat. Boards persist under `~/.hydra-acp/planner/projects/<id>/` so plans survive daemon restarts. Strictly speaking it's a [transformer](#transformers), not an extension — it sits in the daemon's message pipeline rather than attaching as a client — but it installs and configures the same way.
 
 ```sh
@@ -890,21 +900,21 @@ Agents are sourced from the [ACP Registry](https://github.com/agentclientprotoco
 ## Architecture
 
 ```
-            editor         browser          Slack        ← clients
-              │               │               │
-          hydra-acp   hydra-acp-browser hydra-acp-slack  ← hydra extensions
-              │               │               │
-              └───────────────┼───────────────┘
+           VS Code         Chrome            Slack       ← clients
+              │               │                │
+          hydra-ahp   hydra-acp-browser  hydra-acp-slack ← hydra extensions
+              │               │                │
+              └───────────────┼────────────────┘
                               │
                           WSS / HTTP
                               │
                           hydra-acp                      ← hydra daemon
                               │
-                      T1 → T2 → … → Tn                  ← hydra transformers
+                      T1 → T2 → … → Tn                   ← hydra transformers
                               │
-              ┌───────────────┼───────────────┐
-              │               │               │
-            claude         opencode           pi         ← agents
+            ┌───────────┬─────┴─────┬───────────┐
+            │           │           │           │
+         claude     opencode       pi         codex      ← agents
 ```
 
 ### How it works
@@ -1013,6 +1023,7 @@ All three are documented in [`PROTOCOL.md`](PROTOCOL.md), with endpoint shapes,
 The daemon exposes a process-management surface. Treat the service token like an SSH key.
 
 - **Default bind is `127.0.0.1`.** Cross-host access requires TLS + a strong token.
+- **Remote access is opt-in via `hydra-acp daemon listen`.** `tailnet` binds the tailnet IP with a CA-signed cert, `all` binds every interface with a self-signed cert, and `local` goes back to loopback. The daemon refuses a non-loopback bind without TLS; see [Accepting remote clients](#accepting-remote-clients).
 - **No anonymous access.** Every request — REST and WSS — must present the bearer token.
 - **Token rotation:** `hydra-acp init --rotate-token` invalidates the old token; running clients are kicked.
 - **Sandboxing is the user's responsibility.** Spawned agents inherit the daemon's filesystem and shell. Run the daemon under a restricted user or inside a container if you don't trust agents fully.
@@ -1020,31 +1031,6 @@ The daemon exposes a process-management surface. Treat the service token like an
 
 The service token (stored at `~/.hydra-acp/auth-token`, mode 0600) is generated on `hydra-acp init` and required as `Authorization: Bearer <token>` for every REST call and as a WebSocket subprotocol or query parameter for `wss://.../acp`. The token never leaves `~/.hydra-acp/`.
 
-> **Windows:** mode 0600 is not enforcement there. Windows derives file access from ACLs, and Node's `chmod` only toggles the read-only bit, so `auth-token` (along with `config.json`, `peers.json`, `remotes.json`, and the session records) inherits whatever the parent directory grants. On a machine with more than one interactive user, restrict `%USERPROFILE%\.hydra-acp` yourself, e.g. `icacls "%USERPROFILE%\.hydra-acp" /inheritance:r /grant:r "%USERNAME%:(OI)(CI)F"`.
-
-For remote access (binding to a non-loopback address), enable TLS via:
-
-```json
-{
-  "daemon": {
-    "tls": {
-      "cert": "/path/to/cert.pem",
-      "key": "/path/to/key.pem"
-    }
-  }
-}
-```
-
-The daemon refuses to bind to non-loopback hosts without TLS configured.
-`hydra-acp daemon listen` writes all of this for you (see
-[Accepting remote clients](#accepting-remote-clients)). To do it by hand, a
-self-signed cert is enough, since `remote add`'s TOFU handshake only needs a
-key pair to pin, not a CA-signed one:
-
-```sh
-openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout key.pem -out cert.pem -subj "/CN=$(hostname)"
-```
-
 ## License
 
 MIT.