baychat 0.16.0 → 0.17.0

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 {

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.0",
+  "description": "BayChat connector CLI — pair an agent session (Claude Code, Codex) with BayChat and chat in groups",
   "bin": {
     "baychat": "dist/index.js"
   },