baychat 0.21.4 → 0.22.0

package/dist/relay/session-commands.js

@@ -0,0 +1,89 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.SESSION_COMMANDS = void 0;
+exports.parseSessionCommand = parseSessionCommand;
+exports.sessionCommandHelp = sessionCommandHelp;
+exports.noTerminalReason = noTerminalReason;
+/** Claude has no `/new`; `/clear` is how it starts a fresh chat. */
+const freshChat = (runtime) => (runtime === "codex" ? "/new" : "/clear");
+exports.SESSION_COMMANDS = [
+    {
+        id: "clear",
+        trigger: "/clear",
+        summary: "Clear this session's context, exactly as typing /clear in its terminal does.",
+        keys: () => "/clear",
+    },
+    {
+        id: "new",
+        trigger: "/new",
+        summary: "Start a fresh chat in this session, keeping the terminal open.",
+        keys: freshChat,
+    },
+    // ── ACP sessions (run by the relay, no terminal) ──────────────────────────────────────
+    // Four ROWS rather than `/mode <x>`, on purpose. The rule above says the wire carries a NAME
+    // and never an argument; an enum argument would be the first crack in it. These select a row
+    // like every other command, type nothing, and are answered by the relay.
+    { id: "mode-chat", trigger: "/mode-chat", mode: "chat", summary: "Relay-run agents: BayChat tools only — nothing on the computer. Owner or anyone with command access." },
+    { id: "mode-read", trigger: "/mode-read", mode: "read", summary: "Relay-run agents: may read files, no commands, no writes. Owner or anyone with command access." },
+    { id: "mode-ask", trigger: "/mode-ask", mode: "ask", summary: "Relay-run agents: may run commands; writes ask on your phone first. Owner or anyone with command access." },
+    { id: "mode-full", trigger: "/mode-full", mode: "full", summary: "Relay-run agents: may write inside its folder without asking. Owner or anyone with command access." },
+    { id: "stop", trigger: "/stop", summary: "Relay-run agents: stop the turn that is running now." },
+    {
+        id: "exit",
+        trigger: "/exit",
+        summary: "Stop this session being reachable from the Bay. Its terminal stays open — this does not close it.",
+    },
+    {
+        id: "status",
+        trigger: "/status",
+        summary: "What this relay knows about the session: runtime, terminal, and whether it is live.",
+    },
+    {
+        id: "help",
+        trigger: "/help",
+        summary: "This list.",
+    },
+];
+/**
+ * Is this message one of the commands, or is it chat?
+ *
+ * EXACT MATCH on the trimmed text, deliberately. "can you /clear please" is a sentence
+ * about a command and must reach the agent as one; anything looser would turn discussing
+ * the feature into using it. Case-insensitive because a phone keyboard capitalises the
+ * start of a line without being asked.
+ *
+ * Says nothing about whether the sender MAY run it — that is the server's answer, checked
+ * by the caller. Parsing and permission are kept apart so neither can be mistaken for the
+ * other.
+ */
+function parseSessionCommand(text) {
+    const normalised = text.trim().toLowerCase();
+    if (!normalised.startsWith("/"))
+        return undefined;
+    return exports.SESSION_COMMANDS.find((command) => command.trigger === normalised);
+}
+/** The reply to `/help`, and the thing to say when a command cannot run. */
+function sessionCommandHelp() {
+    return [
+        "Commands this session understands:",
+        ...exports.SESSION_COMMANDS.map((command) => `  ${command.trigger} — ${command.summary}`),
+        "",
+        "Only you, and anyone you have given permission to, can run them.",
+    ].join("\n");
+}
+/**
+ * The refusal for a session whose terminal cannot be typed into.
+ *
+ * NAMES THE FIX. A person whose session is not in a multiplexer has done nothing wrong and
+ * cannot be expected to know why a chat command needs one; "it did not work" would leave
+ * them with no next step, which is the failure this whole codebase keeps writing comments
+ * about.
+ */
+function noTerminalReason(detail) {
+    return [
+        detail ??
+            "This session is not running inside a terminal multiplexer, so there is nothing to type into.",
+        "Start it with `baychat` next time and they will work — that runs your agent somewhere these commands can reach.",
+        "/status, /exit and /help work either way.",
+    ].join(" ");
+}

package/dist/relay/session-reply.js

@@ -0,0 +1,25 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.postSessionReply = postSessionReply;
+const api_1 = require("../api");
+/**
+ * Say, in the room, what a session command did.
+ *
+ * ── WHY A REPLY IS PART OF THE FEATURE AND NOT A NICETY ───────────────────────────────
+ *
+ * Everything else the relay does is witnessed by the agent answering: you know the wake
+ * landed because a reply appears. A session command produces NO agent turn — `/clear` is
+ * absorbed by the runtime's own TUI and says nothing back — so without this the sender
+ * sees precisely the same thing whether the command cleared their session, refused because
+ * the terminal is not in tmux, or was silently ignored because the relay is a version
+ * behind. That is the failure mode this codebase keeps writing comments about, and it would
+ * be the default here.
+ *
+ * So every outcome is reported, refusals included, and the wording distinguishes them. The
+ * message is posted AS THE SESSION, which is right: the session is the thing that did (or
+ * did not do) it, and a reply from anyone else would be a second voice in the room
+ * explaining somebody's terminal.
+ */
+async function postSessionReply(auth, conversationId, sessionName, text, request = api_1.apiRequest) {
+    await request(auth, "POST", `/api/device-api/conversations/${encodeURIComponent(conversationId)}/messages`, { session: sessionName, content: text });
+}

package/dist/relay/terminal-pane.js

@@ -0,0 +1,197 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.detectPane = detectPane;
+exports.verifyPane = verifyPane;
+exports.typeIntoPane = typeIntoPane;
+const child_process_1 = require("child_process");
+const profiles_1 = require("./profiles");
+/**
+ * Read the pane out of the environment — INSIDE the session, never in the daemon.
+ *
+ * Same principle as `runtimeBin` and `resumeId`: the process that is actually in the
+ * terminal is the only one that can answer, and the daemon guessing is how this codebase
+ * has been bitten before. `relay attach` runs in the session; its environment carries
+ * `$TMUX` and `$TMUX_PANE` (measured: `/tmp/tmux-1003/default,1381496,1` and `%1`, matching
+ * `display-message -p '#{pane_id}'` from outside).
+ *
+ * Every multiplexer we can RECOGNISE is returned, including ones we cannot yet type into.
+ * That is deliberate: "you are in screen, and tmux is what this supports" is a far better
+ * answer than the silence of not looking.
+ */
+function detectPane(env = process.env) {
+    const tmux = env.TMUX;
+    const tmuxPane = env.TMUX_PANE;
+    if (tmux && tmuxPane) {
+        // "<socket>,<server pid>,<session>" — only the first field addresses the server.
+        const socket = tmux.split(",")[0];
+        if (socket)
+            return { kind: "tmux", socket, pane: tmuxPane };
+    }
+    if (env.STY)
+        return { kind: "screen", session: env.STY, window: env.WINDOW ?? "0" };
+    if (env.ZELLIJ)
+        return { kind: "zellij", pane: env.ZELLIJ_PANE_ID };
+    return undefined;
+}
+/** The binary whose name must still be in the pane for a send to be allowed. */
+function expectedCommand(runtime) {
+    return (0, profiles_1.profileFor)(runtime)?.bin ?? runtime;
+}
+/**
+ * Is this pane still the session we recorded?
+ *
+ * ⚠️ THE CHECK THAT KEEPS THIS FROM BEING A REMOTE SHELL. A pane outlives the program in
+ * it: an agent that exited leaves a **shell prompt** on the same pane id, and typing into a
+ * shell is running a command. So the foreground command is compared against the runtime
+ * recorded at attach, and anything else — dead pane, different program, tmux not answering
+ * — is a refusal.
+ *
+ * `#{pane_current_command}` is the FOREGROUND process, which is what a keystroke would
+ * actually reach. Using it also means a pane sitting in a subprocess refuses rather than
+ * typing into that subprocess, which is fail-closed in the direction we want.
+ */
+function verifyPane(handle, runtime, run = (file, args) => (0, child_process_1.execFileSync)(file, args, { encoding: "utf8", timeout: 5_000 }), ownerPid) {
+    if (handle.kind === "zellij") {
+        return {
+            ok: false,
+            reason: "this session is running in zellij, which cannot be typed into yet — tmux and screen can.",
+        };
+    }
+    if (handle.kind === "screen") {
+        // SCREEN CANNOT BE ASKED WHAT IS RUNNING IN A WINDOW. tmux answers
+        // `#{pane_current_command}`; screen has no equivalent, and `screen -ls` says only that
+        // a session exists. So the same question is put to the PROCESS instead: is the runtime
+        // this session recorded at attach still alive, and still that runtime?
+        //
+        // This is a weaker check than tmux's in one specific way, and it is worth naming: it
+        // proves the agent is RUNNING, not that it is the foreground program of that window.
+        // A human who switched that window to a shell would be typed at. The window number is
+        // pinned from `$WINDOW` precisely to keep that to the window the agent started in.
+        if (ownerPid === undefined) {
+            return { ok: false, reason: "this screen session did not record its runtime process, so it cannot be typed into safely." };
+        }
+        return runtimeStillRunning(ownerPid, runtime, run);
+    }
+    let out;
+    try {
+        out = run("tmux", [
+            "-S",
+            handle.socket,
+            "display-message",
+            "-p",
+            "-t",
+            handle.pane,
+            "#{pane_dead} #{pane_current_command}",
+        ]).trim();
+    }
+    catch (err) {
+        return {
+            ok: false,
+            reason: `tmux could not find pane ${handle.pane} any more (${errText(err)}).`,
+        };
+    }
+    const [dead, current] = out.split(/\s+/);
+    if (dead !== "0")
+        return { ok: false, reason: `pane ${handle.pane} has exited.` };
+    const want = expectedCommand(runtime);
+    if (current !== want) {
+        return {
+            ok: false,
+            reason: `pane ${handle.pane} is running ${current ?? "nothing"}, not ${want} — refusing to type into it.`,
+        };
+    }
+    return { ok: true };
+}
+/**
+ * Is `pid` still running, and still the runtime we recorded?
+ *
+ * Both halves matter. A pid alone proves nothing — pids are reused, and the reused one is
+ * exactly as likely to be a shell as anything else. The command name is what makes it an
+ * identification rather than a hope.
+ */
+function runtimeStillRunning(pid, runtime, run) {
+    const want = expectedCommand(runtime);
+    let comm;
+    try {
+        comm = run("ps", ["-p", String(pid), "-o", "comm="]).trim();
+    }
+    catch {
+        return { ok: false, reason: `the ${want} process for this session is no longer running.` };
+    }
+    if (!comm)
+        return { ok: false, reason: `the ${want} process for this session has exited.` };
+    // `comm` is truncated to 15 characters by the kernel, so compare on that basis rather
+    // than demanding equality — "claude" and "codex" are short, but a longer runtime name
+    // would otherwise never match itself.
+    if (comm !== want && !want.startsWith(comm)) {
+        return { ok: false, reason: `that process is ${comm}, not ${want} — refusing to type into it.` };
+    }
+    return { ok: true };
+}
+/**
+ * ⚠️ Characters that must never reach a multiplexer's "type this" command.
+ *
+ * `screen -X stuff` parses `^X` as a control character and `\` as an escape, so a string
+ * containing either would send something other than itself. Our text comes from a fixed
+ * table and contains neither — this refuses anyway, because the day somebody adds a row
+ * with a backslash in it is the day that stops being true, and a test failing is a much
+ * better outcome than a control character being typed into a terminal.
+ */
+const UNSAFE_TO_TYPE = /[\^\\\r\n\x00-\x1f]/;
+/**
+ * Type one line into the pane and press Enter.
+ *
+ * ⚠️ `-l` IS LOAD-BEARING. Without it `send-keys` reads its arguments as KEY NAMES, so text
+ * containing `C-c` or `Escape` would be a signal rather than characters. With it the string
+ * is sent literally and Enter is a separate, deliberate key.
+ *
+ * `text` must come from the command table in `session-commands.ts` and NEVER from a chat
+ * message. That is the rule the whole feature rests on: the wire carries a command NAME,
+ * and the keystrokes are ours. There is deliberately no argument here that a message could
+ * reach.
+ */
+async function typeIntoPane(handle, runtime, text, deps = {}) {
+    // Checked BEFORE the pane, so a bad row fails on every machine rather than only on the
+    // multiplexer that would have mangled it.
+    if (UNSAFE_TO_TYPE.test(text)) {
+        return { ok: false, reason: "that command contains characters that must never be typed into a terminal." };
+    }
+    const verify = deps.verify ?? verifyPane;
+    const check = verify(handle, runtime, undefined, deps.ownerPid);
+    if (!check.ok)
+        return check;
+    const exec = deps.exec ?? runQuietly;
+    try {
+        if (handle.kind === "tmux") {
+            // `-l` sends the string LITERALLY. Without it send-keys reads its arguments as key
+            // NAMES, so text containing `C-c` would be a signal rather than characters.
+            await exec("tmux", ["-S", handle.socket, "send-keys", "-t", handle.pane, "-l", "--", text]);
+            await exec("tmux", ["-S", handle.socket, "send-keys", "-t", handle.pane, "Enter"]);
+            return { ok: true };
+        }
+        if (handle.kind === "screen") {
+            // `-p <window>` pins the window the agent started in; screen's "current window" is
+            // whichever the human last looked at, which is not the same thing.
+            //
+            // Enter goes as its own `stuff` of `^M`, which screen reads as a carriage return.
+            // That is the one place a `^` is deliberate — and it is ours, never a message's:
+            // `UNSAFE_TO_TYPE` above guarantees the text itself carries none.
+            const at = ["-S", handle.session, "-p", handle.window, "-X", "stuff"];
+            await exec("screen", [...at, text]);
+            await exec("screen", [...at, "^M"]);
+            return { ok: true };
+        }
+        return { ok: false, reason: `${handle.kind} cannot be typed into yet.` };
+    }
+    catch (err) {
+        return { ok: false, reason: `${handle.kind} refused the keystrokes: ${errText(err)}` };
+    }
+}
+function runQuietly(file, args) {
+    return new Promise((resolve, reject) => {
+        (0, child_process_1.execFile)(file, args, { timeout: 5_000 }, (err) => (err ? reject(err) : resolve()));
+    });
+}
+function errText(err) {
+    return err instanceof Error ? err.message : String(err);
+}

package/dist/relay/types.js

@@ -1,11 +1,2 @@
 "use strict";
-/**
- * Shared types for the relay daemon.
- *
- * The relay's job is narrow: hold `/updates`, decide which local session an
- * event belongs to, and wake that session — once, never twice concurrently.
- * It deliberately does NOT decide whether the session should reply. That
- * judgement is the server's (`shouldRespond`) and the woken session's; the
- * relay only carries the message across the process boundary.
- */
 Object.defineProperty(exports, "__esModule", { value: true });

package/dist/runtime-install.js

@@ -39,6 +39,7 @@ const fs = __importStar(require("fs"));
 const os = __importStar(require("os"));
 const path = __importStar(require("path"));
 const runtimes_1 = require("./runtimes");
+const skill_bootstrap_1 = require("./skill-bootstrap");
 /**
  * Install a runtime's BayChat skill/command.
  *
@@ -61,11 +62,17 @@ function installRuntimeCommand(runtime, home = os.homedir()) {
         needsRestart: spec.needsRestart,
     };
     if (!spec.command) {
-        return { ...base, written: null, skipped: spec.fallback ?? "no command mechanism for this runtime" };
+        return {
+            ...base,
+            written: null,
+            skipped: spec.fallback ?? "no command mechanism for this runtime",
+        };
     }
     const dir = path.join(home, spec.command.dir);
     const file = path.join(dir, spec.command.file);
-    const body = spec.command.render((0, runtimes_1.commandContextFor)(runtime));
+    const body = runtime === "codex" || runtime === "claude"
+        ? (0, skill_bootstrap_1.renderSkillBootstrap)(runtime)
+        : spec.command.render((0, runtimes_1.commandContextFor)(runtime));
     fs.mkdirSync(dir, { recursive: true });
     // Back up a hand-edited skill rather than silently overwriting it — the user
     // may have tuned the room rules for their own setup.

package/dist/runtimes.js

@@ -31,6 +31,7 @@ const help_topics_1 = require("./help-topics");
 const tool_defs_1 = require("./tool-defs");
 const claude_onboarding_1 = require("./claude-onboarding");
 const codex_onboarding_1 = require("./codex-onboarding");
+const session_setup_1 = require("./session-setup");
 exports.RUNTIMES = [
     "claude",
     "codex",
@@ -38,6 +39,7 @@ exports.RUNTIMES = [
     "desktop",
     "pi",
     "hermes",
+    "dsh",
     "generic",
 ];
 const GENERIC_RESUME_NOTE = `The relay can only wake this session while \`attach\` is running. Re-arm it after
@@ -202,6 +204,8 @@ Answering in the wrong room is the worst failure this feature has.
 
 ${help_topics_1.ROOMS_TOPIC}
 
+${ctx.runtime === "claude" || ctx.runtime === "codex" ? (0, session_setup_1.sessionSetupSteps)(ctx.runtime) : ""}
+
 ## Steps
 
 ${ctx.runtime === "claude"
@@ -480,6 +484,18 @@ DELIVERY PENDING and waits for a human — re-arm attach after every wake, witho
         fallback: "Hermes is a self-hosted agent: it authenticates with its own agent token and long-polls for messages, so there is nothing to install on this machine. Pair it from the app, then add BayChat under `mcp_servers:` in ~/.hermes/config.yaml to give it tools.",
         needsRestart: false,
     },
+    dsh: {
+        id: "dsh",
+        label: "DeepSeek Harness",
+        mcp: { kind: "manual", describe: "merged into ~/.dsh/cordis.patch.yml by `baychat connect dsh`" },
+        // ~/.dsh/skills is rank 400 in dsh's skill search and ~/.agents/skills is 500 [source], so
+        // this copy SHADOWS a Codex skill a client already has — which would tell dsh to attach as
+        // `--runtime codex`. It must be written here, never shared with the Codex file.
+        command: { dir: ".dsh/skills/baychat", file: "SKILL.md", frontmatter: true, render: (ctx) => renderCommand(ctx, true) },
+        invocation: '/baychat <name> ["<Group Title>"]',
+        relay: { runtime: "dsh", reArm: "background-every-wake", resumeNote: GENERIC_RESUME_NOTE },
+        needsRestart: true,
+    },
     generic: {
         id: "generic",
         label: "Generic MCP client",

package/dist/session-command.js

@@ -7,6 +7,7 @@ const streamableHttp_js_1 = require("@modelcontextprotocol/sdk/client/streamable
 const config_1 = require("./config");
 const session_name_1 = require("./session-name");
 const owner_pid_1 = require("./relay/owner-pid");
+const terminal_pane_1 = require("./relay/terminal-pane");
 const profiles_1 = require("./relay/profiles");
 const message_format_1 = require("./relay/message-format");
 const commands_1 = require("./relay/commands");
@@ -69,15 +70,16 @@ async function cmdJoinSession(args) {
     const joining = Boolean(options.session || options.group || options.destination);
     const runtime = options.runtime ?? (0, owner_pid_1.detectRuntime)(profiles_1.RUNTIME_PROFILES);
     if (joining && !runtime)
-        throw new Error("Cannot detect this runtime. Pass --runtime codex or --runtime claude.");
+        throw new Error("Cannot detect this runtime. Pass --runtime codex, --runtime claude, --runtime cursor, or --runtime dsh.");
     if (runtime === "hermes") {
         throw new Error("Hermes is a persistent agent. Use baychat connect hermes.");
     }
     if (joining &&
         runtime !== "codex" &&
         runtime !== "claude" &&
-        runtime !== "cursor") {
-        throw new Error("Supported coding runtimes: codex, claude, cursor.");
+        runtime !== "cursor" &&
+        runtime !== "dsh") {
+        throw new Error("Supported coding runtimes: codex, claude, cursor, dsh.");
     }
     let name = joining
         ? (options.session ?? (await (0, session_name_1.automaticSessionName)(runtime)))
@@ -189,6 +191,17 @@ async function cmdJoinSession(args) {
         return 1;
     }
     console.log("Connecting incoming messages…");
+    // SAID AT JOIN, NOT AT FAILURE. `/clear` and `/new` from the app work by typing into
+    // this session's terminal, which needs a multiplexer pane to address (see
+    // relay/terminal-pane.ts). Somebody who learns that only when a command refuses has
+    // already been let down once; one line here is the whole difference.
+    // ONE LINE, AND ONLY WHEN IT IS ACTIONABLE. `baychat start` puts an agent somewhere these
+    // commands can reach without anybody learning what a multiplexer is, so the note names
+    // the one word that fixes it and never the machinery underneath.
+    const pane = (0, terminal_pane_1.detectPane)();
+    if (!pane) {
+        console.log("Note: /clear and /new from the app cannot reach this session. Start it with `baychat` next time and they will. Everything else works either way.");
+    }
     const attach = () => (0, commands_1.cmdRelayAttach)({
         session: name,
         runtime: runtime,

package/dist/session-setup.js

@@ -0,0 +1,38 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.sessionSetupSteps = sessionSetupSteps;
+/** One setup policy for both coding clients; their delivery adapters remain distinct. */
+function sessionSetupSteps(runtime) {
+    const reload = runtime === "claude"
+        ? "Open /mcp, select baychat and Reconnect. If tools are still missing, restart Claude and resume this conversation."
+        : "Restart Codex and resume this conversation to load the configured BayChat tools.";
+    return `## Automatic setup — the session does it
+
+If the required tools are already available, skip setup. Use the live remote MCP
+connection; an expired local login alone does not mean that connection is broken.
+For Codex the required chat tools are \`get_messages\` and \`send_message\`;
+Claude also needs the native listener tools listed in its join steps below.
+Search deferred tools once when needed, before creating membership.
+
+If required BayChat tools are missing, or the owner asks to configure this runtime,
+run \`baychat connect ${runtime} --start\` yourself in the session's terminal, once.
+Do not ask the user to run connect. It reuses a valid device login and configures
+MCP plus this skill. With no usable login it prints an approval link and exits 2;
+show that link immediately and wait for approval, without a waiting terminal.
+After approval run \`baychat connect ${runtime} --finish\` once. If still pending,
+show the link and wait; do not poll. Report other failures briefly and stop.
+
+After setup succeeds, use the host's reconnect facility if exposed, then search
+the deferred tools once more. If they remain unavailable, show this one action:
+"${reload}" Keep the original session name and group for the retry.
+Do not restart the host yourself, extract tokens, hand-write JSON-RPC, or run a
+local MCP server as a workaround. A host reload is not another login.
+
+For an actual authentication refusal, first use the connection's own authorization
+link if provided. For a CLI device login, use the same --start/--finish flow above.
+Do not infer a remote authentication failure from a local credential file.
+
+Confirm a successful join in one line: the name, room and actual delivery state.
+Keep routine setup narration out of chat; explain only a failure or required action.
+`;
+}

package/dist/skill-bootstrap.js

@@ -0,0 +1,47 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.renderSkillBootstrap = renderSkillBootstrap;
+/** Keep the installed entry point stable while npm supplies the current workflow. */
+function renderSkillBootstrap(runtime) {
+    const invocation = runtime === "codex" ? "$baychat" : "/baychat";
+    const tools = runtime === "claude"
+        ? "allowed-tools:\n  - Bash\n  - Monitor\n  - mcp__baychat\n"
+        : "";
+    return `---
+name: baychat
+description: Join this coding session to BayChat, chat with agents, or update BayChat from this session.
+${tools}---
+
+# BayChat
+
+Use \`${invocation} <name> --group "<title>"\` to join, or
+\`${invocation} --update\` to update. Preserve the user's name and group literally.
+
+For each join or other non-update request, run \`baychat skill --runtime ${runtime}\` in the session's
+terminal and follow the current workflow it returns. This reads local package
+instructions; it does not log in, join a room, or start a receiver. Do not inspect
+installed source or credential files. Package updates supply the new workflow
+automatically; there is no separate skill-refresh command for the user.
+
+For an update request (\`--update\`), run \`baychat update\` and report what it prints.
+That one command does every part: the npm package, every connected client's config, and
+a relay restart. The relay is the step that matters most and the easiest to miss — a
+running daemon holds its old code in memory, so an npm install alone leaves the machine
+on the previous version with nothing saying so.
+
+Do not run npm yourself, and do not run the steps separately. A sequence the model has
+to remember is a sequence the model will one day do half of; \`baychat update\` is
+idempotent, refreshes only what is already connected, and never sets anything up.
+If BayChat is not installed at all, install it once with
+\`npm install --global baychat@latest\` and retry. Stop on failure with its short error;
+do not retry installs or change npm permissions.
+
+On an update-only request, stop after reporting — do not load the join workflow, join, or
+send messages. If a join was also requested, load the new workflow afterwards and keep the
+original name and group.
+
+Missing MCP setup is handled by the returned workflow inside this session.
+Do not ask the user to run connect. Authentication approvals and host reloads
+may need the user; show the exact link or single required action promptly.
+`;
+}