kritya 0.8.40-beta → 0.8.42-beta

package/dist/commands/doctor.js

@@ -2,7 +2,7 @@ import fs from "node:fs";
 import os from "node:os";
 import path from "node:path";
 import { createRequire } from "node:module";
-import { BUILTIN_PROVIDERS, CONFIG_DIR, CONFIG_FILE, legacyGlobalModel, loadConfig, privacyModeFor, resolveProvider, } from "../config/config.js";
+import { BUILTIN_PROVIDERS, CONFIG_DIR, CONFIG_FILE, legacyGlobalModel, loadConfig, loadDotEnv, privacyModeFor, resolveProvider, } from "../config/config.js";
 import { DEFAULT_MODEL, contextWindowFor } from "../config/models.js";
 import { retentionDaysFor } from "../config/retention.js";
 import { assertJsonWithinLimits } from "../config/jsonSafety.js";
@@ -368,6 +368,13 @@ export async function runDoctorCli(argv, options = {}) {
     const offline = argv.includes("--offline");
     const dirArg = argv.find((a) => !a.startsWith("-"));
     const workspace = path.resolve(options.workspace ?? dirArg ?? ".");
+    // The user's own global .env is unconditionally trusted and is where the
+    // interactive and headless paths both pick up provider keys (see
+    // `runInteractive` in index.tsx and `runHeadless` in headless.ts). Without
+    // loading it here the provider check below sees only the ambient
+    // environment, so a key that lives solely in ~/.kritya/.env is reported as
+    // missing — a false "no API key" that also flips the exit code to 1.
+    loadDotEnv([path.join(CONFIG_DIR, ".env")]);
     const sections = await collectDiagnostics({ ...options, workspace, offline });
     const report = summarize(sections, workspace);
     if (json) {

package/dist/index.js

@@ -221,17 +221,21 @@ if (args.version) {
     // pipe never pays for it and never sees it), cached for a day, bounded, and
     // written to stderr.
     console.log(VERSION);
+    // Awaited, not fired off behind a deferred process.exit(). This is
+    // top-level module code with no `return`, so a detached exit does not stop
+    // the statements below it: on a TTY the whole interactive path ran anyway
+    // (the TTY check, then main() and its AI-disclosure banner) and was then
+    // killed mid-frame when the notice resolved, which trips a libuv assertion
+    // on Windows — "Assertion failed: !(handle->flags & UV_HANDLE_CLOSING),
+    // file src\win\async.c". Awaiting keeps the notice and makes the exit
+    // synchronous. checkForUpdate is capped by a 2s AbortSignal timeout, cached
+    // for a day, and never throws, so this cannot hang or fail.
     if (process.stdout.isTTY) {
-        void updateNoticeForUser()
-            .then((notice) => {
-            if (notice)
-                console.error(notice);
-        })
-            .finally(() => process.exit(0));
-    }
-    else {
-        process.exit(0);
+        const notice = await updateNoticeForUser();
+        if (notice)
+            console.error(notice);
     }
+    process.exit(0);
 }
 const workspace = path.resolve(args.dir);
 if (!fs.existsSync(workspace) || !fs.statSync(workspace).isDirectory()) {

package/dist/shell/sandbox.js

@@ -1,9 +1,11 @@
 import { spawnSync } from "node:child_process";
 import fs from "node:fs";
+import { createRequire } from "node:module";
 import os from "node:os";
 import path from "node:path";
 import { classifyDanger } from "../permissions/danger.js";
 let cachedTool;
+let cachedMxcExec;
 function commandExists(bin) {
     const finder = os.platform() === "win32" ? "where" : "which";
     try {
@@ -13,7 +15,66 @@ function commandExists(bin) {
         return false;
     }
 }
-/** Which sandbox binary (if any) is usable on this platform, cached after the first check. */
+/**
+ * MXC ships `wxc-exec.exe` per architecture (`bin/x64/`, `bin/arm64/`), and its
+ * own resolver picks the same way — see `sdk/node/src/v1/platform.ts::
+ * findWxcExecutable`, which this mirrors.
+ */
+function mxcArch() {
+    return os.arch() === "arm64" ? "arm64" : "x64";
+}
+/** The `@microsoft/mxc-sdk` install directory, or null when it isn't installed. */
+function mxcPackageRoot() {
+    try {
+        // `./package.json` is in the SDK's exports map, so this resolves whether or
+        // not the package's main entry is importable.
+        const require = createRequire(import.meta.url);
+        return path.dirname(require.resolve("@microsoft/mxc-sdk/package.json"));
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * Locate `wxc-exec.exe`, in the order a user would expect to override it: an
+ * explicit path, then MXC's own `MXC_BIN_DIR`, then `PATH`, then an optional
+ * `@microsoft/mxc-sdk` install. Null means MXC isn't present, which leaves
+ * Windows behaving exactly as it did before MXC support existed.
+ */
+function locateMxcExecutable() {
+    const explicit = process.env.KRITYA_MXC_EXEC;
+    if (explicit && fs.existsSync(explicit))
+        return explicit;
+    // MXC's own override: <MXC_BIN_DIR>/<arch>/wxc-exec.exe.
+    const binDir = process.env.MXC_BIN_DIR;
+    if (binDir) {
+        const candidate = path.join(binDir, mxcArch(), "wxc-exec.exe");
+        if (fs.existsSync(candidate))
+            return candidate;
+    }
+    // On PATH — kept as a bare name so the OS resolves it at spawn time.
+    if (commandExists("wxc-exec.exe"))
+        return "wxc-exec.exe";
+    const root = mxcPackageRoot();
+    if (root) {
+        const candidate = path.join(root, "bin", mxcArch(), "wxc-exec.exe");
+        if (fs.existsSync(candidate))
+            return candidate;
+    }
+    return null;
+}
+/** Cached after the first check — locating it can shell out to `where`. */
+function mxcExecutable() {
+    if (cachedMxcExec === undefined)
+        cachedMxcExec = locateMxcExecutable();
+    return cachedMxcExec;
+}
+/** Test-only: drops the memoized backend and MXC path between cases. */
+export function resetSandboxToolCache() {
+    cachedTool = undefined;
+    cachedMxcExec = undefined;
+}
+/** Which sandbox backend (if any) is usable on this platform, cached after the first check. */
 function sandboxTool() {
     if (cachedTool !== undefined)
         return cachedTool;
@@ -24,6 +85,12 @@ function sandboxTool() {
     else if (platform === "darwin") {
         cachedTool = commandExists("sandbox-exec") ? "sandbox-exec" : null;
     }
+    else if (platform === "win32") {
+        // MXC (Microsoft eXecution Containers) is Windows' only containment
+        // backend — AppContainer + DACLs, enforced by the kernel. It is an
+        // optional install, so "not there" is the common case and stays null.
+        cachedTool = mxcExecutable() ? "mxc" : null;
+    }
     else {
         cachedTool = null;
     }
@@ -35,10 +102,11 @@ export function sandboxAvailable() {
 /**
  * Default `sandboxMode` when the config leaves `sandboxExec` unset. "auto" on
  * Linux/macOS, where bwrap/sandbox-exec can actually confine writes to the
- * workspace. On Windows there's no sandbox backend at all (see
- * `sandboxUnavailableReason`), so "auto"/"always" would let a flagged command
- * run unprotected outside the workspace — "strict" refuses those instead of
- * silently falling back.
+ * workspace. On Windows "strict" is kept even though MXC can now back it,
+ * because "strict" is the mode that fails closed: with MXC installed every
+ * command runs *inside* the container instead of being refused, and on a host
+ * where MXC isn't present (or can't be served) commands are refused rather
+ * than silently falling back to an unconfined run.
  */
 export function defaultSandboxMode() {
     return os.platform() === "win32" ? "strict" : "auto";
@@ -46,8 +114,10 @@ export function defaultSandboxMode() {
 /** One-line reason sandboxing can't run here, for a fallback warning. */
 export function sandboxUnavailableReason() {
     const platform = os.platform();
-    if (platform === "win32")
-        return "sandboxed execution isn't supported on Windows yet";
+    if (platform === "win32") {
+        return ("wxc-exec.exe not found (install @microsoft/mxc-sdk, set MXC_BIN_DIR, " +
+            "or point KRITYA_MXC_EXEC at the binary)");
+    }
     if (platform === "linux")
         return "bwrap (bubblewrap) not found on PATH";
     if (platform === "darwin")
@@ -58,18 +128,18 @@ export function sandboxUnavailableReason() {
 export function shouldSandbox(mode, command) {
     if (!mode || mode === "off")
         return false;
-    // "always"/"strict" mean always, on every platform — including Windows,
-    // where there's no sandbox binary to back it, so every command falls back
-    // to the "[sandbox unavailable]" note ("always") or is refused outright
-    // ("strict"). That's deliberate: these are the modes for someone who wants
-    // maximum enforcement/visibility even without a real sandbox backing it.
+    // "always"/"strict" mean always, on every platform. Where no backend can be
+    // found that falls back to the "[sandbox unavailable]" note ("always") or a
+    // refusal ("strict") — deliberate, since these are the modes for someone who
+    // wants maximum enforcement/visibility even without a sandbox behind them.
     if (mode === "always" || mode === "strict")
         return true;
-    // "auto": Windows has no sandbox binary at all — falling back to "only
-    // flagged commands" (today's behavior) avoids a spurious fallback note on
-    // every single shell call, which "sandbox everything" would otherwise cause.
+    // "auto" on Windows without a backend: falling back to "only flagged
+    // commands" avoids a spurious fallback note on every single shell call,
+    // which "sandbox everything" would otherwise cause. With MXC installed
+    // there *is* a backend, so "auto" means here what it means elsewhere.
     if (os.platform() === "win32")
-        return classifyDanger(command) !== null;
+        return sandboxAvailable() || classifyDanger(command) !== null;
     return true;
 }
 /**
@@ -365,6 +435,169 @@ ${writeExtra}
 ${readExtra}
 `;
 }
+/**
+ * Windows' system-drive root, e.g. `C:\` — the read-everything analogue of
+ * bwrap's `--ro-bind / /`. It is granted through MXC's *readwrite* list rather
+ * than its readonly one; see `mxcPolicyJson` for why that is not a loosening.
+ */
+function systemDriveRoot() {
+    const drive = process.env.SystemDrive || "C:";
+    return drive.endsWith("\\") ? drive : `${drive}\\`;
+}
+/**
+ * `command` as a `cmd.exe` command line, the way `buildSandboxedCommand`'s
+ * other two branches get theirs from `sh -c`.
+ *
+ * `wxc-exec` takes one command-line string and hands it to CreateProcess, which
+ * reads it as an image plus arguments — no shell, so `a && b` arrives at the
+ * first program as literal arguments and `|`, `>`, `cd …` and the like do
+ * nothing at all. This mirrors what Node's own `child_process.exec` passes on
+ * Windows (`cmd.exe /d /s /c "…"`), so a sandboxed command and an unsandboxed
+ * one behave the same: `/d` skips the registry AutoRun hooks, and `/s` makes
+ * cmd strip only the outermost quotes so a command carrying its own quoted
+ * arguments survives. Verified through wxc-exec: `&&`, `|`, `>` and nested
+ * quotes (`node -e "…"`) all work, and `dir`/`echo` resolve as cmd builtins.
+ */
+function windowsShellCommand(command) {
+    return `cmd.exe /d /s /c "${command}"`;
+}
+/**
+ * `PATH` directories the container must be able to read for `cmd.exe` to
+ * resolve bare tool names such as `git`, `npm` and `node`.
+ *
+ * The container's `PATH` is the real, registry-derived one, so it lists
+ * directories like `C:\Program Files\nodejs` — but those are `EPERM` to the
+ * container until granted, so cmd.exe's lookup fails inside them and reports
+ * `'node' is not recognized as an internal or external command`. Granting them
+ * read-only fixes it. This is the same job MXC's own
+ * `policy.filesystem.getAvailableToolsPolicy` does, and the filters below
+ * follow it.
+ *
+ * Filtered rather than passed through wholesale:
+ *  - only paths that exist and are directories,
+ *  - nothing under `%SystemRoot%` — the container already has a baseline over
+ *    the system directories, and MXC's helper excludes them for that reason,
+ *  - never a drive root, and never a path that contains the home directory or
+ *    the workspace: granting an ancestor of either aborts container creation
+ *    outright (see `mxcPolicyJson`), and a `PATH` entry that contains the
+ *    workspace would also contradict the read-write grant it already has.
+ */
+function windowsToolPaths(workspace) {
+    const home = os.homedir();
+    const systemRoot = (process.env.SystemRoot || process.env.WINDIR || "C:\\Windows").replace(/\\+$/, "");
+    // True when `parent` is `child` or contains it.
+    const contains = (parent, child) => {
+        const rel = path.relative(parent, child);
+        return rel === "" || (!rel.startsWith("..") && !path.isAbsolute(rel));
+    };
+    const seen = new Set();
+    const out = [];
+    for (const raw of (process.env.PATH ?? "").split(path.delimiter)) {
+        const entry = raw.trim();
+        if (!entry || !path.isAbsolute(entry))
+            continue;
+        const abs = path.resolve(entry);
+        const key = abs.toLowerCase();
+        if (seen.has(key))
+            continue;
+        seen.add(key);
+        // `C:\` (and a bare `C:`) is the read-everything entry, handled separately.
+        if (abs === path.parse(abs).root)
+            continue;
+        if (abs.toLowerCase() === systemRoot.toLowerCase())
+            continue;
+        if (abs.toLowerCase().startsWith(systemRoot.toLowerCase() + "\\"))
+            continue;
+        if (contains(abs, home) || contains(abs, workspace))
+            continue;
+        try {
+            if (!fs.statSync(abs).isDirectory())
+                continue;
+        }
+        catch {
+            continue;
+        }
+        out.push(abs);
+    }
+    return out;
+}
+/**
+ * The MXC request for one command, as JSON. Mirrors the posture of the bwrap
+ * and sandbox-exec branches below: reads stay open, writes are confined to the
+ * workspace plus the same short allowlist of tool caches.
+ *
+ * MXC's schema is versioned and the version marker is part of the contract, so
+ * this targets 1.0.0 (`schemas/stable/mxc-config.schema.1.0.0.json`).
+ * `wxc-exec` validates natively and refuses a request it cannot serve, so a
+ * policy that is wrong here fails the command rather than running it unconfined.
+ *
+ * Deliberate choices, all to keep Windows consistent with the other platforms
+ * rather than stricter by accident:
+ *  - The network is left open. Neither bwrap nor sandbox-exec restricts it, and
+ *    a contained command that cannot reach the network cannot `npm install`,
+ *    `git push`, or run a dev server. Tightening it is a cross-platform call.
+ *  - The temp dir is not isolated. Windows has no tmpfs equivalent, so scratch
+ *    state already persists across calls without a shared-dir bind. MXC hands
+ *    the container its own writable temp dir regardless (it rewrites `TEMP` to
+ *    `%LOCALAPPDATA%\Packages\sandbox.{…}\AC\Temp`), so nothing needs granting
+ *    here either.
+ *  - UI access stays enabled. MXC's default blocks the Win32k subsystem, and a
+ *    contained process that cannot reach it dies before running a line of its
+ *    own code, with STATUS_DLL_INIT_FAILED (0xC0000142) — wxc-exec names this
+ *    exact setting when it reports that. bwrap and sandbox-exec do not restrict
+ *    the UI either, so this is the consistent posture rather than a loosening.
+ *  - The system drive root is granted as read-write, and `readonlyPaths` is
+ *    omitted entirely. Both spellings are meant to say "reads stay open over
+ *    the whole drive", and MXC's own `policy.filesystem.getPowerShellPolicy`
+ *    emits the readonly one — but on Windows 11 24H2 that spelling aborts
+ *    container creation. wxc-exec logs `process created (PID …)` and the child
+ *    then exits 1 with no output, so the command silently never runs; it is
+ *    reproducible with a bare `readonlyPaths: ["C:\\"]` and with the drive root
+ *    added to a policy that already works. Every ancestor of the profile chain
+ *    behaves the same way (`C:\Users`, `%USERPROFILE%`, `…\AppData`,
+ *    `…\AppData\Local`), which is consistent with the drive root needing to be
+ *    DACL-brokered for the contained token. Listing it under `readwritePaths`
+ *    instead is harmless and grants what was actually intended: the command can
+ *    stat `C:\` — which `node.exe`, `cmd.exe` and `pwsh.exe` all do at startup,
+ *    and without which they die with `EPERM: lstat 'C:\'` — while writes to the
+ *    root, to the profile and to `%USERPROFILE%` are still denied. Verified
+ *    against `wxc-exec.exe` 1.0.0 on Windows 11 24H2 with a policy of exactly
+ *    this shape: reads of `C:\`, `System32` and `Program Files` succeed, the
+ *    workspace and the container's own temp dir are writable, and the profile
+ *    root, the drive root and `C:\Windows\Temp` all stay unwritable.
+ *    `readonlyPaths` carries the `PATH` tool directories from
+ *    `windowsToolPaths`. MXC already gives the container a baseline over the
+ *    system directories and over anything whose ACL carries an AppContainer
+ *    capability SID, so most of `PATH` needs nothing said about it — but a
+ *    directory outside that baseline (per-user installs such as
+ *    `%APPDATA%\npm`) is `EPERM` until granted, and `cmd.exe` cannot resolve a
+ *    bare `npm` or `node` that lives in one. The key is omitted rather than
+ *    sent as `[]` when there is nothing to add, so a policy built without it
+ *    is byte-identical to what this function produced before.
+ */
+export function mxcPolicyJson(command, workspace, writable, readable = []) {
+    return JSON.stringify({
+        version: "1.0.0",
+        containment: "processcontainer",
+        process: { commandLine: command, cwd: workspace },
+        filesystem: {
+            // Existing paths only: the bwrap branch skips missing binds for the same
+            // reason, and naming a path that is not there is a needless way to have
+            // the whole request rejected. The drive root closes the list because it
+            // is the read-everything entry — see the note above for why it belongs
+            // here rather than in `readonlyPaths`.
+            readwritePaths: [...new Set([...writable, workspace, systemDriveRoot()])],
+            // Never the drive root or the profile chain — see the note above; both
+            // are fatal under `readonlyPaths`.
+            ...(readable.length > 0 ? { readonlyPaths: [...new Set(readable)] } : {}),
+        },
+        network: { egress: { default: "allow" }, ingress: { default: "allow" } },
+        ui: { disable: false },
+        // MXC telemetry is off unless the run opts in, the user consents, and
+        // administrative policy permits it. Kritya opts out on the user's behalf.
+        telemetry: { enabled: false },
+    });
+}
 /**
  * Wraps `command` (run via `sh -c`) so it's confined to `workspace`: writes
  * are blocked everywhere else, network and (outside the real temp-dir roots)
@@ -382,6 +615,33 @@ export function buildSandboxedCommand(command, workspace) {
         return null;
     // Linked worktrees / submodules keep their real git dir outside the workspace.
     const gitDir = externalGitCommonDir(workspace);
+    if (tool === "mxc") {
+        // Windows: hand the whole request to wxc-exec, which creates the
+        // AppContainer and runs the command inside it. The policy travels as
+        // base64 rather than a file — the same way MXC's own SDK passes it — so
+        // there is no profile file to create, guard, or clean up. Compare the
+        // symlink/TOCTOU defences the macOS branch needs for its profile: never
+        // writing a policy to disk removes that whole class of problem.
+        //
+        // Deliberately ahead of the shared-temp-dir setup below, which creates a
+        // directory as a side effect: Windows has no tmpfs to carve it out of, so
+        // there is nothing for it to do here.
+        const exe = mxcExecutable();
+        if (!exe)
+            return null;
+        const writable = [...extraWritablePaths(), ...(gitDir ? [gitDir] : [])].filter((p) => fs.existsSync(p));
+        // Unlike the branches below there is no `sh -c` here to give the command a
+        // shell, so `windowsShellCommand` supplies the `cmd.exe` one — see its
+        // note. `windowsToolPaths` supplies the read-only grants cmd.exe needs to
+        // resolve bare tool names inside the container.
+        return {
+            cmd: exe,
+            args: [
+                "--config-base64",
+                Buffer.from(mxcPolicyJson(windowsShellCommand(command), workspace, writable, windowsToolPaths(workspace)), "utf8").toString("base64"),
+            ],
+        };
+    }
     // null if the path exists but isn't a real, self-owned directory (e.g.
     // another local user squatted it as a symlink) — see safeSandboxSharedTmpDir.
     const shared = safeSandboxSharedTmpDir();

package/dist/ui/useAgent.js

@@ -125,7 +125,8 @@ export function useAgent({ agent, workspace, modelRef, providerRef, config, uiBr
     const hasConfirmedAcceptEdits = useRef(false);
     const hasConfirmedBypassMode = useRef(false);
     /** Whether auto/bypass mode is even reachable — requires a real sandbox
-     *  backend on this platform (Windows never has one; see sandboxAvailable). */
+     *  backend on this platform (on Windows that means MXC is installed; see
+     *  sandboxAvailable). */
     const sandboxActive = (config.sandboxExec ?? defaultSandboxMode()) !== "off" && sandboxAvailable();
     const abortRef = useRef(null);
     /** Tool calls currently running, keyed by call id — more than one when a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kritya",
-  "version": "0.8.40-beta",
+  "version": "0.8.42-beta",
   "description": "Kritya — Superintelligence at your command line",
   "type": "module",
   "publishConfig": {