usebeeline 0.0.123 → 0.0.124

package/README.md

@@ -104,7 +104,7 @@ The corner receives a GitHub App token scoped to **that one repository**, instal
 - **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.
 - **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 route mounts on the agent's next session. Revoking it removes the route from the home.
+- **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.
 - **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.