viber-channel 0.8.9 → 0.8.11

package/lib/cli_bow_out.ts

@@ -0,0 +1,46 @@
+/**
+ * Bow-out decision: should this process yield the channel to the PLUGIN copy? (#365, #495)
+ *
+ * WHY THE GUARD EXISTS (#365 / #280 step-29). In an AGENT session (a vibe-master
+ * terminal) the channel must be the PLUGIN copy — only it can inject inbound
+ * messages. The manually-registered viber-dev-channel MCP loads in the same
+ * session with the same env; rather than race it for the channel lock, it bows
+ * out deterministically. Normal sessions (no VIBER_CHANNEL_AGENT_SESSION) are
+ * unaffected.
+ *
+ * WHY IT ONLY CONCERNS THE MCP SERVER MODE (#495). A CLI subcommand
+ * (`enroll-runner`, `run-runner`, `connect`, `--help`) serves no tool and takes
+ * no channel lock, so it cannot conflict with the plugin copy. Evaluating this
+ * guard before the subcommand dispatch made every subcommand exit 0 without
+ * doing anything inside an agent session — silent, and falsely successful. The
+ * call site therefore sits AFTER the dispatch block; see viber-channel.ts.
+ *
+ * The dev-backend exclusion is DERIVED from the environment (single source of
+ * truth, isDevBackend) rather than trusting VIBER_CHANNEL_AGENT_SESSION not to
+ * leak from the parent shell: on the dev backend there is NO plugin to yield to
+ * (it is disabled in this repo, #365), so yielding would mean no channel at all
+ * (`-32000`, no registration).
+ */
+import { isDevBackend } from "./auth.ts";
+
+/**
+ * Pure function of the environment — takes the env explicitly so it is testable
+ * without mutating `process.env`.
+ *
+ * `VIBER_BASE_URL` is defaulted to `""` HERE, deliberately: `isDevBackend()`
+ * falls back to `process.env` when its argument is `undefined`, which would let
+ * the real environment of a test runner decide the outcome.
+ */
+export function shouldBowOutToPlugin(
+  env: Record<string, string | undefined>,
+): boolean {
+  return (
+    !isDevBackend(env.VIBER_BASE_URL ?? "") &&
+    env.VIBER_CHANNEL_AGENT_SESSION === "1" &&
+    env.VIBER_CHANNEL_PLUGIN !== "1"
+  );
+}
+
+/** The stderr line emitted when the process bows out. Shared with the tests. */
+export const BOW_OUT_MESSAGE =
+  "[viber-channel] agent session: yielding to the plugin channel copy (manual MCP registration exits)\n";

package/lib/codex_shell_path.ts

@@ -0,0 +1,119 @@
+/**
+ * codex_shell_path — #500: let codex spawn processes on Windows again.
+ *
+ * codex's Windows sandbox launches every command under a RESTRICTED TOKEN
+ * (`CreateProcessAsUserW`). Windows refuses to start an MSIX-PACKAGED binary
+ * that way, and the shell codex resolves on JP's machine is PowerShell 7 from
+ * the Microsoft Store — packaged under `C:\Program Files\WindowsApps\…`. So
+ * every command died with:
+ *
+ *   windows sandbox: runner failed during SpawnChild:
+ *   CreateProcessAsUserW failed: 5 (Access is denied.)
+ *
+ * Measured, 20 trials per case (success = absence of `CreateProcessAsUserW`),
+ * reproduced independently by a second agent:
+ *
+ *   | target                                  | spawn failures |
+ *   | pwsh MSIX (package dir OR alias dir)    | 20/20          |
+ *   | powershell 5.1 / cmd.exe / git bash     |  0/20          |
+ *
+ * FIX: drop the `WindowsApps` directories from the PATH of the `codex
+ * app-server` CHILD ONLY. codex then resolves `powershell.exe` 5.1 and spawns
+ * fine (measured end to end: `hello_from_shell`, exit 0, 722 ms).
+ *
+ * REJECTED — `-c windows.sandbox="unelevated"`. It also fixes the spawn (0/20
+ * failures on the MSIX target), but it switches the sandbox to the legacy
+ * backend, and that has two measured costs:
+ *   - PowerShell drops to **ConstrainedLanguage** (5/5, both agents): .NET
+ *     method calls, `Add-Type` and type casts fail in agent scripts;
+ *   - codex's own binary states that "Restricted read-only access requires the
+ *     elevated Windows sandbox backend" — our `read`/`chat` tiers rely on the
+ *     read-only sandbox, so they would be SILENTLY weakened, and any future
+ *     deny-read path (`.viber/auth.json`, `~/.ssh`) would be a no-op.
+ * Writes outside the workspace stay blocked in both modes, so the tradeoff is
+ * not about writes — it is about keeping the backend our tiers are built on.
+ */
+
+/**
+ * A PATH entry that resolves to Store/MSIX app-execution aliases.
+ *
+ * Anchored on a whole path SEGMENT: a substring match would also strip
+ * `C:\SDK\WindowsAppsSDK\bin` and nobody would understand why six months later.
+ * The two real cases stay covered — the package dir and
+ * `%LOCALAPPDATA%\Microsoft\WindowsApps`.
+ */
+function isWindowsAppsEntry(entry: string): boolean {
+	return /[\\/]windowsapps([\\/]|$)/i.test(entry.replace(/[\\/]+$/, ""));
+}
+
+export interface SanitizeResult {
+	/** The PATH to hand the child. Unchanged when no surgery was needed. */
+	path: string;
+	/** Entries removed, in their original order. Empty when nothing changed. */
+	stripped: string[];
+	/** Set when surgery was NEEDED but deliberately skipped — worth logging. */
+	skipped?: string;
+}
+
+/**
+ * Remove the MSIX alias directories from a PATH — but only on Windows, and only
+ * when no unpackaged `pwsh.exe` is REACHABLE, i.e. sits on a surviving PATH
+ * entry. An MSI PowerShell 7 that exists on disk but is not on the PATH does
+ * NOT count: codex resolves its shell through the PATH, so it would still land
+ * on the broken packaged one (raised in review — we do not have a measurement
+ * showing codex probes fixed locations, so we must not assume it does).
+ *
+ * Pure: platform, PATH and filesystem probing are all injected, so this never
+ * depends on the machine running the test.
+ */
+export function sanitizeCodexPath(
+	pathValue: string | undefined,
+	opts: { platform: string; exists: (p: string) => boolean; sep?: string },
+): SanitizeResult {
+	const sep = opts.sep ?? ";";
+	const original = pathValue ?? "";
+	if (opts.platform !== "win32") return { path: original, stripped: [] };
+
+	const entries = original.split(sep);
+	const kept = entries.filter((e) => !isWindowsAppsEntry(e));
+	const stripped = entries.filter((e) => isWindowsAppsEntry(e) && e.trim() !== "");
+	if (stripped.length === 0) return { path: original, stripped: [] };
+
+	// An unpackaged pwsh on a surviving entry means codex already has a shell it
+	// can spawn — leave the PATH intact so the child keeps its Store aliases
+	// (python stub, wt, …).
+	const onKeptPath = (exe: string): boolean =>
+		kept.some((dir) => dir.trim() !== "" && opts.exists(`${dir.replace(/[\\/]+$/, "")}\\${exe}`));
+	if (onKeptPath("pwsh.exe")) return { path: original, stripped: [] };
+
+	// Floor: if not even cmd.exe survives the surgery, codex would have no shell
+	// to fall back on — stripping would cost the Store aliases for nothing.
+	// PowerShell 5.1 IS removable as an optional feature on recent Windows 11,
+	// so this is not purely theoretical. Do nothing, and say so.
+	if (!onKeptPath("cmd.exe") && !onKeptPath("powershell.exe")) {
+		return { path: original, stripped: [], skipped: "no unpackaged shell would remain on PATH" };
+	}
+
+	return { path: kept.join(sep), stripped };
+}
+
+/**
+ * Apply {@link sanitizeCodexPath} to a child environment, in place.
+ *
+ * Windows env keys are case-INSENSITIVE, a JS object's are not: a parent may
+ * carry `Path`, `PATH` or even `PaTh`, and handing the child two spellings of
+ * the same variable is asking for the wrong one to win. So we read whichever
+ * variant exists, then collapse them all into one canonical `PATH`.
+ */
+export function applySanitizedPath(
+	env: Record<string, string | undefined>,
+	opts: { platform: string; exists: (p: string) => boolean; sep?: string },
+): SanitizeResult {
+	const keys = Object.keys(env).filter((k) => k.toLowerCase() === "path");
+	const current = keys.map((k) => env[k]).find((v) => v !== undefined);
+	const result = sanitizeCodexPath(current, opts);
+	if (result.stripped.length === 0) return result;
+	for (const k of keys) delete env[k];
+	env.PATH = result.path;
+	return result;
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "viber-channel",
-  "version": "0.8.9",
+  "version": "0.8.11",
   "description": "Voice + text MCP channel between a Claude Code session and the Viber UI (https://viber.dgypx.dev). Push transcripts to Claude; send_message tool delivers text back to the UI.",
   "type": "module",
   "bin": {

package/viber-channel.ts

@@ -61,6 +61,7 @@ import { buildChannelInstructions, IDENTITY_BUDGET } from "./lib/channel_instruc
 import { CLAUDE_TOOL_DEFS } from "./lib/claude_tool_defs.ts";
 import { warnIfStale } from "./lib/version_check.ts";
 import { capabilitiesText } from "./lib/capabilities.ts";
+import { BOW_OUT_MESSAGE, shouldBowOutToPlugin } from "./lib/cli_bow_out.ts";
 
 // ---- CLI subcommand dispatch (must happen before lock acquire + loadAuth) ----
 //
@@ -68,32 +69,6 @@ import { capabilitiesText } from "./lib/capabilities.ts";
 // exits — it does not start the MCP server. Any other invocation (no args, or
 // the unknown subcommand) falls through to the MCP server below.
 {
-  // #280 step-29: in an AGENT session (vibe-master terminal), the channel must
-  // be the PLUGIN copy (`--channels plugin:viber-channel@…` — only it can
-  // inject inbound messages). The manually-registered viber-dev-channel MCP
-  // loads in the same session with the same env; instead of racing it for the
-  // channel lock, it bows out deterministically here. Normal sessions
-  // (no VIBER_CHANNEL_AGENT_SESSION) are unaffected.
-  //
-  // BUT the yield is a STAGING/PROD-only behavior: the plugin channel only runs
-  // there (it is disabled in the Viber dev repo, #365). On the DEV backend there
-  // is NO plugin to yield to, so yielding = no channel at all (`-32000`, no
-  // registration). Derive this from the environment (single source of truth,
-  // isDevBackend) instead of relying on VIBER_CHANNEL_AGENT_SESSION not leaking
-  // from the parent shell into the spawned dev terminal (the real bug: that var
-  // leaked and terminal.ts never cleared it, so the dev channel silently bowed
-  // out). Default (non-dev) behavior is unchanged.
-  if (
-    !isDevBackend() &&
-    process.env.VIBER_CHANNEL_AGENT_SESSION === "1" &&
-    process.env.VIBER_CHANNEL_PLUGIN !== "1"
-  ) {
-    process.stderr.write(
-      "[viber-channel] agent session: yielding to the plugin channel copy (manual MCP registration exits)\n",
-    );
-    process.exit(0);
-  }
-
   const sub = process.argv[2];
   if (sub === "--help" || sub === "-h") {
     process.stdout.write(
@@ -165,6 +140,23 @@ import { capabilitiesText } from "./lib/capabilities.ts";
   }
 }
 
+// ---- Bow-out guard (#365) — MCP SERVER MODE ONLY ----
+//
+// THIS ORDER IS SIGNIFICANT (#495): the guard must stay AFTER the dispatch block
+// above. Every branch of that block ends in `process.exit` on every path (catch
+// included), so reaching this line means "no subcommand was handled" — i.e. this
+// is an MCP server launch, the only mode where yielding to the plugin copy makes
+// sense. Evaluating it earlier (as it was) made `enroll-runner`, `run-runner` and
+// `connect` exit 0 without doing anything inside an agent session: silent, and
+// falsely successful. Do NOT hoist this back up. Rationale: lib/cli_bow_out.ts.
+//
+// It also sits BEFORE warnIfStale() so the yielding process makes no network
+// call on its way out.
+if (shouldBowOutToPlugin(process.env)) {
+  process.stderr.write(BOW_OUT_MESSAGE);
+  process.exit(0);
+}
+
 // Server path (fell through the dispatch block): warn if this install is behind
 // npm latest, but fire-and-forget so it never delays mcp.connect — the nudge
 // lands on stderr shortly after startup (#330).
@@ -363,9 +355,10 @@ process.stdin.on("end", () => {
 
 // ---- Auth from .viber/auth.json ----
 
+// isDevBackend is no longer imported here: its only use in this file was the
+// bow-out condition, now owned by lib/cli_bow_out.ts (#495).
 import {
   authFilePath,
-  isDevBackend,
   loadAuth,
   persistInstanceCredentials,
 } from "./lib/auth.ts";

package/viber-codex-bridge.ts

@@ -12,6 +12,7 @@ import { existsSync, mkdirSync, readFileSync, writeFileSync } from "node:fs";
 import { dirname, join } from "node:path";
 import { authFilePath, loadAuth } from "./lib/auth.ts";
 import { CONTRACT_STYLE_NEUTRAL, CONTRACT_STYLE_TOOLS } from "./lib/channel_instructions.ts";
+import { applySanitizedPath } from "./lib/codex_shell_path.ts";
 import {
   ConversationMintError,
   defaultLabel,
@@ -620,6 +621,32 @@ class CodexAppServer {
     const codexBin = process.env.VIBER_CODEX_BIN?.trim() || "codex";
     const args = ["app-server"];
     const childEnv = { ...process.env };
+    // #500: codex's Windows sandbox cannot spawn an MSIX-packaged shell (Store
+    // PowerShell 7) under a restricted token — every command died with
+    // CreateProcessAsUserW failed: 5. Drop the WindowsApps alias dirs from the
+    // CHILD's PATH so codex resolves powershell.exe 5.1 instead. The sandbox
+    // keeps its `elevated` backend, which our read-only tiers depend on.
+    // applySanitizedPath collapses every case-variant of the key into one
+    // canonical PATH — handing the child both `Path` and `PATH` would let the
+    // stale one win.
+    const sanitized = applySanitizedPath(childEnv, {
+      platform: process.platform,
+      exists: existsSync,
+    });
+    if (sanitized.stripped.length > 0) {
+      process.stderr.write(
+        `[viber-codex-bridge] #500: removed ${sanitized.stripped.length} MSIX alias dir(s) from the ` +
+          `codex child's PATH so it can spawn processes: ${sanitized.stripped.join(", ")}. ` +
+          "The child therefore loses the Store execution aliases — notably WINGET (and wt, ngrok, " +
+          "the WSL launchers); node/npm/bun/git/codex/python are unaffected. Installing PowerShell 7 " +
+          "from the MSI makes this surgery unnecessary.\n",
+      );
+    } else if (sanitized.skipped) {
+      process.stderr.write(
+        `[viber-codex-bridge] #500: MSIX alias dirs left on the codex child's PATH — ${sanitized.skipped}. ` +
+          "Commands may fail with CreateProcessAsUserW failed: 5; run scripts/repro-codex-spawn.ps1.\n",
+      );
+    }
     if (mcp) {
       args.push("-c", `mcp_servers.viber.url="${mcp.url}"`);
       args.push("-c", `mcp_servers.viber.bearer_token_env_var="${mcp.bearerEnvVar}"`);