usebeeline 0.0.125 → 0.0.128

package/README.md

@@ -65,12 +65,12 @@ Codex, Claude Code, Grok, and OpenCode use the sign-in they already have on that
 
 You can pass the pairing code inline — `npx usebeeline connect XXXXXXXX-XXXXXXXX` — and the package also installs a `beeline` bin alias.
 
-**Requirements:** Node 20.11+, Linux x64, and systemd user services. The published daemon bundle is `linux-x64` only today; macOS is not shipped.
+**Requirements:** Node 20.11+ and either Linux x64 with systemd user services or macOS (Apple silicon or Intel) with launchd. On macOS the helper is supervised in your login session: a LaunchAgent starts at login rather than at boot, so keep a user logged in — turn on automatic login for a headless Mac. Pairing over SSH with nobody logged in cannot start the daemon.
 
 ## What happens
 
 1. `connect` redeems the app's one-time pairing code and receives an agent identity for your Workspace.
-2. It downloads the signed current daemon bundle into `~/.local/lib/beeline` and starts it as a supervised `systemd --user` service, one per agent.
+2. It downloads the signed current daemon bundle into `~/.local/lib/beeline` and starts it as a supervised per-user service, one per agent (`systemd --user` on Linux, a launchd LaunchAgent on macOS).
 3. The agent appears in the Room. Tag it like a teammate.
 4. Given a repository-bound Room, the agent can open a corner and produce a pull request there.
 5. The daemon updates itself when a new release ships, draining any turn in flight first, and rolls back if the new bundle cannot answer.
@@ -84,6 +84,7 @@ A Room and a corner are the same conversation surface with different permissions
 **In a Room, the agent can:**
 
 - read the repository checkout, run searches, read git history — the filesystem is mounted **read-only**;
+- run shell commands inside that same sandbox (curl an endpoint, check `tailscale status`) — writable only in its own session state;
 - use every MCP tool mounted into its session, and web search where the harness has it (Codex and Claude Code get theirs turned on in the isolated home);
 - read files and photos people share (downloaded to the session for it — it never fetches a URL) and attach a file back to its reply;
 - address any other member, human or agent, by writing `@name`;
@@ -101,13 +102,13 @@ The corner receives a GitHub App token scoped to **that one repository**, instal
 
 ## Security posture
 
-- **The filesystem boundary is the sandbox, not a tool list.** Room sessions run under bubblewrap with a read-only view of the checkout, a private `/tmp`, and an isolated home. Every mounted MCP tool is approved tool-by-tool because the sandbox — not an allowlist — is what holds the line.
-- **When the sandbox cannot be built, the daemon says so and keeps serving.** A host with no `bwrap`, or a kernel that refuses unprivileged user namespaces, is logged once at start and every session afterwards runs unwrapped; the read-only rule then rests on the harness's own permission callback, which Codex, Claude Code, and Grok honour. Pi does not ask before it writes, so a Pi Room is only as read-only as its sandbox. OpenCode Rooms select its Plan agent; bubblewrap holds the filesystem boundary when available.
+- **The filesystem boundary is the sandbox, not a tool list.** Room sessions run under bubblewrap with a read-only view of the checkout, a private `/tmp`, and an isolated home. Every mounted MCP tool is approved, and so are shell commands while the sandbox wraps the session, because the sandbox — not an allowlist — is what holds the line for both.
+- **When the sandbox cannot be built, the daemon says so and keeps serving.** A host with no `bwrap` gets one automatic install attempt at daemon start (Linux hosts with `apt-get`; the unit's start deadline is extended to cover it, and a failed attempt is remembered for a day rather than retried on every restart). If the sandbox still cannot be built — a kernel that refuses unprivileged user namespaces, no usable package manager, or an operator who turned it off — every session afterwards runs unwrapped: mounted MCP tools stay approved, the agent's session prompt states whether it can run shell commands, and the read-only rule for anything else rests on the harness's own sandbox. Codex keeps its offline read-only mode; a harness that asks, like Claude Code or Grok, is told a shell is unavailable instead of being granted one. Pi does not ask before it writes, so a Pi Room is only as read-only as its sandbox. OpenCode Rooms select its Plan agent; bubblewrap holds the filesystem boundary when available.
 - **Write access requires a corner.** A corner is a separate worktree on its own branch with a repository-scoped GitHub App token, and it is opened by an explicit host-governed call, never inferred.
-- **Reach outside the sandbox is a grant.** The agent asks — `path`, `host`, `secret`, `device`, `budget`, `command`, or `mcp` — and a card goes to its owner in the Room with the exact ask and the reason. You approve once, always, or deny, and the decision is a line in the transcript. Approving a command grant is word-for-word: an approved `npm test` does not approve `npm test && curl …`, and a command carrying shell metacharacters is refused before it is ever offered. An `mcp` grant routes one MCP server the operator already runs on this host into the agent's isolated home — only that agent's owner can approve it, only for an agent that answers its owner alone (approving on an open agent narrows it to the owner first), and the approval wake cold-starts the next session with the route already mounted. An ALWAYS route remains available on later sessions until it is revoked.
-- **Yolo mode** flips a single agent to auto-approval and is settable only by that agent's owner. In a public Workspace, yolo is forced off without changing the owner's preference, so it resumes when the Workspace returns to invite-only; it never covers a budget or `mcp` grant.
+- **Reach outside the sandbox is a grant.** Repository cards stay in the requesting Room, where a Workspace owner or admin can answer. Personal-resource cards — host commands, paths, devices, secrets, wallets, apps, and other MCP routes — go to the resource owner's private connector or `@system` DM, and only that owner can answer. Every approval is scoped to the Room and the original human requester, so delegation or an approval resume cannot turn someone else's request into owner consent. Approving a command grant is word-for-word: an approved `npm test` does not approve `npm test && curl …`, and a command carrying shell metacharacters is refused before it is ever offered. An ALWAYS route remains available for the same scope until it is revoked; ONCE is consumed by the first authorized resource call, not by discovery.
+- **Yolo mode** flips a single agent to auto-approval and is settable only by that agent's owner. It bypasses repository prompts for any requester, but bypasses personal-resource prompts only when the original requester is the resource owner. In a public Workspace, yolo is forced off without changing the owner's preference, so it resumes when the Workspace returns to invite-only. Generic budget grants are retired.
 - **Provider keys never reach Beeline's servers.** They live in your config directory at mode `0600` and reach only the harness process you already trust with them.
-- **Honest about what is not built yet:** today `command` and `mcp` are the kinds that actually change what a running agent may do. `path`, `host`, `secret`, `device`, and `budget` grants are requested, decided, and recorded, but are not yet applied to the sandbox.
+- **Honest about what is not built yet:** `command` and `mcp` grants directly gate their corresponding operations. `path`, `secret`, and `device` grants are recorded but are not yet individual sandbox mounts; generic budget requests are rejected.
 
 ## Command reference
 
@@ -129,13 +130,30 @@ corners also mount the release-owned `codegraph` server after its local index is
 
 `beeline-readonly-mcp` — reading, in a Room and in a corner:
 
-| Tool                                            | What it does                                                                            |
-| ----------------------------------------------- | --------------------------------------------------------------------------------------- |
-| `list_files`, `read_file`                       | Walk and read the checkout                                                              |
-| `search_text`                                   | Search the checkout                                                                     |
-| `git_log`, `git_show`, `git_diff`, `git_status` | Read repository history and state                                                       |
-| `read_agent_file`                               | Read the agent's approved skills or Workspace memory                                    |
-| `write_memory`                                  | Replace the agent's private Workspace `MEMORY.md` — the only memory write a Room allows |
+| Tool                                            | What it does                                  |
+| ----------------------------------------------- | --------------------------------------------- |
+| `list_files`, `read_file`                       | Walk and read the checkout                    |
+| `search_text`                                   | Search the checkout                           |
+| `git_log`, `git_show`, `git_diff`, `git_status` | Read repository history and state             |
+| `read_agent_file`                               | Read the agent's approved materialized skills |
+
+The retired private per-agent `MEMORY.md` and `write_memory` tool are not part of the live
+Room/corner runtime. Institutional memory is ON by default on server and Body: host-side review
+records sourced Workspace facts and requester-profile preferences. Each turn receives one
+relevance-selected, command-bound snapshot capped at 8,000 UTF-8 bytes; failures omit the optional
+block. `propose_memory_item` is the active-command-bound write path.
+`BEELINE_INSTITUTIONAL_MEMORY_ENABLED=false` turns live memory off and
+`BEELINE_INSTITUTIONAL_MEMORY_SHADOW_ENABLED=false` turns the measurement-only mode off (set both
+to stop the feature entirely). `search_history` intersects every result with the requester,
+answering agent, and complete output audience. A merged corner can produce a bounded,
+code-anchored Workspace procedure; turns see only its relevance-ranked catalog entry, and
+`load_workspace_skill` returns the procedure as quoted, non-authoritative guidance with measured
+use. Generated procedures are never installed as native harness skills. Every Workspace is
+enrolled at the `live` stage by default; the release migration advances existing `shadow`/`pilot`
+rows to `live` and enrolls Workspaces that have no row, so `stage` is only an off switch (`paused`
+stops the curator without unstaging, `off` removes the Workspace from every lane). The server's
+idempotent weekly curator ages and retains items, queues audience-partitioned consolidation on
+authorized user hosts, and honors Workspace job/token budgets.
 
 `codegraph` — indexed code relationships in repository-backed Rooms and corners:
 
@@ -155,8 +173,11 @@ Rooms run CodeGraph without a file watcher and keep source files read-only; only
 | `post_artifact`                                        | Everywhere      | Upload one file (path or html/bytes) as an attachment         |
 | `fetch_image`                                          | Everywhere      | Download one photograph into scratch for a data: embed        |
 | `create_schedule`, `list_schedules`, `delete_schedule` | Everywhere      | Run a prompt again later — interval minutes or a 5-field cron |
-| `request_grant`                                        | Everywhere      | Ask the owner for reach outside the sandbox                   |
+| `request_grant`                                        | Everywhere      | Ask the correct Room manager or resource owner for access     |
 | `run_granted_command`                                  | Everywhere      | Run a command an approved grant covers, outside the sandbox   |
+| `propose_memory_item`                                  | Live memory     | Propose one sourced fact or requester working preference      |
+| `search_history`                                       | Live memory     | Search history visible to the full output audience            |
+| `load_workspace_skill`                                 | Live memory     | Load one restricted merge-derived Workspace procedure         |
 
 ## The app
 
@@ -169,7 +190,7 @@ Sign in with GitHub, and the app hands you the pairing code that `npx usebeeline
 
 ## Beta
 
-Beeline is `0.0.x` and moves fast. Concretely, today: the daemon bundle ships for Linux x64 only; corners assume a GitHub repository the app can reach; five sandbox grant kinds are recorded but not yet enforced; and releases are cut by hand rather than on every merge. The pieces described above are the ones that work.
+Beeline is `0.0.x` and moves fast. Concretely, today: the daemon bundle ships for Linux x64 and macOS, not Windows; corners assume a GitHub repository the app can reach; five sandbox grant kinds are recorded but not yet enforced; and releases are cut by hand rather than on every merge. The pieces described above are the ones that work.
 
 ## One README for GitHub and npm