@argszero/cordis-plugin-sandbox-grant-advisor 0.10.0 → 0.11.0

package/lib/types/index.d.ts

@@ -2,7 +2,7 @@
  * `sandbox-grant-advisor`: turn an environment failure that has no path forward
  * into a diagnosis the model — and the user reading the transcript — can act on.
  *
- * ## The three failures it recognizes
+ * ## The four failures it recognizes
  *
  * **Workspace provisioning (Windows ACL).** Four reports of one signature
  * (`#7538`, `#7622`, `#7646`, `#7720`) describe the same shape: the host-side write grant
@@ -68,6 +68,26 @@
  * tool's own canonical output, never a line of rendered text — and which three
  * narrowings keep the recognition from firing on something else.
  *
+ * **Denied inside the workspace (Windows ACL, `#423`).** The fourth family is
+ * the other half of the backend the first one explains, and it is the first
+ * whose remedy is withheld on purpose. There the grant could not be applied at
+ * all; here it *was* applied — on the workspace root, once — and Windows ACE
+ * inheritance silently skipped objects whose DACL the caller could not write.
+ * The backend's provisioning check short-circuits on the root (`hasExactGrant`
+ * returns early once the root carries the ACE, `sandbox-windows-acl/src/acl.ts`),
+ * so those descendants are never revisited and the same command fails forever,
+ * while a directory the harness itself created works. It arrives at the same
+ * seam as the native-init family and for the same structural reason: a denied
+ * command exits nonzero and the shipped shell tools report that as a finished
+ * run, so the fact is in `ToolExecutionSuccess.value` rather than in an error.
+ * Unlike that family it needs no bespoke code — the executors stamp the denial
+ * onto the value as a structured triple (`sandbox: { mode, denied, enforcement? }`,
+ * produced by matching the backend's own refusal dialect in the captured
+ * stderr), so this plugin reads the harness's own reading of its own sandbox.
+ * See `src/signature.ts` for the facts that narrow it, and in particular for
+ * why a denial is the *designed* outcome in three other situations (outside the
+ * workspace, under `read-only`, a runner failure) and must never be advised.
+ *
  * ## Where it acts, and why there
  *
  * One listener on the public `tools/post-execute` waterfall
@@ -107,9 +127,15 @@
  *    packaged desktop binary, which the plugin **measures and reports** rather
  *    than assumes), and carries the one conversion a model can actually make —
  *    rewrite the work as PowerShell or `cmd` when the program that could not
- *    start was an MSYS2 one. All three ride `additionalContexts`, so the model
- *    sees the diagnosis beside the failure rather than only in a log it never
- *    reads.
+ *    start was an MSYS2 one. For the workspace-denial family it prints the path
+ *    it keyed on beside the root it tested it against, says that retrying is
+ *    provably useless (the root-only provisioning check never revisits the
+ *    object), gives the two-sided reachability rule, names the label variant of
+ *    the same shape, and prints **no** repair command — the obvious one is
+ *    refused by Windows with `ERROR_NONE_MAPPED (1332)`, and this project has no
+ *    Windows host to verify a line on. All four ride `additionalContexts`, so the
+ *    model sees the diagnosis beside the failure rather than only in a log it
+ *    never reads.
  * 2. **A bounded fail-fast, ACL family only.** With `enforceAfter` set, a call
  *    this plugin has *watched fail* this way is refused at `tools/pre-execute`
  *    once the environment has failed at least that many times. It is off by
@@ -121,8 +147,13 @@
  *    only sent when the resolved mode actually confines; if the mode is not
  *    confining, or cannot be
  *    resolved at all, the failure is left exactly as it was **and the host log
- *    says so once**. Silence alone would make "the sandbox is not the cause" and
- *    "this plugin could not tell" indistinguishable from the outside.
+ *    says so once**. The workspace-denial advisory is withheld the same way when
+ *    the workspace root — the fact the containment claim is tested against —
+ *    cannot be resolved. Silence alone would make "the sandbox is not the cause" and
+ *    "this plugin could not tell" indistinguishable from the outside. A denial
+ *    the classifier *can* place outside the workspace is a different case and is
+ *    left silent on purpose: that is the sanctioned escalation path, not a
+ *    puzzle, and a note about it would be noise.
  *
  * ## Honest boundaries
  *
@@ -139,7 +170,10 @@
  *   tools' own foreground projection with the reported codes, including the
  *   signed form the reporter saw (`-1073741502`) and the real MSYS2 stderr, so the
  *   recognition runs against the producer's data rather than against a message
- *   this plugin invented.
+ *   this plugin invented. The workspace-denial family is exercised the same way:
+ *   the test builds the executors' own `sandbox` stamp and the shipped foreground
+ *   projection, supplies `win32` as the platform fact, and covers both the
+ *   recognized case and each of the narrowings that must stay silent.
  * - **It does not repair anything.** No ACL is written, no privilege is
  *   requested, nothing is elevated, no environment variable is set for another
  *   process, no preset is installed and no mode is changed: the remedies are the
@@ -148,7 +182,7 @@
  *   guard keys on *call identity* (identical arguments retried); this one keys
  *   on the *environment signature*, which is how several different commands can
  *   share one cause. They can be mounted together.
- * - **The real fix is upstream**, in all three families: the ACL failure should
+ * - **The real fix is upstream**, in all four families: the ACL failure should
  *   name
  *   the outstanding condition at the site that knows it (`grantWrite` computes
  *   `hasExactGrant`/`hasExactDeny`/`hasExactLabel` and discards which was
@@ -156,7 +190,12 @@
  *   incompatible with the PTY backend" or fall back to a one-shot shell, and the
  *   sandbox runner should be launched with the environment its own execution
  *   needs (`ELECTRON_RUN_AS_NODE` when argv[0] is an Electron binary) or with a
- *   documented, checkable refusal for MSYS2 programs. This plugin is the stopgap.
+ *   documented, checkable refusal for MSYS2 programs. The workspace-denial family
+ *   is the same shape once more: `grantWrite` returns early when the *root*
+ *   already carries the ACE, so the descendants that missed the propagation are
+ *   never repaired — the check would have to look past the root, or the denial
+ *   surface would have to say *which* path was refused instead of only that one
+ *   was. This plugin is the stopgap.
  *
  * @module @argszero/cordis-plugin-sandbox-grant-advisor
  */

package/lib/types/mode.d.ts

@@ -19,6 +19,13 @@
  * session — so what is quoted in the advisory is the policy that actually
  * governed the failing call, not a guess reconstructed from configuration.
  *
+ * The same lookup answers the **workspace root** for the fourth family
+ * (`workspace-denial`, #423), whose claim is that the path a denied command
+ * named lies inside the session's own workspace. Same request, same fail-closed
+ * posture, separate function ({@link resolveWorkspaceRoot}), so that neither
+ * family can fail on a field it never reads and each can name the failure in its
+ * own words.
+ *
  * ## Why this is a guarded lookup instead of an import
  *
  * `@deepseek-ai/dsh-sandbox-policy` is **optional** in this plugin's world: a
@@ -73,6 +80,18 @@ export type ModeResolution =
     readonly ok: false;
     readonly withheld: string;
 };
+/** The outcome of resolving one agent's workspace root. */
+export type RootResolution = 
+/** The workspace root the enforcing providers were handed. */
+{
+    readonly ok: true;
+    readonly workspaceRoot: string;
+}
+/** No answer was available, and why — the host side says so out loud. */
+ | {
+    readonly ok: false;
+    readonly withheld: string;
+};
 /**
  * Resolve the effective sandbox mode for one agent's call.
  *
@@ -85,3 +104,18 @@ export type ModeResolution =
  * @returns the mode, or the reason it could not be resolved.
  */
 export declare function resolveSandboxMode(ctx: Context, agent: Agent): ModeResolution;
+/**
+ * The workspace root the policy resolver reports for one agent's call.
+ *
+ * The same lookup, the same request and the same fail-closed posture as
+ * {@link resolveSandboxMode}, and for the same reason: the root is what the
+ * enforcing providers were handed, so it is the value the workspace-denial
+ * family must test containment against rather than one reconstructed from
+ * configuration. The two are separate functions rather than one that returns
+ * both because each family needs one of them, and a family that needs only the
+ * mode must not be able to fail on a missing root (nor the other way round).
+ * @param ctx - the plugin's context.
+ * @param agent - the agent whose call failed.
+ * @returns the root, or the reason it could not be resolved.
+ */
+export declare function resolveWorkspaceRoot(ctx: Context, agent: Agent): RootResolution;

package/lib/types/signature.d.ts

@@ -1,5 +1,5 @@
 /**
- * Recognize the three environment failures this plugin explains, and refuse
+ * Recognize the four environment failures this plugin explains, and refuse
  * everything else.
  *
  * ## The ACL provisioning failure (`acl-provisioning`)
@@ -147,6 +147,82 @@
  *   observe and would make this family untestable on the host this plugin is
  *   built on — which is how a family ships without ever having been run.
  *
+ * ## Denied inside the workspace (`workspace-denial`)
+ *
+ * The fourth family is the other half of the same backend the first one
+ * explains. There the grant could not be applied at all and every command died
+ * before it ran; here the grant *was* applied and the workspace looks
+ * provisioned — and part of the tree still refuses writes. `#423` is the
+ * report: under `workspace-write` on Windows, a command writing into a
+ * subdirectory that was created or moved in from outside the session is denied,
+ * forever, while the same command against a directory the harness itself
+ * created succeeds.
+ *
+ * Like the native-init family, and for the same structural reason, this one is
+ * **invisible from the error path**: a denied command exits nonzero, and the
+ * shipped shell tools report a nonzero exit as a finished run rather than as
+ * `isError`, so the fact arrives in `ToolExecutionSuccess.value`. Unlike that
+ * family it does not need a bespoke code to be read — the shipped executors
+ * *stamp the denial* onto the value, as a structured triple no line of rendered
+ * text can fabricate:
+ *
+ *   `sandbox: { mode, denied: true, enforcement? }`
+ *
+ * (`packages/shell/bash-sandbox/src/index.ts` and `pwsh-sandbox`, both on
+ * `classifyDenial`; projected into the tool result value by `tool-bash` /
+ * `tool-pwsh`). `denied` is produced by matching the backend's own refusal
+ * dialect in the *captured stderr* — `'access is denied'`, `'access to the
+ * path'`, `'permission denied'`, `'operation not permitted'` for the
+ * `windows-acl` backend — so the value is the harness's reading of its own
+ * sandbox, not this plugin's reading of a message.
+ *
+ * **`denied` alone is not this family, and the narrowings are the whole
+ * design.** A denial is the *sanctioned* outcome in three other situations, and
+ * advising about a missing inherited grant in any of them would be the
+ * confidently wrong cause this module exists to avoid:
+ *
+ * - **Outside the workspace.** `fs-sandbox` throws its marker only when a path
+ *   falls outside the writable roots, and a confined shell denying a path
+ *   outside the workspace is the designed escalation path — the denial surface
+ *   offers one retry under a wider mode, and that offer is correct there.
+ * - **Under `read-only`.** That mode denies *every* write by construction
+ *   (`fs-sandbox`'s `checkedTarget`: `read-only` throws before any containment
+ *   question is asked), so an in-workspace denial under it is the mode working.
+ * - **A runner failure.** The executor refuses to call a run denied when the
+ *   runner itself failed (`denied: !runnerFailed && …`), and a value that
+ *   carries `runnerFailed: true` is left alone for the same reason.
+ *
+ * What is left is exactly the anomaly: **a denial under `workspace-write` of a
+ * path inside the session's own workspace**, which is the one combination the
+ * harness is supposed to make impossible. The mode comes off the value (the
+ * executor stamped the mode it actually ran under, so no policy lookup can
+ * disagree with it), and the containment test needs the workspace root, which
+ * comes from the policy resolver at the call site —
+ * {@link classifyWorkspaceDenial} takes it as a fact rather than reading it, so
+ * the recognition stays a pure function of its inputs.
+ *
+ * **The in-workspace half of that test is keyed on the command's own text**, and
+ * deliberately not on the stderr the denial was inferred from: the regex looks
+ * for drive-qualified or UNC path literals in the call's `command` argument, and
+ * the family is recognized only when **every** such literal it finds lies under
+ * the workspace root. A command that names an outside path as well — an
+ * interpreter shipped under `C:\Program Files`, an output directory on another
+ * volume — is refused rather than guessed at, and so is a command that names
+ * only relative paths: in both cases the plugin cannot say *which* path was
+ * denied, and silence is the fail-closed direction. The paths it did key on are
+ * carried into the advisory, so the reader can see the reasoning rather than
+ * take it on faith.
+ *
+ * **The platform gate is real here, and unlike the native-init family it cannot
+ * be dropped.** The mechanism is Windows ACE inheritance: the backend writes the
+ * grant once, on the workspace root, and relies on the operating system to
+ * propagate it to descendants, which needs `WRITE_DAC` on each descendant at
+ * that moment. Every other backend applies its policy per call to the process
+ * (landlock rules, a bwrap profile, a seatbelt profile) and has no descendant to
+ * miss, so the same value on those hosts is a different story. `win32` is
+ * therefore part of recognition, passed in rather than read, and the suite runs
+ * this family with the platform fact supplied.
+ *
  * @module
  */
 /** Which provisioning operation failed, and which diagnosis follows from it. */
@@ -174,7 +250,9 @@ export type FailureFamily =
 /** The persistent PTY shell could not start under a confining sandbox mode. */
  | 'pty-startup'
 /** A confined Windows child died while its native images were initializing. */
- | 'native-init';
+ | 'native-init'
+/** A confined command was denied a path inside its own workspace (Windows ACL). */
+ | 'workspace-denial';
 /** One recognized provisioning failure, with the producer's own fields kept. */
 export interface ProvisioningFailure {
     /** Which family this failure belongs to. */
@@ -233,8 +311,53 @@ export interface NativeInitFailure {
     /** The same code normalized to its unsigned 32-bit form, for comparison and printing. */
     readonly exitCode: number;
 }
+/**
+ * The mode in which a write **inside** the workspace is supposed to succeed.
+ *
+ * It is the only mode this family is recognized under, and that is a fact about
+ * the other two rather than about this one: `read-only` denies every write by
+ * construction, and `danger-full-access` spawns nothing through the sandbox at
+ * all — so a denial under either is the mode doing its job, and the one place a
+ * denial is an anomaly is here.
+ */
+export declare const DENIAL_MODE = "workspace-write";
+/**
+ * The facts the workspace-denial recognition needs beyond the result value.
+ *
+ * Both are passed in rather than read here, for the reason the other families
+ * state in their own words: a gate that trusts the shape of its input is the
+ * gate that reports a cause from the wrong world. The type is also what keeps
+ * the platform fact honest — the Android/Cygwin-style "`process.platform` is
+ * win32" belief cannot be smuggled in as a default.
+ */
+export interface WorkspaceDenialFacts {
+    /** The host's `process.platform`, as the caller read it. */
+    readonly platform: string;
+    /** The session's workspace root, as the policy resolver reported it. */
+    readonly workspaceRoot: string;
+}
+/**
+ * A confined command that was denied a path inside its own workspace.
+ *
+ * The producer fields are kept verbatim rather than paraphrased, so the advisory
+ * can show the reader the exact facts the recognition keyed on — which matters
+ * more here than anywhere else in this module, because the family's claim
+ * ("this path is inside your workspace") is a statement about two strings.
+ */
+export interface WorkspaceDenialFailure {
+    /** Which family this failure belongs to. */
+    readonly family: 'workspace-denial';
+    /** The mode the denied call ran under, as the executor stamped it on the value. */
+    readonly mode: string;
+    /** The command's exit status, or `null` when the tool reported none. */
+    readonly exitCode: number | null;
+    /** The in-workspace absolute paths the call named, in the order they appear. */
+    readonly paths: readonly string[];
+    /** The workspace root those paths were tested against, as it was given. */
+    readonly workspaceRoot: string;
+}
 /** Any failure this plugin recognizes, tagged by family. */
-export type RecognizedFailure = ProvisioningFailure | PtyStartupFailure | NativeInitFailure;
+export type RecognizedFailure = ProvisioningFailure | PtyStartupFailure | NativeInitFailure | WorkspaceDenialFailure;
 /**
  * Classify one failure message against the ACL family.
  * @param message - the failure text, from the result's `error.message` or its rendered content.
@@ -283,3 +406,66 @@ export declare function classifyNativeInitDeath(value: unknown): NativeInitFailu
  * @returns the message text the producing layer would have produced.
  */
 export declare function failureLine(failure: RecognizedFailure): string;
+/**
+ * The drive-qualified and UNC path literals in one command line.
+ *
+ * Deliberately crude, in the direction that keeps the diagnosis honest. A
+ * literal is taken to end at the first character a shell token cannot carry
+ * unquoted, so a path containing a space is recovered as its first segment — a
+ * **prefix** of the real path, which preserves the containment answer for every
+ * path that lies under the root (a prefix of a descendant is still a descendant)
+ * and refuses the test for paths whose root itself contains a space. A path that
+ * appears twice is returned once.
+ * @param command - the `command` argument of the failing shell call.
+ * @returns the literals found, in order, without trailing separators.
+ */
+export declare function windowsPathsIn(command: string): string[];
+/**
+ * Whether one path lies at or under one root, the way Windows compares them.
+ * @param root - the workspace root.
+ * @param path - the candidate path.
+ * @returns true when `path` is `root` itself or a descendant of it.
+ */
+export declare function isInsideWorkspace(root: string, path: string): boolean;
+/**
+ * Whether one settled value carries the executors' workspace-denial stamp.
+ *
+ * The **structural half** of the fourth family's recognition, split out so that
+ * "this is not a denial at all" (silent, and the overwhelming majority of
+ * successful calls) stays distinguishable from "this is a denial and the plugin
+ * could not finish placing it" — the case the disclosure rule requires the host
+ * log to account for. It reads the value the executors wrote, never a line of
+ * rendered text, and it is deliberately platform-blind: the platform gate is a
+ * fact the classifier takes as an argument, and a stamp test that baked it in
+ * could not be used to decide whether a missing platform fact is worth saying
+ * out loud.
+ *
+ * What it does **not** decide is which path was denied — that needs the call's
+ * arguments and the workspace root, and belongs to
+ * {@link classifyWorkspaceDenial}. A stamp alone is the sanctioned outcome in
+ * three other situations (outside the workspace, under `read-only`, a runner
+ * failure); this function excludes the third by itself and leaves the first two
+ * to the classifier, which is the only place they can be separated.
+ * @param value - a settled execution's canonical value.
+ * @returns true when the value is a foreground shell projection stamped
+ *   `denied: true` under `workspace-write` with no runner failure.
+ */
+export declare function hasWorkspaceDenialStamp(value: unknown): boolean;
+/**
+ * Classify one **successful** execution's canonical value as a workspace-internal
+ * denial, and recover the paths the call named.
+ *
+ * Four facts, in the order they narrow: the call ran on Windows (the mechanism
+ * is ACE inheritance, which no other backend has); the value carries the
+ * executor's denial stamp ({@link hasWorkspaceDenialStamp}); the call's
+ * `command` argument carries at least one absolute Windows path literal; and
+ * **all** of them lie under the workspace root. The last is the one that
+ * separates this family from the sanctioned escalation path — a command naming
+ * any path outside its own workspace is refused rather than guessed at, because
+ * the plugin cannot say which path the sandbox refused.
+ * @param value - the settled execution's canonical value (`ToolExecutionSuccess.value`).
+ * @param args - the settled call's parsed arguments (`ToolExecution.arguments`).
+ * @param facts - the host platform and the session's workspace root.
+ * @returns the recognized failure, or undefined when this is not one.
+ */
+export declare function classifyWorkspaceDenial(value: unknown, args: unknown, facts: WorkspaceDenialFacts): WorkspaceDenialFailure | undefined;

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@argszero/cordis-plugin-sandbox-grant-advisor",
-  "description": "Turns three sandbox environment failures that name neither their cause nor a remedy into a diagnosis with a path forward. Family 1, the Windows workspace ACL: twelve reports (#7538, #7622, #7646, #7720, #7750, #7735, #7771, #7804, #7816, #8232, #8272, #8275) of one signature \u2014 every sandboxed command fails before it runs with `SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)`, because the merged DACL + mandatory-label write needs WRITE_OWNER on the directory (an object right the caller can self-grant), not SeSecurityPrivilege and not elevation; the host grant is materialized lazily and caches nothing on the failure path, so the same failure repeats per command. Two further reports (#8312, #8314) describe the other end of that same backend — what its grant leaves behind once it succeeds: three STANDING entries nothing revokes (the workspace capability SID, the world delete-child deny, and an INHERITABLE Low integrity label that lives in the SACL, so resetting the DACL does not take it off), which makes every program launched from a folder DSH has written to run at Low integrity, and — through the NTFS hard links a pnpm workspace is made of, where two names share one file object and therefore one security descriptor — can reach out of the tree onto a content-addressed store's shared objects, leaving every project that builds from that store with Low-integrity executables and failures that name the build tool rather than DSH; the advisory states all of it before handing over the command that applies that grant, and offers no removal command, because the maintainers' own diagnosis skill does not remove the label either and removing one needs WRITE_OWNER. Family 2, the persistent shell (#7638, #8322): with the `minimal` preset under a confining sandbox mode every shell call dies instantly with `PTY shell exited during startup` because the terminal backend cannot create the pseudo-console inside the sandbox, retrying never helps, and `minimal` mounts no fallback shell tool; #8322 separated the arms inside that mode with one runner and one ConPTY — a console-subsystem node.exe host starts the confined shell while the packaged desktop's GUI-subsystem Electron host kills it silently — so the advisory names the host alongside the mode, says the outcome is deterministic per (session mode × host) rather than intermittent, and adds the console-owning host the Web UI provides (#8313) to the user-side options. Family 3, a confined Windows child that died during native initialization (#7876, #7877): every command spawned through the sandbox runner can report exit 0xC0000142 STATUS_DLL_INIT_FAILED with the process never reaching its entry point \u2014 the packaged desktop starts that runner as [process.execPath, entry], and that host has been measured twice with one indistinguishable appearance from inside a session \u2014 either nothing on the runner path ran because the Electron binary launches as an application unless the child's environment carries ELECTRON_RUN_AS_NODE=1 (#7876), or the desktop launcher does set that variable and the child still dies because the restricted token is derived from the Electron process image (#8193), and an MSYS2 / Git-Bash program cannot create its signal pipe under the restricted token while cmd.exe and pwsh run fine in the same workspace under the same mode (#7877) \u2014 and because upstream's runner-failure rules admit only exit 127 with the `windows-acl-run: ` signature, the code is never an error: it arrives as the canonical value of a result the pipeline calls a success. The plugin observes the public `tools/post-execute` waterfall, classifies all three signatures narrowly (only the two `...NamedSecurityInfoW` operations; the PTY message matched on a whole line, never as a substring; the loader status read as a 32-bit integer out of the shell tool's own canonical success value, never from rendered text; both mode-gated families advised only under a mode the policy resolver reports as confining), and attaches ONE durable user-role advisory per agent per family through `additionalContexts`. The ACL advisory names the missing right, both environments the identical text can describe (an inherited Modify-only entry, a data volume where no ACE names the caller at all, and a directory owned by another account), the version boundary that arrived with the mandatory label (0.1.7-alpha.1, flag 20, versus the DACL-only flag 4 up to 0.1.6-alpha.x) together with why downgrading is not the remedy, the second boundary the later reports needed (the backend's own `diagnose-windows-sandbox-acl` skill is not part of the 0.1.7 line at all — it arrives with 0.2.0, measured on both published tarballs: 0.1.7-rc.2 names it zero times in either README, ships no assets, and carries no registration symbol anywhere in its tree, while 0.2.0-rc.2 ships assets/diagnose-windows-sandbox-acl/ and names it three times per README — so a reader who found the promise in a README was reading a 0.2.0-era document, and sending them to repair a files glob would be the wrong repair), and why a \"weaker grant\" is a mechanism the backend cannot express rather than a policy it declines (the label rides the SAME SetNamedSecurityInfoW as the grant — there is no DACL-only apply path to fall back to — and the confined token is itself lowered to Low, so the object's Low label is what lets the confined child write there at all; declining the label usefully means declining the token level with it), the discriminator, the remedy forked on an ownership check the user runs (`(Get-Acl \"<dir>\").Owner`), because one command cannot serve both rights situations: where the caller owns the directory, the unelevated `icacls ... :(OI)(CI)(WO)` is the whole of what is missing \u2014 the owner's implicit WRITE_DAC already covers the DACL half \u2014 and where the caller does not own it that same command is refused for want of WRITE_DAC, so the grant has to come from an elevated account, or by taking ownership first, or by moving the workspace under %USERPROFILE% \u2014 and the two remedies that look right and are not (`takeown`, `icacls /reset`), each with the reason it fails — and it states the two things about the failure's shape that the reports had to measure for themselves (#8232): that it belongs to the workspace rather than to the command (a command that only reads fails identically, so there is no harmless retry), and that the grant is scoped to the directory it names and its children, so a sibling workspace root on the same volume needs the line once more; the PTY advisory names the failing combination and the host binary that decides it, states the resolved mode and that the session's recorded mode is the one that counts, tells the model to stop rather than retry, and hands over the user-side options (a preset swap, a patch row, or the console-owning host of #8313) \u2014 it never names a shell tool the failing composition does not mount; the native-init advisory states the resolved mode, says the process died before its entry point, enumerates the two producers measured under a confining mode \u2014 naming both measured shapes of the desktop host rather than asserting the one that was measured first \u2014 with the check that separates them (what program the reader ran; whether this host is the packaged desktop binary, which the plugin measures and reports rather than assumes), carries the one conversion a model can make itself (rewrite the work as PowerShell or `cmd` when an MSYS2 program is what could not start), and \u2014 for the Electron host \u2014 names the fix #8193 measured rather than a wider mode: host the runner on a real node.exe (the desktop ships one under `resources/runtime/primary-runtime/dependencies/node/bin/node.exe`), where the same confined `pwsh`/`cmd` spawns succeed, while `danger-full-access` is described as a way to confirm the diagnosis and not a fix, together with the warning that unsetting `ELECTRON_RUN_AS_NODE` instead would leave the desktop's Electron-hosted runner unable to execute `runner.js` at all (the interaction #8193 records with #8174), and says plainly which producers it does not know \u2014 it never claims the sandbox caused the failure and never offers a widened mode as a fix. An optional, off-by-default `enforceAfter` refuses an identical ACL call this plugin has watched fail, bounded by `maxDenials`; the blocking half is ACL-only by design. It never edits an ACL, never elevates, never sets another process's environment, and never changes a preset or a mode, and it complements repeat-guard-escalation, which keys on call identity rather than on the environment signature.",
-  "version": "0.10.0",
+  "description": "Turns four sandbox environment failures that name neither their cause nor a remedy into a diagnosis with a path forward. Family 1, the Windows workspace ACL: twelve reports (#7538, #7622, #7646, #7720, #7750, #7735, #7771, #7804, #7816, #8232, #8272, #8275) of one signature — every sandboxed command fails before it runs with `SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)`, because the merged DACL + mandatory-label write needs WRITE_OWNER on the directory (an object right the caller can self-grant), not SeSecurityPrivilege and not elevation; the host grant is materialized lazily and caches nothing on the failure path, so the same failure repeats per command. Two further reports (#8312, #8314) describe the other end of that same backend — what its grant leaves behind once it succeeds: three STANDING entries nothing revokes (the workspace capability SID, the world delete-child deny, and an INHERITABLE Low integrity label that lives in the SACL, so resetting the DACL does not take it off), which makes every program launched from a folder DSH has written to run at Low integrity, and — through the NTFS hard links a pnpm workspace is made of, where two names share one file object and therefore one security descriptor — can reach out of the tree onto a content-addressed store's shared objects, leaving every project that builds from that store with Low-integrity executables and failures that name the build tool rather than DSH; the advisory states all of it before handing over the command that applies that grant, and offers no removal command, because the maintainers' own diagnosis skill does not remove the label either and removing one needs WRITE_OWNER. Family 2, the persistent shell (#7638, #8322): with the `minimal` preset under a confining sandbox mode every shell call dies instantly with `PTY shell exited during startup` because the terminal backend cannot create the pseudo-console inside the sandbox, retrying never helps, and `minimal` mounts no fallback shell tool; #8322 separated the arms inside that mode with one runner and one ConPTY — a console-subsystem node.exe host starts the confined shell while the packaged desktop's GUI-subsystem Electron host kills it silently — so the advisory names the host alongside the mode, says the outcome is deterministic per (session mode × host) rather than intermittent, and adds the console-owning host the Web UI provides (#8313) to the user-side options. Family 3, a confined Windows child that died during native initialization (#7876, #7877): every command spawned through the sandbox runner can report exit 0xC0000142 STATUS_DLL_INIT_FAILED with the process never reaching its entry point — the packaged desktop starts that runner as [process.execPath, entry], and that host has been measured twice with one indistinguishable appearance from inside a session — either nothing on the runner path ran because the Electron binary launches as an application unless the child's environment carries ELECTRON_RUN_AS_NODE=1 (#7876), or the desktop launcher does set that variable and the child still dies because the restricted token is derived from the Electron process image (#8193), and an MSYS2 / Git-Bash program cannot create its signal pipe under the restricted token while cmd.exe and pwsh run fine in the same workspace under the same mode (#7877) — and because upstream's runner-failure rules admit only exit 127 with the `windows-acl-run: ` signature, the code is never an error: it arrives as the canonical value of a result the pipeline calls a success. The plugin observes the public `tools/post-execute` waterfall, classifies all four signatures narrowly (only the two `...NamedSecurityInfoW` operations; the PTY message matched on a whole line, never as a substring; the loader status read as a 32-bit integer out of the shell tool's own canonical success value, never from rendered text; the two value-read families advised only when the facts they need hold \u2014 a confining resolved mode for the native-init death, and a Windows host, a `workspace-write` stamped mode and an in-workspace path for the denial), and attaches ONE durable user-role advisory per agent per family through `additionalContexts`. The ACL advisory names the missing right, both environments the identical text can describe (an inherited Modify-only entry, a data volume where no ACE names the caller at all, and a directory owned by another account), the version boundary that arrived with the mandatory label (0.1.7-alpha.1, flag 20, versus the DACL-only flag 4 up to 0.1.6-alpha.x) together with why downgrading is not the remedy, the second boundary the later reports needed (the backend's own `diagnose-windows-sandbox-acl` skill is not part of the 0.1.7 line at all — it arrives with 0.2.0, measured on both published tarballs: 0.1.7-rc.2 names it zero times in either README, ships no assets, and carries no registration symbol anywhere in its tree, while 0.2.0-rc.2 ships assets/diagnose-windows-sandbox-acl/ and names it three times per README — so a reader who found the promise in a README was reading a 0.2.0-era document, and sending them to repair a files glob would be the wrong repair), and why a \"weaker grant\" is a mechanism the backend cannot express rather than a policy it declines (the label rides the SAME SetNamedSecurityInfoW as the grant — there is no DACL-only apply path to fall back to — and the confined token is itself lowered to Low, so the object's Low label is what lets the confined child write there at all; declining the label usefully means declining the token level with it), the discriminator, the remedy forked on an ownership check the user runs (`(Get-Acl \"<dir>\").Owner`), because one command cannot serve both rights situations: where the caller owns the directory, the unelevated `icacls ... :(OI)(CI)(WO)` is the whole of what is missing — the owner's implicit WRITE_DAC already covers the DACL half — and where the caller does not own it that same command is refused for want of WRITE_DAC, so the grant has to come from an elevated account, or by taking ownership first, or by moving the workspace under %USERPROFILE% — and the two remedies that look right and are not (`takeown`, `icacls /reset`), each with the reason it fails — and it states the two things about the failure's shape that the reports had to measure for themselves (#8232): that it belongs to the workspace rather than to the command (a command that only reads fails identically, so there is no harmless retry), and that the grant is scoped to the directory it names and its children, so a sibling workspace root on the same volume needs the line once more; the PTY advisory names the failing combination and the host binary that decides it, states the resolved mode and that the session's recorded mode is the one that counts, tells the model to stop rather than retry, and hands over the user-side options (a preset swap, a patch row, or the console-owning host of #8313) — it never names a shell tool the failing composition does not mount; the native-init advisory states the resolved mode, says the process died before its entry point, enumerates the two producers measured under a confining mode — naming both measured shapes of the desktop host rather than asserting the one that was measured first — with the check that separates them (what program the reader ran; whether this host is the packaged desktop binary, which the plugin measures and reports rather than assumes), carries the one conversion a model can make itself (rewrite the work as PowerShell or `cmd` when an MSYS2 program is what could not start), and — for the Electron host — names the fix #8193 measured rather than a wider mode: host the runner on a real node.exe (the desktop ships one under `resources/runtime/primary-runtime/dependencies/node/bin/node.exe`), where the same confined `pwsh`/`cmd` spawns succeed, while `danger-full-access` is described as a way to confirm the diagnosis and not a fix, together with the warning that unsetting `ELECTRON_RUN_AS_NODE` instead would leave the desktop's Electron-hosted runner unable to execute `runner.js` at all (the interaction #8193 records with #8174), and says plainly which producers it does not know — it never claims the sandbox caused the failure and never offers a widened mode as a fix. Family 4, a confined command DENIED a path inside its own workspace (#423): the workspace grant is applied once, on the root, and relies on Windows ACE inheritance to reach the tree beneath it, so an object that already existed (created by an installer, an editor, another harness under its own account) whose DACL the caller could not write kept its older DACL — silently, because a skipped inherited ACE produces no error, no return value and no log line — after which the backend's root-only check (`hasExactGrant(workspaceRoot)`) short-circuits and those descendants are NEVER revisited, so the identical command keeps failing while a directory the harness itself created works; the family is read from the executors' own structured stamp on a successful result (`sandbox: { mode, denied, enforcement? }`, produced by matching the backend's refusal dialect in the captured stderr, so what it reads is the harness's own reading of its own sandbox), and it speaks only when the host is Windows, the stamped mode is `workspace-write`, and EVERY absolute path the command's own arguments name lies under the session's workspace — a denial anywhere else is the designed escalation path, and a command naming any outside path as well, or only relative ones, is refused rather than guessed at because the plugin cannot say which path was refused; the advisory prints the path it keyed on beside the root it tested it against, states that retrying is provably useless, gives the two-sided discriminator (reading and listing use the normal token while writing and deleting use the restricted one, so an object whose DACL names only Administrators/SYSTEM plus the capability SID looks granted to a check that merely greps for the SID), names the second measured variant of the same shape (coverage missing on the mandatory-integrity LABEL rather than on the DACL, separable outside a session only by the repository's own `diagnose-windows-sandbox-acl`), and states the Windows ceiling that closes the obvious repair (a recursive `icacls /grant` for a capability SID is refused with ERROR_NONE_MAPPED (1332) because that SID has no name to map) — while shipping NO repair command at all, for the reason the standing-grant section ships none: this project has no Windows host to verify a line on. An optional, off-by-default `enforceAfter` refuses an identical ACL call this plugin has watched fail, bounded by `maxDenials`; the blocking half is ACL-only by design. It never edits an ACL, never elevates, never sets another process's environment, and never changes a preset or a mode, and it complements repeat-guard-escalation, which keys on call identity rather than on the environment signature.",
+  "version": "0.11.0",
   "type": "module",
   "main": "lib/index.js",
   "types": "lib/types/index.d.ts",