@bivy/bivy 0.20.9-staging.7 → 0.20.9-staging.8

package/README.md

@@ -285,10 +285,9 @@ Every session gets the `bivy` CLI, so any agent with a shell can talk back
 through the app, not only agents with their own built-in tools:
 
 ```bash
-bivy notify "Tests are green, PR is up"     # chat card + phone push when you're away
+bivy notify                                 # push to your phone so you come back
 bivy ask "Ship to staging?" --option Yes --option No  # waits for your answer
 bivy attach report.png --caption "Before/after"       # show a file in the chat
-bivy suggest "Add a dark theme to settings"           # a next task you start in one tap
 bivy context --json                                   # session, workspace, machine, apps
 ```
 

package/bin/bivy.mjs

@@ -2595,38 +2595,6 @@ async function cmdContext(args = []) {
   console.log(`\nEverything else: ${c.cyan("bivy help")} (or ${c.cyan("bivy help --json")}).`);
 }
 
-// `bivy suggest "<task>" [--title "…"] [--run here|subagents|new] [--session <id>]`
-// — propose a task the user can start in one tap, in this session or beside it. For an agent
-// offering next steps: write the task as a complete instruction.
-async function cmdSuggest(args = []) {
-  const usage = 'Usage: bivy suggest "<task>" [--title "short label"] [--run here|subagents|new] [--session <id>] [--json]';
-  if (args.includes("-h") || args.includes("--help")) {
-    console.log(`${usage}\n\nPost a task the user can start in one tap: in this session, through your sub-agents, or in a parallel session that works in its own copy of the project. Write it as a complete instruction, with paths relative to the project root.\n\n--run says where you recommend running it, which becomes the card's main button: here (builds on this conversation), subagents (independent tasks you can split across your own sub-agents; only if you have them), or new (bigger independent work the user will want to follow in its own session). Without it, one card recommends here and several recommend new.\n\n--json prints {"ok","id"}.`);
-    return;
-  }
-  const json = wantsJson(args);
-  const fail = (error) => cliError(error, { json, paint: c.red });
-  const flagsWithValue = new Set(["--session", "--title", "--run"]);
-  const flag = (name) => {
-    const i = args.indexOf(name);
-    return i >= 0 && i + 1 < args.length ? args[i + 1] : undefined;
-  };
-  const text = args.filter((a, i) => !a.startsWith("-") && !(i > 0 && flagsWithValue.has(args[i - 1]))).join(" ").trim();
-  const sessionId = resolveAttachSessionId({ sessionFlag: flag("--session"), env: process.env });
-  if (!text) return fail({ code: "usage", message: usage, exit: EXIT.usage });
-  const run = flag("--run");
-  if (run !== undefined && !["here", "subagents", "new"].includes(run)) return fail({ code: "usage", message: `--run is here, subagents or new (got "${run}").`, exit: EXIT.usage });
-  if (!sessionId) return fail({ code: "no_session", message: "No session id.", hint: "Run inside an agent session ($BIVY_SESSION_ID) or pass --session <id>.", next: "bivy sessions --json", exit: EXIT.usage });
-  const config = loadConfig();
-  if (!(await ensureNodeRunning(config))) return fail({ code: "node_unreachable", message: `Could not reach the Bivy node at ${url(config)}.`, next: "bivy status", exit: EXIT.unavailable });
-  const res = await sessionPost(config, sessionId, "suggest", { text, title: flag("--title"), run }).catch((error) => error);
-  if (res instanceof Error) return fail({ code: "node_unreachable", message: `Could not reach the Bivy node: ${res.message}`, next: "bivy status", exit: EXIT.unavailable });
-  const body = await res.json().catch(() => ({}));
-  if (!res.ok) return fail(sessionHttpError("Suggest", res.status, body));
-  if (json) { console.log(JSON.stringify(body)); return; }
-  console.log(c.green("Suggested in the chat. The user can start it in one tap."));
-}
-
 // `bivy title "<title>" [--session <id>]` — rename the session the agent runs in.
 async function cmdTitle(args = []) {
   const usage = 'Usage: bivy title "<title>" [--session <id>] [--json]';
@@ -2674,45 +2642,37 @@ function durationSeconds(text) {
   return m ? Number(m[1]) * (m[2] === "h" ? 3600 : m[2] === "m" ? 60 : 1) : NaN;
 }
 
-// `bivy notify "<message>" [--urgent]` — reach the user: a card in the chat,
-// and a push naming the session (never the text) when nobody has the app open.
+// `bivy notify [--urgent]` — bring the user back: a push naming the session
+// (never any text) when nobody has the app open. Nothing is posted in the chat.
 async function cmdNotify(args = []) {
-  const usage = 'Usage: bivy notify "<message>" [--urgent] [--session <id>] [--json]';
+  const usage = "Usage: bivy notify [--urgent] [--session <id>] [--json]";
   if (args.includes("-h") || args.includes("--help")) {
     console.log(`${usage}
 
-Send the user a message: it appears as a card in the chat, and their devices get
-a push notification (naming this session, not the text) when nobody has the app
-open. --urgent pushes even while they do. At most one push a minute per session;
-later messages still reach the chat. Use it when you finish long work, get
-blocked, or need the user to look at something. --json prints
-{"ok","id","push":"sent"|"user_watching"|"rate_limited","userWatching"}.`);
+Push to the user's devices so they come back to this session. The push names the
+session, nothing else, and nothing is posted in the chat: say what you need in
+your reply. It is sent only when nobody has the app open; --urgent pushes even
+while they do. At most one push a minute per session. You don't need it when you
+finish: Bivy already pushes when a turn ends while the user is away. --json prints
+{"ok","push":"sent"|"user_watching"|"rate_limited"|"unavailable","userWatching"}.`);
     return;
   }
   const json = wantsJson(args);
   const fail = (error) => cliError(error, { json, paint: c.red });
   const parsed = parseSessionArgs(args, ["--session"]);
   if (parsed.error) return fail({ code: "usage", message: parsed.error, exit: EXIT.usage });
-  const text = parsed.positional.join(" ").trim();
-  if (!text) return fail({ code: "usage", message: usage, exit: EXIT.usage });
   const sessionId = resolveAttachSessionId({ sessionFlag: parsed.one("--session"), env: process.env });
   if (!sessionId) return fail({ code: "no_session", message: "No session id.", hint: "Run inside an agent session ($BIVY_SESSION_ID) or pass --session <id>.", next: "bivy sessions --json", exit: EXIT.usage });
   const config = loadConfig();
   if (!(await ensureNodeRunning(config))) return fail({ code: "node_unreachable", message: `Could not reach the Bivy node at ${url(config)}.`, next: "bivy status", exit: EXIT.unavailable });
-  const res = await sessionPost(config, sessionId, "notify", { text, urgent: parsed.has("--urgent") }).catch((error) => error);
+  const res = await sessionPost(config, sessionId, "notify", { urgent: parsed.has("--urgent") }).catch((error) => error);
   if (res instanceof Error) return fail({ code: "node_unreachable", message: `Could not reach the Bivy node: ${res.message}`, next: "bivy status", exit: EXIT.unavailable });
   const body = await res.json().catch(() => ({}));
   if (!res.ok) return fail(sessionHttpError("Notify", res.status, body));
   if (json) { console.log(JSON.stringify(body)); return; }
-  const noPush = { user_watching: "the user has the app open; add --urgent to push anyway", rate_limited: "this session pushed less than a minute ago", unavailable: "this machine isn't signed in to a Bivy account" }[body.push];
-  // A terminal run (`bivy run`) has no chat to hold a card: the push is the notice.
-  if (body.posted === false) {
-    if (body.push === "sent") console.log(c.green("Pushed to the user's devices."));
-    else console.log(c.yellow(`Not delivered: a terminal run has no chat to post in, and no push was sent (${noPush ?? body.push}).`));
-    return;
-  }
-  const pushed = body.push === "sent" ? "and pushed to the user's devices" : noPush ? `(no push: ${noPush})` : "";
-  console.log(c.green(`Posted in the chat ${pushed}.`.replace(" .", ".")));
+  if (body.push === "sent") { console.log(c.green("Pushed to the user's devices.")); return; }
+  const noPush = { user_watching: "the user has the app open, so they see your reply; add --urgent to push anyway", rate_limited: "this session pushed less than a minute ago", unavailable: "this machine isn't signed in to a Bivy account" }[body.push];
+  console.log(c.yellow(`No push sent: ${noPush ?? body.push}.`));
 }
 
 // `bivy ask "<question>" [--option …]` — the question card, for any agent.
@@ -6515,9 +6475,6 @@ An agent's own --help passes through, e.g. 'bivy run claude --help'.`);
     case "attach":
       await cmdAttach(args);
       break;
-    case "suggest":
-      await cmdSuggest(args);
-      break;
     case "title":
       await cmdTitle(args);
       break;

package/bin/cli-commands.mjs

@@ -44,14 +44,12 @@ export const COMMANDS = [
   { name: "context", group: "session", scope: "session", json: true, usage: "context [--json]", summary: "Where this agent is running: session, workspace, machine, apps, and what to run next",
     tools: [{ name: "bivy_context", description: "Where you are running inside Bivy: your session, agent, workspace and git branch, the machine, apps you have published, whether the user has the app open, and the commands that reach them.", input: {}, argv: ["context"] }] },
   { name: "attach", group: "session", scope: "session", json: true, usage: 'attach <file> [--caption "…"] [--artifact]', summary: "Show a local file or image to the user in the chat" },
-  { name: "notify", group: "session", scope: "session", json: true, usage: 'notify "<message>" [--urgent]', summary: "Message the user: a card in the chat, and a push when they're away",
-    tools: [{ name: "notify_user", description: "Send the user a message: a card in the chat, and a push to their phone when nobody has the app open (the push names the session, not the text). Use it when long work finishes, you are blocked, or something needs their attention. At most one push a minute per session.", input: { message: { type: "string", description: "What to tell the user.", required: true }, urgent: { type: "boolean", description: "Push even while the user has the app open." } }, argv: ["notify", { arg: "message" }, { when: "urgent", flag: "--urgent" }] }] },
+  { name: "notify", group: "session", scope: "session", json: true, usage: "notify [--urgent]", summary: "Push to the user's phone so they come back (nothing posted in the chat)",
+    tools: [{ name: "notify_user", description: "Push to the user's phone so they come back to this session, e.g. when you are blocked on them while still working. The push names the session only and nothing is posted in the chat, so say what you need in your reply. Not needed when you finish: Bivy already pushes when a turn ends while they are away. Sent only when nobody has the app open, at most one a minute per session.", input: { urgent: { type: "boolean", description: "Push even while the user has the app open." } }, argv: ["notify", { when: "urgent", flag: "--urgent" }] }] },
   { name: "ask", group: "session", scope: "session", json: true, usage: 'ask "<question>" [--option A --option B] [--async]', summary: "Ask the user a question and wait for the answer", subcommands: ["status", "wait"],
     tools: [{ name: "ask_user", description: "Ask the user a question in the chat and wait for their answer (their phone gets a push). Offer 2-8 options, or none for a free-text answer; they can always write their own. Returns {status, answer}: status is answered, dismissed (decide yourself) or expired.", input: { question: { type: "string", description: "The question.", required: true }, options: { type: "array", items: { type: "string" }, description: "Choices to pick from (2-8)." }, multiple: { type: "boolean", description: "Allow several choices." }, header: { type: "string", description: "A short label for the card." }, timeout_seconds: { type: "number", description: "How long to wait (default 600)." } }, argv: ["ask", { arg: "question" }, { flag: "--option", from: "options" }, { when: "multiple", flag: "--multi" }, { flag: "--header", from: "header" }, { flag: "--timeout", from: "timeout_seconds" }] }] },
   { name: "title", group: "session", scope: "session", json: true, usage: 'title "<title>"', summary: "Rename this session",
     tools: [{ name: "set_session_title", description: "Rename this session in the user's session list. Use a short title (under 60 characters) that says what the work is, when the first message made a poor title or the work changed direction.", input: { title: { type: "string", description: "The new title.", required: true } }, argv: ["title", { arg: "title" }] }] },
-  { name: "suggest", group: "session", scope: "session", json: true, usage: 'suggest "<task>" [--title "label"] [--run here|subagents|new]', summary: "Propose a task the user can start in one tap",
-    tools: [{ name: "suggest_task", description: "Propose a next step the user can start in one tap: in this session, through your sub-agents, or in a parallel session with its own copy of the project. Write the task as a complete instruction with paths relative to the project root. Post one per idea instead of listing them.", input: { task: { type: "string", description: "The complete instruction.", required: true }, title: { type: "string", description: "A short label for the card." }, run: { type: "string", enum: ["here", "subagents", "new"], description: "Where you recommend running it: here (builds on this conversation), subagents (independent tasks you can split across your own sub-agents; only if you have them), or new (bigger independent work in its own session). Defaults: here for one card, new for several." } }, argv: ["suggest", { arg: "task" }, { flag: "--title", from: "title" }, { flag: "--run", from: "run" }] }] },
   { name: "app", group: "session", scope: "session", json: true, usage: "app <publish|shot|present|share|run|…>", summary: "Live previews: publish a web/terminal/desktop app, screenshot it, present it", subcommands: ["publish", "list", "remove", "shot", "present", "share", "notes", "run", "click", "type", "key", "scroll", "drag", "move", "menu"],
     tools: [
       { name: "app_publish", description: "Give the user a live preview of something with a UI, from an app manifest file (web server port, static build, terminal, or desktop app). Run `bivy app --help` for the manifest format.", input: { manifest_path: { type: "string", description: "Path to the manifest JSON.", required: true } }, argv: ["app", "publish", { arg: "manifest_path" }] },

package/bin/guides/talk-to-the-user.md

@@ -1,18 +1,24 @@
 # Talk to the user
 
-Summary: When to answer in chat, when to notify, when to ask and wait, and how to offer next steps.
+Summary: When to answer in chat, when to notify, and when to ask and wait.
 
 Your chat reply is the default. Reach for these when the chat alone won't do.
 
 ## They may be away: notify
 
-    bivy notify "Migration finished: 3 tables rewritten, all tests pass."
-    bivy notify --urgent "Production is serving the old build."
+    bivy notify
+    bivy notify --urgent
 
-Posts a card in the chat. When nobody has the app open, their devices get a push
-naming this session (the text stays in the chat). `--urgent` pushes even while
-they are looking. One push a minute per session; don't send one per step.
-Good moments: long work finished, you are blocked, something needs a look.
+Pushes to their devices so they come back to this session. The push names the
+session only and nothing is posted in the chat, so say what you need in your
+reply. It goes out only when nobody has the app open; `--urgent` pushes even
+while they are looking. One push a minute per session.
+
+You don't need it when you finish: Bivy already pushes when a turn ends while
+they are away. Use it while you keep working and need them, for example when a
+long run is blocked on something only they can do.
+
+Next steps and options go in your reply as plain text.
 
 ## You need a decision: ask
 
@@ -24,23 +30,6 @@ dismissed it (use your judgment), exit 5 that `--timeout` (default 10m) passed.
 For long waits use `--async`, keep working, and later `bivy ask wait <id>`.
 Ask only when you can't reasonably decide yourself.
 
-## Offer next steps: suggest
-
-    bivy suggest "Add a GET /version endpoint that returns the package version." --title "Add /version"
-
-Each suggestion is a card the user can start in one tap: here, through your
-sub-agents, or in a parallel session with its own copy of the project. Write it as
-a complete instruction with paths relative to the project root. Post one per idea
-instead of a bulleted list.
-
-`--run` picks the card's main button; the others stay one tap away:
-
-| `--run` | When |
-|---|---|
-| `here` | It builds on this conversation, or it's small. Default for a single card. |
-| `subagents` | Independent tasks you can split across your own sub-agents and report back on. Only if you have sub-agents. |
-| `new` | Bigger independent work the user will want to follow, review or merge on its own. Default for several cards. |
-
 ## Name the session: title
 
     bivy title "Fix login redirect loop"

package/dist/agent-instructions.js

@@ -39,18 +39,12 @@ export const BIVY_AGENT_NOTE = [
         "can check your work; `bivy app present` tells the user a visible change is ready to look at, and " +
         "`.bivy/scenarios/*.json` files let them open it in the states that matter (errors, empty, slow) with `--try`. " +
         "`bivy app --help` has the details.",
-    "- Proposing tasks the user could hand you (next steps, ideas, options): post each with " +
-        '`bivy suggest "<complete instruction>" [--title "short label"] [--run here|subagents|new]` instead of only ' +
-        "listing them. The user can start each in one tap, in this session, through your sub-agents, or in a parallel " +
-        "one that works in its own copy of the project, so write it to stand on its own, with paths relative to the " +
-        "project root. `--run` is the one you recommend: here when it builds on this conversation, subagents for " +
-        "independent tasks you can split and supervise (only if you have sub-agents), new for bigger work worth its " +
-        "own session.",
     '- If this session\'s title (taken from the first message) doesn\'t say what the work is, or the work changes ' +
         'direction: `bivy title "<short title>"`.',
-    "- When you finish long work, get blocked, or need the user to look at something: " +
-        '`bivy notify "<message>"` (a chat card, plus a push to their phone when they are away). To ask and wait for ' +
-        'an answer: `bivy ask "<question>" [--option A --option B]` prints their answer (or use your own ask-the-user tool).',
+    "- Your chat reply is what the user reads; when you finish while they are away, Bivy pushes to their phone for you. " +
+        'To bring them back while you keep working: `bivy notify` (a push only; say what you need in the chat). To ask ' +
+        'and wait for an answer: `bivy ask "<question>" [--option A --option B]` prints their answer (or use your own ' +
+        "ask-the-user tool).",
     "- Only when the user asks for another agent or another of their machines to take part: " +
         '`bivy delegate "<self-contained task>" --agent <id> [--machine <name>] --wait` runs it there and prints ' +
         "its answer and any branch/PR; `--to codex,grok@<machine>` asks several to compare, `bivy delegate machines` " +

package/dist/apps/styles.css

@@ -3241,24 +3241,9 @@ p.setup-note .btn.link { min-height: 44px; margin-block: calc((1lh - 44px) / 2);
 .app-row-meta { color: var(--muted); font-size: var(--text-xs); line-height: var(--lh-xs); }
 .app-row-action { flex: none; display: flex; align-items: center; gap: var(--space-1); }
 .app-message { margin-block: var(--space-2); }
-/* Suggested task (SuggestionCard.tsx): a task the agent proposed, one tap to
-   start in its own session. Shell from .card; layout only here. */
-.suggestion-card { max-inline-size: 440px; display: flex; flex-direction: column; gap: var(--space-1); }
 /* The small label above a chat card's content, shared by every agent-posted card. */
-.suggestion-eyebrow, .delegation-eyebrow, .notice-eyebrow { margin: 0; color: var(--muted); font-size: var(--text-xs); font-weight: var(--weight-semibold); }
-.suggestion-title { margin: 0; font-size: var(--text-base); font-weight: var(--weight-semibold); overflow-wrap: anywhere; }
-.suggestion-text { margin: 0; color: var(--muted); font-size: var(--text-sm); white-space: pre-wrap; overflow-wrap: anywhere; display: -webkit-box; -webkit-line-clamp: 4; -webkit-box-orient: vertical; overflow: hidden; }
-.suggestion-text[data-expanded="true"] { display: block; overflow: visible; }
-.suggestion-actions { display: flex; flex-wrap: wrap; gap: var(--space-2); margin-top: var(--space-2); }
-.suggestion-bar, .suggestion-all { display: flex; flex-direction: column; gap: var(--space-1); margin-top: var(--space-2); }
-.suggestion-all { padding-top: var(--space-2); border-top: 1px solid var(--line); }
-.suggestion-bar .suggestion-actions, .suggestion-all .suggestion-actions { margin-top: 0; }
-.suggestion-hint { margin: 0; color: var(--muted); font-size: var(--text-xs); }
-/* In a set, the title is the checkbox's label, so the whole line is the tap target. */
-.suggestion-pick { display: flex; align-items: flex-start; gap: var(--space-2); cursor: pointer; }
-.suggestion-pick input { flex: none; inline-size: 18px; block-size: 18px; margin: 2px 0 0; accent-color: var(--accent); }
-.suggestion-status { margin: var(--space-2) 0 0; display: flex; align-items: center; gap: var(--space-2); color: var(--ok); font-size: var(--text-sm); font-weight: var(--weight-medium); }
-/* Notice (NoticeCard.tsx): a message the agent sent with `bivy notify`.
+.delegation-eyebrow, .notice-eyebrow { margin: 0; color: var(--muted); font-size: var(--text-xs); font-weight: var(--weight-semibold); }
+/* Notice (NoticeCard.tsx): a message from Bivy, e.g. applied automations.
    Shell and tone from .card, the urgent marker from .badge. */
 .notice-card { max-inline-size: 440px; display: flex; flex-direction: column; gap: var(--space-1); }
 .notice-eyebrow { display: flex; align-items: center; gap: var(--space-2); }

package/dist/server.js

@@ -80,7 +80,6 @@ import { exportProviderAuth, exportAccountApiKeys, exportAccountOAuthCredentials
 import { listProviders } from "./runtime/provider-catalog.js";
 import { exportLocalModels, importLocalModels } from "./runtime/local-model-store.js";
 import { sessionLikeFields } from "./session/start-like.js";
-import { MAX_SUGGESTION_TEXT, MAX_SUGGESTION_TITLE, SUGGESTION_RUNS, isTaskSuggestion } from "./session/suggestions.js";
 import { BIVY_AGENT_NOTE, mergeSyncedAgentInstructions, readAgentInstructions, sessionInstructions, writeAgentInstructions, MAX_AGENT_INSTRUCTIONS_BYTES } from "./agent-instructions.js";
 import { execEphemeralRequest } from "./ephemeral-exec.js";
 import { ApprovalManager } from "./approval.js";
@@ -143,7 +142,7 @@ import { AgentQuestions, askQuestionsFrom } from "./session/agent-questions.js";
 import { AutomationProposals, describeChange } from "./session/automation-proposals.js";
 import { createSessionTokenCodec, isSessionToken, sessionTokenAllows } from "./session/session-tokens.js";
 import { setSessionTokenSigner } from "./runtime/session-env.js";
-import { MAX_NOTICE_TEXT, isAgentNotice, noticePush } from "./session/notices.js";
+import { MAX_NOTICE_TEXT, noticePush } from "./session/notices.js";
 import { createForkCommands } from "./controllers/fork-commands.js";
 import { createGithubCommands } from "./controllers/github-commands.js";
 import { createCredentialCommands } from "./controllers/credential-commands.js";
@@ -11742,10 +11741,9 @@ app.get("/api/session/:id/context", (req, res) => {
         previewAvailable,
     }));
 });
-// `bivy notify "<message>"`: a card in the chat, and a push naming the session
-// (never the text) when nobody has the app open, or when it's urgent. At most
-// one push a minute per session; later notices still post a card. A `bivy run`
-// terminal has no chat to hold the card, so its notice is the push alone.
+// `bivy notify`: a push naming the session (never any text) when nobody has the
+// app open, or when it's urgent. At most one push a minute per session. It adds
+// nothing to the chat: what the agent has to say belongs in its reply there.
 const lastNotifyPush = new Map();
 app.post("/api/session/:id/notify", (req, res) => {
     const record = openSessions.get(String(req.params.id));
@@ -11753,16 +11751,9 @@ app.post("/api/session/:id/notify", (req, res) => {
     const sessionId = record?.id ?? run?.sessionId;
     if (!sessionId)
         return res.status(404).json({ error: "Session not found" });
-    const text = typeof req.body?.text === "string" ? req.body.text.trim() : "";
-    const notice = { id: `notice-${randomBytes(8).toString("hex")}`, text, ...(req.body?.urgent === true ? { urgent: true } : {}) };
-    if (!isAgentNotice(notice))
-        return res.status(400).json({ error: `A notice needs text (up to ${MAX_NOTICE_TEXT} characters).` });
-    if (record) {
-        eventLog.appendNotice(record.id, { afterMessageCount: record.session.getMessages().length, notice });
-        broadcast(stampSessionEvent({ type: "session.event", sessionId: record.id, event: { type: "notice", id: notice.id, notice } }));
-    }
+    const urgent = req.body?.urgent === true;
     const watching = Boolean(record) && (clients.size > 0 || (relay?.clientCount ?? 0) > 0);
-    const push = noticePush({ urgent: notice.urgent, userWatching: watching, lastPushAt: lastNotifyPush.get(sessionId), now: Date.now(), pushConfigured: Boolean(sessionAdvertiseTarget) });
+    const push = noticePush({ urgent, userWatching: watching, lastPushAt: lastNotifyPush.get(sessionId), now: Date.now(), pushConfigured: Boolean(sessionAdvertiseTarget) });
     if (push === "sent") {
         lastNotifyPush.set(sessionId, Date.now());
         void sendNotificationHint({
@@ -11770,10 +11761,10 @@ app.post("/api/session/:id/notify", (req, res) => {
             sessionId,
             targetSessionId: sessionId,
             title: sessionNotifyLabel(record, run?.name || "A terminal session"),
-            body: "Has a message for you — tap to read it.",
+            body: "Wants you to take a look — tap to open the session.",
         });
     }
-    res.json({ ok: true, id: notice.id, posted: Boolean(record), push, userWatching: watching });
+    res.json({ ok: true, push, userWatching: watching });
 });
 // `bivy ask`: the question card and "needs your input" push, for any agent.
 // Returns at once with an id; `/wait` blocks up to 240s per call (under common
@@ -11831,23 +11822,6 @@ app.post("/api/session/:id/title", (req, res) => {
     sessionNamer.setSessionName(record, title);
     res.json({ ok: true, title });
 });
-// `bivy suggest "<task>"`: the agent proposes a task the user can start in one
-// tap, here, through this agent's sub-agents, or in a parallel session; `run`
-// is the one the agent recommends (see packages/web SuggestionCard).
-app.post("/api/session/:id/suggest", (req, res) => {
-    const record = openSessions.get(String(req.params.id));
-    if (!record)
-        return res.status(404).json({ error: "Session not found" });
-    const text = typeof req.body?.text === "string" ? req.body.text.trim() : "";
-    const title = typeof req.body?.title === "string" && req.body.title.trim() ? req.body.title.trim() : undefined;
-    const run = req.body?.run || undefined;
-    const suggestion = { id: `suggestion-${randomBytes(8).toString("hex")}`, text, ...(title ? { title } : {}), ...(run ? { run } : {}) };
-    if (!isTaskSuggestion(suggestion))
-        return res.status(400).json({ error: `A suggestion needs text (up to ${MAX_SUGGESTION_TEXT} characters), an optional title (up to ${MAX_SUGGESTION_TITLE}) and an optional run (${SUGGESTION_RUNS.join(", ")}).` });
-    eventLog.appendSuggestion(record.id, { afterMessageCount: record.session.getMessages().length, suggestion });
-    broadcast(stampSessionEvent({ type: "session.event", sessionId: record.id, event: { type: "suggestion", id: suggestion.id, suggestion } }));
-    res.json({ ok: true, id: suggestion.id });
-});
 // Explicit child Run API for first-party/user-directed workflows. These routes
 // are intentionally not advertised to agents as tools; the service still
 // authorizes every status lookup against this parent Session's provenance.

package/dist/session/event-log.js

@@ -31,7 +31,6 @@ import path from "node:path";
 import { normalizedIntermediateText, thinkingTextFromContent, mergeTranscript } from "./transcript-merge.js";
 import { DELEGATION_BLOCK, isDelegationCard } from "./delegations.js";
 import { APP_PIN_BLOCK, APP_PUBLICATION_BLOCK, APP_REVIEW_BLOCK, isAppPin, isAppReference, isAppReview } from "../apps/types.js";
-import { SUGGESTION_BLOCK, isTaskSuggestion } from "./suggestions.js";
 import { NOTICE_BLOCK, isAgentNotice } from "./notices.js";
 /**
  * Decompose a transcript message into serialization-independent "atoms": the
@@ -333,12 +332,6 @@ function isAppPublication(value) {
     const entry = value;
     return entry.bivyKind === "app-publication" && typeof entry.id === "string" && typeof entry.createdAt === "number" && typeof entry.afterMessageCount === "number" && isAppReference(entry.app);
 }
-function isSuggestionEntry(value) {
-    if (!value || typeof value !== "object")
-        return false;
-    const entry = value;
-    return entry.bivyKind === "suggestion" && typeof entry.id === "string" && typeof entry.createdAt === "number" && typeof entry.afterMessageCount === "number" && isTaskSuggestion(entry.suggestion);
-}
 function isNoticeEntry(value) {
     if (!value || typeof value !== "object")
         return false;
@@ -364,7 +357,7 @@ function isAppPinEntry(value) {
     return entry.bivyKind === "app-pin" && typeof entry.id === "string" && typeof entry.createdAt === "number" && typeof entry.afterMessageCount === "number" && isAppPin(entry.pin);
 }
 function isRecord(value) {
-    return isDelegationEntry(value) || isOverlay(value) || isBase(value) || isForkDisplay(value) || isAttachment(value) || isOutboundAttachment(value) || isInlineImage(value) || isAppPublication(value) || isAppReviewEntry(value) || isAppPinEntry(value) || isSuggestionEntry(value) || isNoticeEntry(value);
+    return isDelegationEntry(value) || isOverlay(value) || isBase(value) || isForkDisplay(value) || isAttachment(value) || isOutboundAttachment(value) || isInlineImage(value) || isAppPublication(value) || isAppReviewEntry(value) || isAppPinEntry(value) || isNoticeEntry(value);
 }
 /**
  * Fold attachment records into a text→refs list: last write wins per text (a
@@ -507,15 +500,11 @@ export function replayExtras(entries) {
         role: "assistant", content: [{ type: DELEGATION_BLOCK, delegation: entry.delegation }],
         id: `delegation-${entry.id}`, afterMessageCount: entry.afterMessageCount, createdAt: entry.createdAt,
     }));
-    const suggestions = entries.filter((entry) => entry.bivyKind === "suggestion").map((entry) => ({
-        role: "assistant", content: [{ type: SUGGESTION_BLOCK, suggestion: entry.suggestion }],
-        id: entry.id, afterMessageCount: entry.afterMessageCount, createdAt: entry.createdAt,
-    }));
     const notices = entries.filter((entry) => entry.bivyKind === "notice").map((entry) => ({
         role: "assistant", content: [{ type: NOTICE_BLOCK, notice: entry.notice }],
         id: entry.id, afterMessageCount: entry.afterMessageCount, createdAt: entry.createdAt,
     }));
-    return [...foldIntermediate(intermediate), ...foldTool(tool), ...replayOutboundAttachments(entries), ...publications, ...cards, ...pinCards, ...delegationCards, ...suggestions, ...notices];
+    return [...foldIntermediate(intermediate), ...foldTool(tool), ...replayOutboundAttachments(entries), ...publications, ...cards, ...pinCards, ...delegationCards, ...notices];
 }
 /**
  * Fold the outbound (agent-sent) attachment records into time-anchored synthetic
@@ -832,10 +821,6 @@ export class EventLog {
         this.load(id);
         this.enqueue(id, `pin:${entry.pin.id}`, { bivyKind: "app-pin", createdAt: entry.createdAt ?? Date.now(), afterMessageCount: entry.afterMessageCount, id: entry.pin.id, pin: structuredClone(entry.pin) });
     }
-    appendSuggestion(id, entry) {
-        this.load(id);
-        this.enqueue(id, `suggestion:${entry.suggestion.id}`, { bivyKind: "suggestion", createdAt: Date.now(), afterMessageCount: entry.afterMessageCount, id: entry.suggestion.id, suggestion: { ...entry.suggestion } });
-    }
     appendNotice(id, entry) {
         this.load(id);
         this.enqueue(id, `notice:${entry.notice.id}`, { bivyKind: "notice", createdAt: Date.now(), afterMessageCount: entry.afterMessageCount, id: entry.notice.id, notice: { ...entry.notice } });

package/dist/session/session-tokens.js

@@ -44,7 +44,7 @@ export function createSessionTokenCodec(key = randomBytes(32)) {
  */
 export const SESSION_TOKEN_ROUTES = [
     { method: "GET", path: /^\/api\/session\/([^/]+)\/context$/, session: "path" },
-    { method: "POST", path: /^\/api\/session\/([^/]+)\/(attach|suggest|notify|title)$/, session: "path" },
+    { method: "POST", path: /^\/api\/session\/([^/]+)\/(attach|notify|title)$/, session: "path" },
     { method: "POST", path: /^\/api\/session\/([^/]+)\/ask$/, session: "path" },
     { method: "GET", path: /^\/api\/session\/([^/]+)\/ask\/[^/]+$/, session: "path" },
     { method: "POST", path: /^\/api\/session\/([^/]+)\/ask\/[^/]+\/wait$/, session: "path" },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bivy/bivy",
-  "version": "0.20.9-staging.7",
+  "version": "0.20.9-staging.8",
   "type": "module",
   "license": "AGPL-3.0-only",
   "description": "Run coding agents on machines you own. Open-source, self-hostable agent workspace.",
@@ -65,7 +65,7 @@
     "lodash-es": "4.18.1",
     "undici": "8.11.2"
   },
-  "readme": "# Bivy\n\n[![npm](https://img.shields.io/npm/v/@bivy/bivy?color=2b6cb0&label=%40bivy%2Fbivy)](https://www.npmjs.com/package/@bivy/bivy)\n[![license: AGPL-3.0-only](https://img.shields.io/badge/license-AGPL--3.0--only-2b6cb0)](LICENSE)\n[![node](https://img.shields.io/badge/node-%E2%89%A520-2b6cb0)](https://nodejs.org)\n\n**Local coding agents that show their work. Anywhere.**\n\nBivy is the open-source workspace for coding agents. It runs Claude Code, Codex,\nPi, OpenCode and other agents on your own machine. Reach them from a browser or\nyour phone, with the live session, its terminal, its approvals, and the app\nthey're building right in the chat. Try it, mark what's wrong, and send it back.\n\n<p align=\"center\">\n  <img src=\"docs/images/preview-feedback-loop.gif\" width=\"360\"\n       alt=\"On a phone: open the app an agent built, circle the packed items, send a note, and compare the result before and after the agent's fix.\">\n</p>\n\nBivy is not another coding agent and not a cloud development machine. The agent\nstays local and does the coding with your model provider. Your repos, tools,\ndatabases, and services stay where they are. Bivy gives you remote access to all\nof it, plus live previews, automations, and review.\n\n- **Live previews.** The running app beside the chat. Mark it, send it back,\n  share it with someone who has no Bivy account.\n- **Automations.** GitHub issues, failed CI, Linear, Slack, schedules, and\n  webhooks start the work. It comes back as a preview link or a pull request.\n- **Any agent.** Hit a usage limit? Fork the session to another agent, or let\n  Bivy retry when the limit resets.\n- **Your machine, anywhere.** Start at your desk, pick the session up on your\n  phone. The machine dials out, so there are no ports to open, and session\n  traffic is end-to-end encrypted.\n\n**[Start free on Bivy Cloud](https://app.bivy.sh)** ·\n**[Quickstart](docs/quickstart.md)** ·\n**[Documentation](docs/README.md)** ·\n**[Self-host](docs/deploy-images.md)** ·\n**[Website](https://bivy.sh)**\n\n**Recommended:** sign in at [app.bivy.sh](https://app.bivy.sh), then copy your\npersonalized **Connect a Machine** command into a terminal on your Mac or Linux\ncomputer. It installs and enrolls the machine without another Bivy login. The\nbrowser connects automatically; choose a repository and send your first task\nright there.\n\nPrefer starting from the terminal?\n\n```bash\ncurl -fsSL https://bivy.sh/install.sh | bash  # install + guided setup\ncd your-repo\nbivy run claude                            # or codex, pi, opencode\nbivy open                                  # continue in the web app (needs remote setup)\n```\n\nBivy Cloud hosts the app, control plane, and relay—not the machines running your\nagents. Connect a Mac, Linux computer, or existing server and bring your own\nagent subscription, model API key, or local model. You can also self-host the\nentire remote-access stack.\n\n> **Bivy is 0.x software.** Claude Code, Codex, Pi, OpenCode, and Grok are the\n> release-tested paths. Credential sync, resume, handoffs, approvals, and\n> sandboxing depend on the runtime. See the\n> [runtime support matrix](docs/runtime-support-matrix.md).\n\n## Don't just read the diff. Try the app.\n\nBivy lets you **use what the agent built and show it what to fix**, without a\nseparate deployment step.\n\n1. **Ask for a change.** The agent works in your repo with your existing tools\n   and local services.\n2. **Try the app.** Bivy finds the dev server the agent starts and opens it\n   beside the chat: web apps, terminals, and desktop apps. Use the running app,\n   not a screenshot of what the agent says it finished.\n3. **Mark what needs work.** Press and hold anything in the preview to mark it,\n   or drag to circle it, then say what you want. **Mark another** keeps\n   separate notes separate. The marks go to the agent with the element and page\n   context. No screenshots to paste.\n4. **Follow each note.** Every mark stays in the chat as a pin that resolves\n   itself: **Changed** when a later run changes what you marked, **Element\n   gone** when it leaves the page, **Done** when you say so.\n5. **Review the next version.** A new version waits on the preview pill instead\n   of reloading under you. Take it when you're ready, compare before and after,\n   inspect the diff and checks, and decide when the work is done.\n6. **Get a second opinion.** Share a preview link for 1 hour, 1 day, or 7 days.\n   Teammates and clients try the running app and leave notes without a Bivy\n   account. Make it view-only, or **Stop sharing** to end every link at once.\n\nOn Bivy Cloud, preview delivery is built in: no per-app domains, certificates,\npublic ports, or tunnels to configure. Self-hosters configure preview delivery\nonce for their Bivy deployment, not for every app. The app still needs its normal\nbuild or dev-server setup, and **the machine serving it must stay awake and\nonline**. These are development previews, not production hosting.\n\n**Share deliberately:** anyone with a preview link can use that app, including\nits live backend, until the link expires or you stop sharing.\nReviewer notes aren't sent to the agent automatically; you send them or explicitly\nallow agent access. Preview traffic uses HTTPS through the preview relay, not\nsession end-to-end encryption; the relay operator can see it.\n\n[App previews, visual feedback, and sharing →](docs/apps.md)\n\n## One workflow, from trigger to review\n\n```text\nPrompt · GitHub issue · CI failure · Linear · Slack · Schedule · Webhook\n                                 │\n                                 ▼\n                   Choose machine + agent + model\n                     + supported credentials\n                                 │\n                                 ▼\n                         Live agent session\n                     Join · steer · approve · stop\n                                 │\n                                 ▼\n                  Try app · inspect changes · checks\n                                 │\n                                 ▼\n                  Mark up · send feedback · iterate\n                                 │\n                                 ▼\n                      Share preview · review PR\n```\n\nA **Machine** is a computer or server you connect. A **Session** is live agent\nwork on that machine. A **Run** is delegated background work that creates a\nsession and tracks its outcome. An **Automation** is a reusable definition that\ncreates runs when an event matches.\n\nManual and automated work use the same kind of live session. You can join a run\nwhen it needs help rather than wait for a black-box job to finish.\n\n### Let events start the work\n\nAutomations turn recurring or incoming work into sessions you can join,\nsupervise, and review. An agent picks the task up on your machine and posts\nback a preview link or a pull request, so you try the result where the task\nlives and reply in the same session. Choose the repository, machine, agent,\nmodel, approval mode, sandbox setting, and maximum attempts.\n\n| Trigger | Example workflow |\n|---|---|\n| **GitHub issues and mentions** | Label an issue `bivy` or `bivy/<machine>`, or mention your Bivy GitHub App, to work toward a pull request. |\n| **Failed CI** | Match a failed workflow, ask the agent to reproduce it, make a fix, and run the affected checks. |\n| **Linear** | Label an issue to start work without copying its description into an agent. |\n| **Slack** | Send a request from the conversation where the work came up. |\n| **Schedules** | Run a weekly dependency review, recurring maintenance, or a one-time task. |\n| **Signed webhooks** | Connect alerts, internal tools, or your own event sources. |\n\nConfigure automations in the app or version them with your repository in\n`.bivy/automations.yaml`:\n\n```bash\nbivy automation init\n# Edit the generated definition for your repository and workflow.\nbivy automation validate\nbivy automation test --event .bivy/events/failed-ci.yaml  # supply a local event fixture\nbivy automation apply\n```\n\nOr delegate a one-off job without creating an automation:\n\n```bash\nbivy runs start \"Review outdated dependencies and propose a small, tested update.\"\nbivy runs wait <id>\n```\n\nRuns keep routing and lifecycle evidence, check results, and output references\nin a reviewable Receipt. For unattended issue work, Bivy runs declared repository\nchecks after the agent's turn; failed required checks fail the run even if the\nagent reports success. A completed process alone is not proof that the task\nsucceeded.\n\n[Automation recipes →](docs/capability-recipes.md#let-events-start-runs) ·\n[Automations as code →](docs/automations-as-code.md) ·\n[Run outcomes and reliability limits →](docs/automation-runs.md)\n\n### Use every agent you pay for. Switch mid-task.\n\nRun Claude Code for one task, Codex for another, and Pi or OpenCode where they\nfit, side by side in one session list. Bivy supplies the shared session,\nremote-access, automation, and review surfaces; your chosen agent still does\nthe coding and uses your model provider.\n\n- **Hit a usage limit? Keep going.** When a turn fails on a limit, fork the\n  session, with its code and conversation, to another agent and model, or let\n  Bivy retry when the limit resets (the provider has to report a reset time).\n- **Get a second opinion.** `bivy delegate` hands a task to another agent, on\n  the same machine or a different one, and brings back its answer, branch, and\n  PR. `--to codex,claude@linux` sends one task to several agents to compare.\n- Choose an agent and, where supported, a model for each session or run.\n- Import existing Claude Code and Codex sessions.\n- Fork or move work to another agent or machine when a different setup fits\n  better. Continuation fidelity varies: some paths preserve native history,\n  while others replay portable turns or hand over a summary with the earlier\n  transcript as a local file.\n- Use agent-native logins, Bivy-managed credentials, or local inference.\n  Bivy's custom OpenAI-compatible endpoint registry currently feeds Pi;\n  other agents may need their own provider configuration.\n- Register your own ACP or headless process agent with `bivy agent add`.\n\nBivy does not replace your agent, provide model inference, or make every agent's\nfeatures identical. Consult the [support matrix](docs/runtime-support-matrix.md)\nand [handoff recipes](docs/capability-recipes.md#fork-or-move-a-session).\n\n### Less signing in. Less copying secrets.\n\nBivy syncs **Bivy-managed API keys and supported OAuth credentials** across\nenrolled machines for compatible runtimes. Connect supported credentials once\nand reuse them where you run work, rather than manually distributing keys to\neach machine.\n\nFor ordinary account sync, credentials are encrypted on the node before upload.\nThe control plane stores ciphertext and wrapped-key metadata; enrolled nodes\nshare access by wrapping the vault key to one another. Bivy Cloud does not\nreceive plaintext credentials through this sync path.\n\nYou can also keep credentials local, use labeled keys and project presets, or\nreference environment variables and 1Password instead of embedding secrets in\nconfiguration:\n\n```bash\nbivy provider login\nbivy credentials add anthropic work\nbivy secrets ref github.repo-token op://Bivy/GitHub/repo-token\n```\n\n**Not every CLI login syncs.** Native agent logins may still be per-machine;\nGitHub App private-key sync is separately opt-in. If you lose every node and\ndevice able to unwrap a vault, you must sign in to providers again. Explicit\nhosted-provisioning custody grants are separate from ordinary encrypted sync.\n\n[Credential sync and runtime coverage →](docs/credential-sync.md) ·\n[Credentials guide →](docs/credentials-guide.md) ·\n[Key storage →](docs/key-management.md)\n\n### Work in the environment you already have\n\nA clean cloud sandbox isn't always enough. Your agent may need the database\nrunning on localhost, an uncommitted change, an internal API behind your VPN,\nor a model running on your GPU. Bivy runs the agent where those things already\nexist, subject to that machine's permissions and the runtime's protection.\n\nConnect several machines to the same account: a laptop for interactive work,\na Linux server for background jobs, or a GPU box for local inference. Choose\nthe machine for each session or pin it in an automation. Repository runs can\nuse isolated Git worktrees without rebuilding the whole development environment.\n\n**The execution machine must stay awake and online.** To close your laptop and\nleave work running, run the agent on a different, always-on machine.\n\n[Environment and multi-machine recipes →](docs/capability-recipes.md)\n\n### Start at your desk. Continue anywhere.\n\nOpen the same session in the browser, phone PWA, or terminal. Watch work live,\nanswer questions, approve supported tool calls, or stop the agent.\n\n- Send screenshots, images, logs, and other files from your phone.\n- Download reports and artifacts the agent creates.\n- Open [session apps](docs/apps.md) from chat or the **Apps** menu: live web\n  previews, desktop app views, and CLI/TUI tools. Agents can publish views with\n  `bivy app publish bivy.app.json` and create share links with `bivy app share`.\n- Use voice input and read-aloud where supported; provider-backed voice may\n  send audio or text to the selected provider.\n- Keep a native terminal workflow or use structured chat, depending on the agent.\n\n```bash\nbivy run claude --no-follow  # start without attaching\nbivy open                    # open the web app\nbivy resume                  # return to the session in your terminal\nbivy link                    # pair a device directly via QR\n```\n\nNo phone app installation is required. Open [app.bivy.sh](https://app.bivy.sh)\nin your browser; adding it to your home screen is optional.\n\n[Remote access →](docs/remote-access.md) ·\n[Voice, files, and terminal recipes →](docs/capability-recipes.md)\n\n### Agents can reach you, too\n\nEvery session gets the `bivy` CLI, so any agent with a shell can talk back\nthrough the app, not only agents with their own built-in tools:\n\n```bash\nbivy notify \"Tests are green, PR is up\"     # chat card + phone push when you're away\nbivy ask \"Ship to staging?\" --option Yes --option No  # waits for your answer\nbivy attach report.png --caption \"Before/after\"       # show a file in the chat\nbivy suggest \"Add a dark theme to settings\"           # a next task you start in one tap\nbivy context --json                                   # session, workspace, machine, apps\n```\n\n`bivy help --json` lists every command, and with `BIVY_OUTPUT=json` failures\ncome back as structured errors with distinct exit codes, so an agent can tell\nwhat went wrong and what to run next. `bivy guide` prints short playbooks for\nagents, and the same commands are served as MCP tools for agents that prefer\nthem. Add your own standing instructions for\nevery session in **Settings → Agent instructions**.\n\n[Commands for agents inside a session →](docs/cli-reference.md#inside-an-agent-session) ·\n[Agent instructions →](docs/agent-instructions.md)\n\n## Get started\n\n### Install\n\nBivy supports **macOS and Linux with Node.js 20+**. The installer installs the\n`@bivy/bivy` package, runs guided setup, and starts a launchd or systemd service:\n\n```bash\ncurl -fsSL https://bivy.sh/install.sh | bash\n```\n\nSetup helps you choose an agent and configure remote access. Existing agents\nkeep their command, login, and configuration. The installer may use `sudo` to\ninstall a missing Node.js, but never for `npm install`. To inspect it first,\ndownload it with `curl -fsSL https://bivy.sh/install.sh -o install.sh`.\n\nAlready have Node.js and want to avoid sudo?\n\n```bash\nnpm install -g @bivy/bivy\nbivy setup\n```\n\nThen try one small task:\n\n```bash\ncd your-repo\nbivy run claude\n# Ask: \"Explain this repo and make one small, safe improvement. Run the relevant checks.\"\nbivy open\n```\n\nOpen that same session on your phone while it runs. For a web app, ask the agent\nto start its dev server, then open **Apps → Running in this workspace → Preview**.\nTry a page, point to something you'd change, and send the feedback back to the\nagent. No separate preview deployment needed.\n\nOnce that works, share a preview for review, connect another machine, or add\nyour first automation.\n\n**Local-only works too.** `bivy run`, `bivy resume`, and `bivy sessions` need no\naccount or server. Choose **local only for now** during setup; use `bivy login`\nlater.\n\n**Just your own devices?** `bivy tailscale` serves the app from the machine\nitself at `https://<machine>.<tailnet>.ts.net`, with no account, control plane\nor relay. You get the core over your tailnet: sessions, chat, approvals,\nquestions, terminals and files. Push notifications, app previews and share\nlinks need Bivy Cloud or a self-hosted server. See [Tailscale](docs/tailscale.md)\nand [Remote access](docs/remote-access.md).\n\n[Full quickstart →](docs/quickstart.md) ·\n[Installer options, service management, and uninstall →](docs/install.md)\n\n### Choose hosted or self-hosted\n\n| Option | What you get |\n|---|---|\n| **Free Cloud — $0** | Every launch feature, including automations; 10 new remote sessions per rolling seven days. No credit card required. |\n| **Cloud — $15/month** | The same features with unlimited remote sessions. |\n| **Self-hosted Core** | Operate the app, control plane, and relay yourself, with no Bivy usage limits. |\n\nManual and automated sessions share the Cloud allowance. Resuming existing\nsessions and viewing history do not consume it. Agent subscriptions and model\nprovider charges are separate. See [current pricing](https://bivy.sh#pricing).\n\n**Self-host anywhere:** deploy the public control-plane (including the web app)\nand relay images with Postgres and [a small set of environment variables](docs/deploy-images.md).\nYour server or container platform handles HTTPS. Set up owner access in the\nbrowser—no SSH, external authentication provider, or Bivy Cloud account required.\nFor a bare VPS, the [Compose installer](docs/self-host-quickstart.md) automates the\nsame stack. These onboarding features require a release containing them.\n\nStart on Cloud and self-host later if you prefer. Deploy the stack, reconnect\nmachines with `bivy relay:setup`, and pair devices to your server. This is not a\none-click migration of your Cloud account; your local repos and agent\nconfiguration stay in place.\n\n```bash\nbivy relay:setup \\\n  --control-plane https://bivy.example.com \\\n  --relay wss://relay.example.com\n```\n\nSelf-hosting is community-supported: you own TLS, backups, upgrades, and\nhardening. Public multi-architecture images are available as\n`ghcr.io/bivysh/bivy-control-plane` and `ghcr.io/bivysh/bivy-relay`; pin a release\nversion or full commit SHA.\n\n[Deploy the images anywhere →](docs/deploy-images.md) ·\n[Optional VPS installer →](docs/self-host-quickstart.md) ·\n[Operations reference →](docs/self-host.md)\n\n## Architecture\n\nYour environment, with clear security boundaries:\n\n```text\nYour machine                         Hosted or self-hosted\n┌──────────────────────┐             ┌──────────────────────┐\n│ Node daemon          │──outbound──▶│ Relay                │\n│ Agents, repos, tools │             │ Encrypted frames     │\n│ Local credentials    │             └──────────┬───────────┘\n└──────────────────────┘                        │\n                                    Browser / phone\n                                    + control plane\n                                    (app, accounts, metadata)\n```\n\n- **Execution stays on your machine.** Bivy Cloud does not run your agents.\n  Your model provider still sees whatever the agent sends it.\n- **Interactive session traffic is end-to-end encrypted** between the node and\n  paired devices. The relay forwards opaque session frames; your node dials out,\n  so no inbound public port is required.\n- **App previews have a separate security boundary.** Preview traffic uses HTTPS\n  and an outbound tunnel, not session E2E encryption. The preview ingress/relay\n  operator can see it. Public preview links grant anyone holding them access to\n  that view and its live backend until expiry or revocation. See\n  [preview security and sharing](docs/apps.md#runtime-and-security-boundaries).\n- **Ordinary credential sync uploads ciphertext, not plaintext keys.**\n  Supported credentials and recovery limits are documented separately.\n- **Encryption is not universal across integrations.** Slack commands and\n  generic webhook instructions reach the control plane in plaintext. Do not\n  put secrets in them. Routing and bounded run metadata are also visible there.\n- **Device authorization matters.** QR pairing authorizes a device directly\n  through the node. Hosted account pairing trusts the control plane to authorize\n  devices and serve the web app that holds client keys.\n- **Bivy is not an OS-level sandbox.** The default approval mode is\n  `autonomous`; protection depends on the runtime. Some agents enforce sandbox\n  tiers, while process agents may run with your full user permissions.\n  Heuristic tool checks help prevent accidents but are not isolation.\n\nReview the runtime's Protection label and configure approval/sandbox settings\nfor the task, especially before enabling unattended work.\n\n[Security model and known limitations →](docs/security-model.md) ·\n[Runtime protection matrix →](docs/runtime-support-matrix.md) ·\n[Configuration →](docs/configuration.md)\n\n## Agents and everyday commands\n\n**Claude Code, Codex, Pi, OpenCode, and Grok are release-tested.** Additional\nadapters include Gemini CLI, Qwen Code, Goose, Aider, Cline, Crush, Cursor, GitHub\nCopilot, Amp, Auggie, Droid, Continue, Kilo Code, and Rovo Dev. Installation,\nresume, model selection, and tool protection vary—see the\n[support matrix](docs/runtime-support-matrix.md) and [agent guides](docs/agents/README.md).\n\nRun an arbitrary command with `bivy run -- ./your-agent --flags`, register a\nreusable entry with `bivy agent add`, or package a declarative integration with\nexperimental [plugins](docs/plugins.md).\n\n```bash\nbivy run claude       # launch a durable session; also codex, pi, opencode\nbivy sessions         # list live and saved sessions\nbivy resume           # resume the most recent session\nbivy open             # open the web app (requires remote setup)\nbivy nodes            # list connected account machines\nbivy runs list        # inspect delegated work\nbivy automation init  # scaffold repo-owned automations\nbivy provider login   # connect supported model credentials\nbivy agent add        # register an ACP or process agent\nbivy doctor           # check installation and connectivity\nbivy logs -f          # follow node logs\nbivy update           # update and restart the service\n```\n\n`bivy update` uses your original installation method and waits for an active\nturn to finish before restarting. Use `--force` to skip that wait.\n\n[CLI reference →](docs/cli-reference.md) ·\n[Node and project configuration →](docs/config-as-code.md) ·\n[GitHub setup →](docs/github-setup.md) ·\n[Linear setup →](docs/linear-work-queue.md)\n\n## Development and contributions\n\n```bash\npnpm install\npnpm run dev          # node daemon on http://localhost:4317\npnpm run dev:web      # web client dev server\n```\n\n| Directory | Contents |\n|---|---|\n| `src/`, `bin/` | Node daemon, CLI, runtime adapters, sessions, approvals, secrets |\n| `packages/core/` | Shared protocol, pairing, and wire format |\n| `packages/web/`, `packages/ui/` | React PWA and shared design system |\n| `services/relay/` | Self-hostable encrypted relay |\n| `services/control-plane/` | Self-hostable control plane |\n| `deploy/` | Deployment examples |\n\n```bash\npnpm run typecheck\npnpm run typecheck:web\npnpm run lint\npnpm run test:unit\npnpm run test:core\npnpm run check:licenses\npnpm run check:secrets\n```\n\nSee [CONTRIBUTING.md](CONTRIBUTING.md) for the development workflow. Releases\nare published from CI with provenance attestations; see\n[release verification](docs/releasing.md).\n\n**Found a security issue?** Use\n[GitHub private vulnerability reporting](https://github.com/bivysh/bivy/security/advisories/new),\nnot a public issue. See [SECURITY.md](SECURITY.md).\n\n### In development—not available at launch\n\nAutomatically provisioned, short-lived **ephemeral machines** are in development\nfor hosted and bring-your-own-cloud deployments. Neither path is ready or\nsupported for this launch. Use an existing computer or server you operate.\nExperimental provisioning has different credential-custody and encryption\nboundaries; see the [provisioning trust model](docs/hosted-provisioning-trust-model.md).\n\n## License\n\nEverything in this repository—node, CLI, web/PWA, relay, and control plane—is\nfree and open-source **AGPL-3.0-only Core**, with no Bivy usage limits. You may\nuse, modify, and self-host it under that license. If users interact with your\nmodified version over a network, section 13 requires you to offer its\ncorresponding source. See [LICENSE](LICENSE).\n\nBivy Cloud is the hosted operation of that stack. Its plans, billing and\nmanaged-compute operations live in a separate private service behind Core's\ndeployment extension. Contributions are made under the\n[Contributor License Agreement](CLA.md). The Bivy name and logo are covered by\nthe [trademark policy](TRADEMARKS.md).\n",
+  "readme": "# Bivy\n\n[![npm](https://img.shields.io/npm/v/@bivy/bivy?color=2b6cb0&label=%40bivy%2Fbivy)](https://www.npmjs.com/package/@bivy/bivy)\n[![license: AGPL-3.0-only](https://img.shields.io/badge/license-AGPL--3.0--only-2b6cb0)](LICENSE)\n[![node](https://img.shields.io/badge/node-%E2%89%A520-2b6cb0)](https://nodejs.org)\n\n**Local coding agents that show their work. Anywhere.**\n\nBivy is the open-source workspace for coding agents. It runs Claude Code, Codex,\nPi, OpenCode and other agents on your own machine. Reach them from a browser or\nyour phone, with the live session, its terminal, its approvals, and the app\nthey're building right in the chat. Try it, mark what's wrong, and send it back.\n\n<p align=\"center\">\n  <img src=\"docs/images/preview-feedback-loop.gif\" width=\"360\"\n       alt=\"On a phone: open the app an agent built, circle the packed items, send a note, and compare the result before and after the agent's fix.\">\n</p>\n\nBivy is not another coding agent and not a cloud development machine. The agent\nstays local and does the coding with your model provider. Your repos, tools,\ndatabases, and services stay where they are. Bivy gives you remote access to all\nof it, plus live previews, automations, and review.\n\n- **Live previews.** The running app beside the chat. Mark it, send it back,\n  share it with someone who has no Bivy account.\n- **Automations.** GitHub issues, failed CI, Linear, Slack, schedules, and\n  webhooks start the work. It comes back as a preview link or a pull request.\n- **Any agent.** Hit a usage limit? Fork the session to another agent, or let\n  Bivy retry when the limit resets.\n- **Your machine, anywhere.** Start at your desk, pick the session up on your\n  phone. The machine dials out, so there are no ports to open, and session\n  traffic is end-to-end encrypted.\n\n**[Start free on Bivy Cloud](https://app.bivy.sh)** ·\n**[Quickstart](docs/quickstart.md)** ·\n**[Documentation](docs/README.md)** ·\n**[Self-host](docs/deploy-images.md)** ·\n**[Website](https://bivy.sh)**\n\n**Recommended:** sign in at [app.bivy.sh](https://app.bivy.sh), then copy your\npersonalized **Connect a Machine** command into a terminal on your Mac or Linux\ncomputer. It installs and enrolls the machine without another Bivy login. The\nbrowser connects automatically; choose a repository and send your first task\nright there.\n\nPrefer starting from the terminal?\n\n```bash\ncurl -fsSL https://bivy.sh/install.sh | bash  # install + guided setup\ncd your-repo\nbivy run claude                            # or codex, pi, opencode\nbivy open                                  # continue in the web app (needs remote setup)\n```\n\nBivy Cloud hosts the app, control plane, and relay—not the machines running your\nagents. Connect a Mac, Linux computer, or existing server and bring your own\nagent subscription, model API key, or local model. You can also self-host the\nentire remote-access stack.\n\n> **Bivy is 0.x software.** Claude Code, Codex, Pi, OpenCode, and Grok are the\n> release-tested paths. Credential sync, resume, handoffs, approvals, and\n> sandboxing depend on the runtime. See the\n> [runtime support matrix](docs/runtime-support-matrix.md).\n\n## Don't just read the diff. Try the app.\n\nBivy lets you **use what the agent built and show it what to fix**, without a\nseparate deployment step.\n\n1. **Ask for a change.** The agent works in your repo with your existing tools\n   and local services.\n2. **Try the app.** Bivy finds the dev server the agent starts and opens it\n   beside the chat: web apps, terminals, and desktop apps. Use the running app,\n   not a screenshot of what the agent says it finished.\n3. **Mark what needs work.** Press and hold anything in the preview to mark it,\n   or drag to circle it, then say what you want. **Mark another** keeps\n   separate notes separate. The marks go to the agent with the element and page\n   context. No screenshots to paste.\n4. **Follow each note.** Every mark stays in the chat as a pin that resolves\n   itself: **Changed** when a later run changes what you marked, **Element\n   gone** when it leaves the page, **Done** when you say so.\n5. **Review the next version.** A new version waits on the preview pill instead\n   of reloading under you. Take it when you're ready, compare before and after,\n   inspect the diff and checks, and decide when the work is done.\n6. **Get a second opinion.** Share a preview link for 1 hour, 1 day, or 7 days.\n   Teammates and clients try the running app and leave notes without a Bivy\n   account. Make it view-only, or **Stop sharing** to end every link at once.\n\nOn Bivy Cloud, preview delivery is built in: no per-app domains, certificates,\npublic ports, or tunnels to configure. Self-hosters configure preview delivery\nonce for their Bivy deployment, not for every app. The app still needs its normal\nbuild or dev-server setup, and **the machine serving it must stay awake and\nonline**. These are development previews, not production hosting.\n\n**Share deliberately:** anyone with a preview link can use that app, including\nits live backend, until the link expires or you stop sharing.\nReviewer notes aren't sent to the agent automatically; you send them or explicitly\nallow agent access. Preview traffic uses HTTPS through the preview relay, not\nsession end-to-end encryption; the relay operator can see it.\n\n[App previews, visual feedback, and sharing →](docs/apps.md)\n\n## One workflow, from trigger to review\n\n```text\nPrompt · GitHub issue · CI failure · Linear · Slack · Schedule · Webhook\n                                 │\n                                 ▼\n                   Choose machine + agent + model\n                     + supported credentials\n                                 │\n                                 ▼\n                         Live agent session\n                     Join · steer · approve · stop\n                                 │\n                                 ▼\n                  Try app · inspect changes · checks\n                                 │\n                                 ▼\n                  Mark up · send feedback · iterate\n                                 │\n                                 ▼\n                      Share preview · review PR\n```\n\nA **Machine** is a computer or server you connect. A **Session** is live agent\nwork on that machine. A **Run** is delegated background work that creates a\nsession and tracks its outcome. An **Automation** is a reusable definition that\ncreates runs when an event matches.\n\nManual and automated work use the same kind of live session. You can join a run\nwhen it needs help rather than wait for a black-box job to finish.\n\n### Let events start the work\n\nAutomations turn recurring or incoming work into sessions you can join,\nsupervise, and review. An agent picks the task up on your machine and posts\nback a preview link or a pull request, so you try the result where the task\nlives and reply in the same session. Choose the repository, machine, agent,\nmodel, approval mode, sandbox setting, and maximum attempts.\n\n| Trigger | Example workflow |\n|---|---|\n| **GitHub issues and mentions** | Label an issue `bivy` or `bivy/<machine>`, or mention your Bivy GitHub App, to work toward a pull request. |\n| **Failed CI** | Match a failed workflow, ask the agent to reproduce it, make a fix, and run the affected checks. |\n| **Linear** | Label an issue to start work without copying its description into an agent. |\n| **Slack** | Send a request from the conversation where the work came up. |\n| **Schedules** | Run a weekly dependency review, recurring maintenance, or a one-time task. |\n| **Signed webhooks** | Connect alerts, internal tools, or your own event sources. |\n\nConfigure automations in the app or version them with your repository in\n`.bivy/automations.yaml`:\n\n```bash\nbivy automation init\n# Edit the generated definition for your repository and workflow.\nbivy automation validate\nbivy automation test --event .bivy/events/failed-ci.yaml  # supply a local event fixture\nbivy automation apply\n```\n\nOr delegate a one-off job without creating an automation:\n\n```bash\nbivy runs start \"Review outdated dependencies and propose a small, tested update.\"\nbivy runs wait <id>\n```\n\nRuns keep routing and lifecycle evidence, check results, and output references\nin a reviewable Receipt. For unattended issue work, Bivy runs declared repository\nchecks after the agent's turn; failed required checks fail the run even if the\nagent reports success. A completed process alone is not proof that the task\nsucceeded.\n\n[Automation recipes →](docs/capability-recipes.md#let-events-start-runs) ·\n[Automations as code →](docs/automations-as-code.md) ·\n[Run outcomes and reliability limits →](docs/automation-runs.md)\n\n### Use every agent you pay for. Switch mid-task.\n\nRun Claude Code for one task, Codex for another, and Pi or OpenCode where they\nfit, side by side in one session list. Bivy supplies the shared session,\nremote-access, automation, and review surfaces; your chosen agent still does\nthe coding and uses your model provider.\n\n- **Hit a usage limit? Keep going.** When a turn fails on a limit, fork the\n  session, with its code and conversation, to another agent and model, or let\n  Bivy retry when the limit resets (the provider has to report a reset time).\n- **Get a second opinion.** `bivy delegate` hands a task to another agent, on\n  the same machine or a different one, and brings back its answer, branch, and\n  PR. `--to codex,claude@linux` sends one task to several agents to compare.\n- Choose an agent and, where supported, a model for each session or run.\n- Import existing Claude Code and Codex sessions.\n- Fork or move work to another agent or machine when a different setup fits\n  better. Continuation fidelity varies: some paths preserve native history,\n  while others replay portable turns or hand over a summary with the earlier\n  transcript as a local file.\n- Use agent-native logins, Bivy-managed credentials, or local inference.\n  Bivy's custom OpenAI-compatible endpoint registry currently feeds Pi;\n  other agents may need their own provider configuration.\n- Register your own ACP or headless process agent with `bivy agent add`.\n\nBivy does not replace your agent, provide model inference, or make every agent's\nfeatures identical. Consult the [support matrix](docs/runtime-support-matrix.md)\nand [handoff recipes](docs/capability-recipes.md#fork-or-move-a-session).\n\n### Less signing in. Less copying secrets.\n\nBivy syncs **Bivy-managed API keys and supported OAuth credentials** across\nenrolled machines for compatible runtimes. Connect supported credentials once\nand reuse them where you run work, rather than manually distributing keys to\neach machine.\n\nFor ordinary account sync, credentials are encrypted on the node before upload.\nThe control plane stores ciphertext and wrapped-key metadata; enrolled nodes\nshare access by wrapping the vault key to one another. Bivy Cloud does not\nreceive plaintext credentials through this sync path.\n\nYou can also keep credentials local, use labeled keys and project presets, or\nreference environment variables and 1Password instead of embedding secrets in\nconfiguration:\n\n```bash\nbivy provider login\nbivy credentials add anthropic work\nbivy secrets ref github.repo-token op://Bivy/GitHub/repo-token\n```\n\n**Not every CLI login syncs.** Native agent logins may still be per-machine;\nGitHub App private-key sync is separately opt-in. If you lose every node and\ndevice able to unwrap a vault, you must sign in to providers again. Explicit\nhosted-provisioning custody grants are separate from ordinary encrypted sync.\n\n[Credential sync and runtime coverage →](docs/credential-sync.md) ·\n[Credentials guide →](docs/credentials-guide.md) ·\n[Key storage →](docs/key-management.md)\n\n### Work in the environment you already have\n\nA clean cloud sandbox isn't always enough. Your agent may need the database\nrunning on localhost, an uncommitted change, an internal API behind your VPN,\nor a model running on your GPU. Bivy runs the agent where those things already\nexist, subject to that machine's permissions and the runtime's protection.\n\nConnect several machines to the same account: a laptop for interactive work,\na Linux server for background jobs, or a GPU box for local inference. Choose\nthe machine for each session or pin it in an automation. Repository runs can\nuse isolated Git worktrees without rebuilding the whole development environment.\n\n**The execution machine must stay awake and online.** To close your laptop and\nleave work running, run the agent on a different, always-on machine.\n\n[Environment and multi-machine recipes →](docs/capability-recipes.md)\n\n### Start at your desk. Continue anywhere.\n\nOpen the same session in the browser, phone PWA, or terminal. Watch work live,\nanswer questions, approve supported tool calls, or stop the agent.\n\n- Send screenshots, images, logs, and other files from your phone.\n- Download reports and artifacts the agent creates.\n- Open [session apps](docs/apps.md) from chat or the **Apps** menu: live web\n  previews, desktop app views, and CLI/TUI tools. Agents can publish views with\n  `bivy app publish bivy.app.json` and create share links with `bivy app share`.\n- Use voice input and read-aloud where supported; provider-backed voice may\n  send audio or text to the selected provider.\n- Keep a native terminal workflow or use structured chat, depending on the agent.\n\n```bash\nbivy run claude --no-follow  # start without attaching\nbivy open                    # open the web app\nbivy resume                  # return to the session in your terminal\nbivy link                    # pair a device directly via QR\n```\n\nNo phone app installation is required. Open [app.bivy.sh](https://app.bivy.sh)\nin your browser; adding it to your home screen is optional.\n\n[Remote access →](docs/remote-access.md) ·\n[Voice, files, and terminal recipes →](docs/capability-recipes.md)\n\n### Agents can reach you, too\n\nEvery session gets the `bivy` CLI, so any agent with a shell can talk back\nthrough the app, not only agents with their own built-in tools:\n\n```bash\nbivy notify                                 # push to your phone so you come back\nbivy ask \"Ship to staging?\" --option Yes --option No  # waits for your answer\nbivy attach report.png --caption \"Before/after\"       # show a file in the chat\nbivy context --json                                   # session, workspace, machine, apps\n```\n\n`bivy help --json` lists every command, and with `BIVY_OUTPUT=json` failures\ncome back as structured errors with distinct exit codes, so an agent can tell\nwhat went wrong and what to run next. `bivy guide` prints short playbooks for\nagents, and the same commands are served as MCP tools for agents that prefer\nthem. Add your own standing instructions for\nevery session in **Settings → Agent instructions**.\n\n[Commands for agents inside a session →](docs/cli-reference.md#inside-an-agent-session) ·\n[Agent instructions →](docs/agent-instructions.md)\n\n## Get started\n\n### Install\n\nBivy supports **macOS and Linux with Node.js 20+**. The installer installs the\n`@bivy/bivy` package, runs guided setup, and starts a launchd or systemd service:\n\n```bash\ncurl -fsSL https://bivy.sh/install.sh | bash\n```\n\nSetup helps you choose an agent and configure remote access. Existing agents\nkeep their command, login, and configuration. The installer may use `sudo` to\ninstall a missing Node.js, but never for `npm install`. To inspect it first,\ndownload it with `curl -fsSL https://bivy.sh/install.sh -o install.sh`.\n\nAlready have Node.js and want to avoid sudo?\n\n```bash\nnpm install -g @bivy/bivy\nbivy setup\n```\n\nThen try one small task:\n\n```bash\ncd your-repo\nbivy run claude\n# Ask: \"Explain this repo and make one small, safe improvement. Run the relevant checks.\"\nbivy open\n```\n\nOpen that same session on your phone while it runs. For a web app, ask the agent\nto start its dev server, then open **Apps → Running in this workspace → Preview**.\nTry a page, point to something you'd change, and send the feedback back to the\nagent. No separate preview deployment needed.\n\nOnce that works, share a preview for review, connect another machine, or add\nyour first automation.\n\n**Local-only works too.** `bivy run`, `bivy resume`, and `bivy sessions` need no\naccount or server. Choose **local only for now** during setup; use `bivy login`\nlater.\n\n**Just your own devices?** `bivy tailscale` serves the app from the machine\nitself at `https://<machine>.<tailnet>.ts.net`, with no account, control plane\nor relay. You get the core over your tailnet: sessions, chat, approvals,\nquestions, terminals and files. Push notifications, app previews and share\nlinks need Bivy Cloud or a self-hosted server. See [Tailscale](docs/tailscale.md)\nand [Remote access](docs/remote-access.md).\n\n[Full quickstart →](docs/quickstart.md) ·\n[Installer options, service management, and uninstall →](docs/install.md)\n\n### Choose hosted or self-hosted\n\n| Option | What you get |\n|---|---|\n| **Free Cloud — $0** | Every launch feature, including automations; 10 new remote sessions per rolling seven days. No credit card required. |\n| **Cloud — $15/month** | The same features with unlimited remote sessions. |\n| **Self-hosted Core** | Operate the app, control plane, and relay yourself, with no Bivy usage limits. |\n\nManual and automated sessions share the Cloud allowance. Resuming existing\nsessions and viewing history do not consume it. Agent subscriptions and model\nprovider charges are separate. See [current pricing](https://bivy.sh#pricing).\n\n**Self-host anywhere:** deploy the public control-plane (including the web app)\nand relay images with Postgres and [a small set of environment variables](docs/deploy-images.md).\nYour server or container platform handles HTTPS. Set up owner access in the\nbrowser—no SSH, external authentication provider, or Bivy Cloud account required.\nFor a bare VPS, the [Compose installer](docs/self-host-quickstart.md) automates the\nsame stack. These onboarding features require a release containing them.\n\nStart on Cloud and self-host later if you prefer. Deploy the stack, reconnect\nmachines with `bivy relay:setup`, and pair devices to your server. This is not a\none-click migration of your Cloud account; your local repos and agent\nconfiguration stay in place.\n\n```bash\nbivy relay:setup \\\n  --control-plane https://bivy.example.com \\\n  --relay wss://relay.example.com\n```\n\nSelf-hosting is community-supported: you own TLS, backups, upgrades, and\nhardening. Public multi-architecture images are available as\n`ghcr.io/bivysh/bivy-control-plane` and `ghcr.io/bivysh/bivy-relay`; pin a release\nversion or full commit SHA.\n\n[Deploy the images anywhere →](docs/deploy-images.md) ·\n[Optional VPS installer →](docs/self-host-quickstart.md) ·\n[Operations reference →](docs/self-host.md)\n\n## Architecture\n\nYour environment, with clear security boundaries:\n\n```text\nYour machine                         Hosted or self-hosted\n┌──────────────────────┐             ┌──────────────────────┐\n│ Node daemon          │──outbound──▶│ Relay                │\n│ Agents, repos, tools │             │ Encrypted frames     │\n│ Local credentials    │             └──────────┬───────────┘\n└──────────────────────┘                        │\n                                    Browser / phone\n                                    + control plane\n                                    (app, accounts, metadata)\n```\n\n- **Execution stays on your machine.** Bivy Cloud does not run your agents.\n  Your model provider still sees whatever the agent sends it.\n- **Interactive session traffic is end-to-end encrypted** between the node and\n  paired devices. The relay forwards opaque session frames; your node dials out,\n  so no inbound public port is required.\n- **App previews have a separate security boundary.** Preview traffic uses HTTPS\n  and an outbound tunnel, not session E2E encryption. The preview ingress/relay\n  operator can see it. Public preview links grant anyone holding them access to\n  that view and its live backend until expiry or revocation. See\n  [preview security and sharing](docs/apps.md#runtime-and-security-boundaries).\n- **Ordinary credential sync uploads ciphertext, not plaintext keys.**\n  Supported credentials and recovery limits are documented separately.\n- **Encryption is not universal across integrations.** Slack commands and\n  generic webhook instructions reach the control plane in plaintext. Do not\n  put secrets in them. Routing and bounded run metadata are also visible there.\n- **Device authorization matters.** QR pairing authorizes a device directly\n  through the node. Hosted account pairing trusts the control plane to authorize\n  devices and serve the web app that holds client keys.\n- **Bivy is not an OS-level sandbox.** The default approval mode is\n  `autonomous`; protection depends on the runtime. Some agents enforce sandbox\n  tiers, while process agents may run with your full user permissions.\n  Heuristic tool checks help prevent accidents but are not isolation.\n\nReview the runtime's Protection label and configure approval/sandbox settings\nfor the task, especially before enabling unattended work.\n\n[Security model and known limitations →](docs/security-model.md) ·\n[Runtime protection matrix →](docs/runtime-support-matrix.md) ·\n[Configuration →](docs/configuration.md)\n\n## Agents and everyday commands\n\n**Claude Code, Codex, Pi, OpenCode, and Grok are release-tested.** Additional\nadapters include Gemini CLI, Qwen Code, Goose, Aider, Cline, Crush, Cursor, GitHub\nCopilot, Amp, Auggie, Droid, Continue, Kilo Code, and Rovo Dev. Installation,\nresume, model selection, and tool protection vary—see the\n[support matrix](docs/runtime-support-matrix.md) and [agent guides](docs/agents/README.md).\n\nRun an arbitrary command with `bivy run -- ./your-agent --flags`, register a\nreusable entry with `bivy agent add`, or package a declarative integration with\nexperimental [plugins](docs/plugins.md).\n\n```bash\nbivy run claude       # launch a durable session; also codex, pi, opencode\nbivy sessions         # list live and saved sessions\nbivy resume           # resume the most recent session\nbivy open             # open the web app (requires remote setup)\nbivy nodes            # list connected account machines\nbivy runs list        # inspect delegated work\nbivy automation init  # scaffold repo-owned automations\nbivy provider login   # connect supported model credentials\nbivy agent add        # register an ACP or process agent\nbivy doctor           # check installation and connectivity\nbivy logs -f          # follow node logs\nbivy update           # update and restart the service\n```\n\n`bivy update` uses your original installation method and waits for an active\nturn to finish before restarting. Use `--force` to skip that wait.\n\n[CLI reference →](docs/cli-reference.md) ·\n[Node and project configuration →](docs/config-as-code.md) ·\n[GitHub setup →](docs/github-setup.md) ·\n[Linear setup →](docs/linear-work-queue.md)\n\n## Development and contributions\n\n```bash\npnpm install\npnpm run dev          # node daemon on http://localhost:4317\npnpm run dev:web      # web client dev server\n```\n\n| Directory | Contents |\n|---|---|\n| `src/`, `bin/` | Node daemon, CLI, runtime adapters, sessions, approvals, secrets |\n| `packages/core/` | Shared protocol, pairing, and wire format |\n| `packages/web/`, `packages/ui/` | React PWA and shared design system |\n| `services/relay/` | Self-hostable encrypted relay |\n| `services/control-plane/` | Self-hostable control plane |\n| `deploy/` | Deployment examples |\n\n```bash\npnpm run typecheck\npnpm run typecheck:web\npnpm run lint\npnpm run test:unit\npnpm run test:core\npnpm run check:licenses\npnpm run check:secrets\n```\n\nSee [CONTRIBUTING.md](CONTRIBUTING.md) for the development workflow. Releases\nare published from CI with provenance attestations; see\n[release verification](docs/releasing.md).\n\n**Found a security issue?** Use\n[GitHub private vulnerability reporting](https://github.com/bivysh/bivy/security/advisories/new),\nnot a public issue. See [SECURITY.md](SECURITY.md).\n\n### In development—not available at launch\n\nAutomatically provisioned, short-lived **ephemeral machines** are in development\nfor hosted and bring-your-own-cloud deployments. Neither path is ready or\nsupported for this launch. Use an existing computer or server you operate.\nExperimental provisioning has different credential-custody and encryption\nboundaries; see the [provisioning trust model](docs/hosted-provisioning-trust-model.md).\n\n## License\n\nEverything in this repository—node, CLI, web/PWA, relay, and control plane—is\nfree and open-source **AGPL-3.0-only Core**, with no Bivy usage limits. You may\nuse, modify, and self-host it under that license. If users interact with your\nmodified version over a network, section 13 requires you to offer its\ncorresponding source. See [LICENSE](LICENSE).\n\nBivy Cloud is the hosted operation of that stack. Its plans, billing and\nmanaged-compute operations live in a separate private service behind Core's\ndeployment extension. Contributions are made under the\n[Contributor License Agreement](CLA.md). The Bivy name and logo are covered by\nthe [trademark policy](TRADEMARKS.md).\n",
   "readmeFilename": "README.md",
   "agentBridges": {
     "@anthropic-ai/claude-agent-sdk": "0.3.286",