baychat 0.16.0 → 0.17.1

package/dist/connect.js

@@ -32,8 +32,10 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
 };
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.renderConnectMenu = renderConnectMenu;
+exports.isClaudeConnectTarget = isClaudeConnectTarget;
 exports.parseConnectClient = parseConnectClient;
 exports.writeClientConfig = writeClientConfig;
+exports.cmdConnectClaude = cmdConnectClaude;
 exports.cmdConnect = cmdConnect;
 const node_fs_1 = __importDefault(require("node:fs"));
 const node_path_1 = __importDefault(require("node:path"));
@@ -61,14 +63,32 @@ function renderConnectMenu() {
         "Connect this laptop to BayChat, once, and configure your client:",
         "",
         ...rows,
+        "  npx baychat connect claude  → Claude Code (refreshes its skill)",
         "",
         "You approve a QR on your phone. After that, in any coding session:",
         "",
         "  /baychat <name>        join BayChat as a session called <name>",
         "",
-        "Claude Code needs no config — `npx baychat login` sets it up for you.",
+        "First-time Claude Code setup is `npx baychat login` — it registers the MCP",
+        "server AND writes the skill. After that, `connect claude` refreshes the skill",
+        "on its own: no QR, no re-pairing. Run it after every CLI upgrade.",
     ].join("\n");
 }
+/** Spellings of Claude Code accepted by `connect`. */
+const CLAUDE_CONNECT_ALIASES = new Set(["claude", "claude-code", "claudecode"]);
+/**
+ * Is this `connect` argument Claude Code?
+ *
+ * Claude Code is deliberately NOT in `MCP_CLIENTS`: that list is clients whose
+ * MCP config is a file we write, and Claude Code's is registered by
+ * `claude mcp add` instead. But refusing the word entirely made the runtime this
+ * product is mostly used from the only one you could not `connect` — and sent a
+ * user whose credential was perfectly valid to `login`, which opens a pairing QR,
+ * when all they needed was the skill file refreshed after a CLI upgrade.
+ */
+function isClaudeConnectTarget(value) {
+    return CLAUDE_CONNECT_ALIASES.has(value.trim().toLowerCase());
+}
 /**
  * Narrow a client argument.
  *
@@ -159,11 +179,38 @@ const realIo = {
  *
  * @returns 0 on success, 2 when the laptop login expired without approval.
  */
+/**
+ * `baychat connect claude` — refresh Claude Code's skill.
+ *
+ * Deliberately does NOT touch the credential or the MCP registration. Both are
+ * `login`'s job, and re-doing them would put a device-pairing QR in front of
+ * somebody whose login is fine. Writing the skill needs no auth at all: it is
+ * generated locally from this CLI's own version, which is exactly why it goes
+ * stale on upgrade and exactly why this command has to exist.
+ */
+function cmdConnectClaude() {
+    try {
+        for (const line of (0, runtime_install_1.describeInstall)((0, runtime_install_1.installRuntimeCommand)("claude")))
+            console.log(`  ${line}`);
+        console.log("");
+        console.log("  Restart Claude Code once so it picks the skill up.");
+        console.log("  Not logged in yet? `npx baychat login` — that registers the MCP server too.");
+        return 0;
+    }
+    catch (err) {
+        console.log(`Could not install the Claude Code skill: ${err instanceof Error ? err.message : String(err)}`);
+        return 1;
+    }
+}
 async function cmdConnect(clientArg, opts = {}) {
     if (clientArg === undefined) {
         console.log(renderConnectMenu());
         return 0;
     }
+    // Claude Code first: it is not an MCP-config client, so it must not reach
+    // `parseConnectClient`, which would reject it.
+    if (isClaudeConnectTarget(clientArg))
+        return cmdConnectClaude();
     const client = parseConnectClient(clientArg);
     const base = (opts.base || process.env.BAYCHAT_API_URL || config_1.DEFAULT_API_URL).replace(/\/$/, "");
     const steps = (0, connect_plan_1.planConnect)({

package/dist/relay/commands.js

@@ -746,7 +746,7 @@ async function cmdRelayAttach(opts) {
  * bare name, which is exactly the behaviour that shipped before this existed — a
  * machine where PATH is fine keeps working, and one where it is not now works too.
  */
-function resolveRuntimeBin(runtime) {
+function resolveRuntimeBin(runtime, env = process.env, execPath = process.execPath) {
     // Delegates to the prover rather than walking PATH itself. The hand-rolled
     // walk this replaces had two Windows faults, and both produced a recorded
     // path the daemon could never spawn:
@@ -763,7 +763,7 @@ function resolveRuntimeBin(runtime) {
     // `resolveRuntimeBinary` tries the platform's real extension order and PROVES
     // each candidate by running it, which is the same question this function was
     // always asking — just answered correctly.
-    const decided = decideRuntimeBin(runtime);
+    const decided = decideRuntimeBin(runtime, env, execPath);
     return decided.ok ? decided.bin : undefined;
 }
 /**
@@ -775,16 +775,16 @@ function resolveRuntimeBin(runtime) {
  * then re-probed could still register `runtimeBin: undefined` — the exact state
  * the guard exists to prevent, reached by way of the guard.
  */
-function decideRuntimeBin(runtime) {
-    const override = process.env[`BAYCHAT_${runtime.toUpperCase()}_BIN`];
-    const resolved = (0, runtime_binary_1.resolveRuntimeBinary)(runtime, (0, runtime_binary_1.currentBinaryEnv)(override));
+function decideRuntimeBin(runtime, env = process.env, execPath = process.execPath) {
+    const override = env[`BAYCHAT_${runtime.toUpperCase()}_BIN`];
+    const resolved = (0, runtime_binary_1.resolveRuntimeBinary)(runtime, (0, runtime_binary_1.currentBinaryEnv)(override, env, execPath));
     if (!resolved.ok) {
         // An explicit override is a user ASSERTION. If it cannot be proven, stop —
         // see the guard in `cmdRelayAttach`. Absence of one is not an assertion, so
         // a plain failed probe keeps the best-effort fallback.
         if (override)
             return { ok: false, reason: (0, runtime_binary_1.summarizeResolutionFailure)(resolved) };
-        return { ok: true, bin: managedRuntimeBin(runtime) };
+        return { ok: true, bin: managedRuntimeBin(runtime, env) };
     }
     try {
         // Resolve symlinks: ~/.local/bin/claude is typically a link into a versioned
@@ -797,10 +797,10 @@ function decideRuntimeBin(runtime) {
         return { ok: true, bin: resolved.path };
     }
 }
-function managedRuntimeBin(runtime) {
+function managedRuntimeBin(runtime, env = process.env) {
     if (runtime !== "codex")
         return undefined;
-    const root = process.env.CODEX_MANAGED_PACKAGE_ROOT?.trim();
+    const root = env.CODEX_MANAGED_PACKAGE_ROOT?.trim();
     if (!root)
         return undefined;
     const candidate = path.join(root, "bin", "codex.js");

package/dist/runtime-binary.js

@@ -41,6 +41,7 @@ exports.currentBinaryEnv = currentBinaryEnv;
 exports.summarizeResolutionFailure = summarizeResolutionFailure;
 const child_process_1 = require("child_process");
 const fs = __importStar(require("fs"));
+const spawn_env_1 = require("./relay/spawn-env");
 /**
  * Resolve a runtime's executable, proving each candidate before accepting it.
  *
@@ -231,12 +232,30 @@ function firstMeaningfulLine(text) {
  *
  * `shell: false` throughout: nothing here is ever concatenated into a command
  * line, and a PATH entry is attacker-adjacent data on a shared machine.
+ *
+ * THE PATH SEARCHED IS THE PATH THE SPAWN WILL USE, not this process's raw one.
+ * The daemon resolves a runtime and then starts it, and those two steps must
+ * agree about where binaries are. `headlessSpawnEnv` prepends the daemon's own
+ * node directory — required because an npm runtime is a `#!/usr/bin/env node`
+ * script and systemd's PATH has no node — and that directory is also where npm
+ * puts the runtime's own symlink.
+ *
+ * Resolving against the raw PATH instead picked a DIFFERENT binary than the one
+ * about to be launched. Measured 2026-09-01, daemon pid 41259: systemd's PATH
+ * carried no nvm and did carry `/snap/bin`, so a bare `codex` resolved to the
+ * confined snap build, which cannot read `~/.codex/sessions`. Every wake below
+ * the socket rung failed with `no rollout found for thread id`, naming a
+ * rollout file that was on disk the whole time. The queue rung and the headless
+ * rung share this lookup, so one wrong PATH took out both.
+ *
+ * Only BARE names reach here — an absolute `SessionTarget.runtimeBin` is never
+ * re-resolved, and that rule is unchanged.
  */
-function currentBinaryEnv(override) {
+function currentBinaryEnv(override, env = process.env, execPath = process.execPath) {
     const delimiter = process.platform === "win32" ? ";" : ":";
     return {
         platform: process.platform,
-        pathEntries: (process.env.PATH ?? "").split(delimiter),
+        pathEntries: ((0, spawn_env_1.headlessSpawnEnv)(env, execPath).PATH ?? "").split(delimiter),
         override,
         isExecutable(candidate) {
             try {
@@ -254,6 +273,24 @@ function currentBinaryEnv(override) {
                 timeout: PROBE_TIMEOUT_MS,
                 encoding: "utf8",
                 shell: false,
+                // THE PROBE MUST BE ABLE TO START WHAT IT IS PROBING.
+                //
+                // An npm runtime is a `#!/usr/bin/env node` script, and a spawn inherits
+                // THIS process's environment — the daemon's, under systemd, with no node
+                // on it. So probing the real binary died with
+                // `/usr/bin/env: 'node': No such file or directory`, the candidate was
+                // rejected as broken rather than unstartable, and resolution fell through
+                // to `/snap/bin/codex`.
+                //
+                // Measured 2026-09-01 18:00 from the daemon's log, after the PATH search
+                // was already fixed: `codex resolved to /snap/bin/codex (codex-cli
+                // 0.114.0)`, then `queue did not deliver ... this codex build has no
+                // \`queue\` subcommand`. The snap is 0.114.0; `queue` landed in 0.149.0.
+                // So a probe that could not start a shebang script cost Codex the one
+                // rung a live session can answer on.
+                //
+                // Same environment the spawn will use, for the same reason.
+                env: (0, spawn_env_1.headlessSpawnEnv)(env, execPath),
             });
             return summarizeProbe({
                 status: run.status,

package/dist/runtimes.js

@@ -108,6 +108,55 @@ failure. Arm once, then get on with your work.
 If you are ever unsure whether the relay knows you, run \`baychat relay status\`:
 you are reachable when your session is listed with a resume id, whether or not
 anything is attached.`;
+    }
+    if (reArm === "supervised-loop") {
+        // WHO runs attach again is the whole fix — attach itself is unchanged.
+        //
+        // `attach` is one-shot on purpose: it exits on a wake, and that exit is what
+        // re-invokes the session. Until 2026-09-01 the thing that ran it again was
+        // the MODEL, instructed here to remember after every turn. One interrupted
+        // turn and the session is deaf, silently and for good.
+        //
+        // A persistent Monitor runs for the LIFETIME of the session and turns every
+        // line of output into an event in the agent's conversation. So a loop around
+        // attach re-arms it in the same second it exits, supervised by the harness
+        // instead of remembered by the model. NO `--timeout` here: it would make the
+        // loop spin, and the blocking wait is exactly what we want.
+        return `## Staying reachable — arm the loop once
+
+If \`baychat relay\` is running on this machine (\`baychat connect\` starts it), start
+this ONCE with the **Monitor** tool, as soon as you have joined — \`persistent: true\`:
+
+\`\`\`
+while true; do
+  ${attachLine} 2>&1 \\
+    | grep --line-buffered -E "^WAKE|^  \\(|error|refused|denied|not reachable"
+  sleep 1
+done
+\`\`\`
+
+**Run it exactly as written.** Keeping the whole attach line verbatim — the flags
+included — is the difference between the relay continuing THIS conversation and it
+starting a stranger with no memory of the room.
+
+**Why a loop.** \`attach\` blocks until a message arrives, prints it, and **exits** —
+one-shot, because that exit is what causes you to be invoked again. The loop runs
+it again immediately, so you are armed again before you have even read the message.
+
+**You never re-arm this by hand.** That is the entire point. A persistent Monitor
+lives as long as your session, and the harness supervises it — not you. Do not
+add \`--timeout\`; the blocking wait is what makes it work.
+
+${resumeNote}
+
+**It also survives an interrupt.** Stopping a task in your harness kills a
+backgrounded attach from outside the process — nothing fails and nothing prints,
+and the old advice ("re-arm after every wake") never covered it. The Monitor is a
+separate supervised task, so it keeps listening.
+
+If you are ever unsure, run \`baychat relay status\`: you are reachable when your
+session reads \`attached\`, and \`NOTHING IS LISTENING\` means the loop is not running —
+start it again.`;
     }
     return `## Staying reachable — re-arm every time
 
@@ -296,13 +345,13 @@ exports.RUNTIME_SPECS = {
         // Bash tool call and equals the id of the transcript the session is writing,
         // which is exactly what `claude --resume` takes.
         relay: {
-            reArm: "background-every-wake",
+            reArm: "supervised-loop",
             runtime: "claude",
             sessionIdExpr: "$CLAUDE_CODE_SESSION_ID",
             resumeNote: `Keep the \`--resume-id\` flag: \`$CLAUDE_CODE_SESSION_ID\` is your own session id,
 and it is what lets the relay run \`claude -p --resume\` and continue THIS conversation
-rather than start a stranger with no memory of the room. Re-arm attach after every
-wake anyway — resuming is the fallback, not the plan.`,
+rather than start a stranger with no memory of the room. Resuming is the fallback
+for a session that has genuinely ended, not the plan for one that is still open.`,
         },
         needsRestart: false,
     },

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "baychat",
-  "version": "0.16.0",
-  "description": "BayChat connector CLI \u2014 pair an agent session (Claude Code, Codex) with BayChat and chat in groups",
+  "version": "0.17.1",
+  "description": "BayChat connector CLI — pair an agent session (Claude Code, Codex) with BayChat and chat in groups",
   "bin": {
     "baychat": "dist/index.js"
   },