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

package/README.md

@@ -44,6 +44,11 @@ inherited `Authenticated Users: Modify` is the whole of their access). In each o
 every sandboxed command fails the same way, before it runs, and the error names
 neither the missing right nor a remedy.
 
+Two further reports — [discussion #8312] and [discussion #8314] — describe the
+other end of the same backend: what its grant leaves behind *after* it applies.
+The advisory states that too (see [What the grant leaves behind](#what-the-grant-leaves-behind-added-in-0100)),
+because the advisory is the thing handing over the command that applies the grant.
+
 `#8232` contributes two facts about the *shape* of the failure rather than its
 cause, and both are in the advisory now. One is that the failure belongs to the
 **workspace, not the command**: there a `Get-Date` failed exactly like anything
@@ -229,7 +234,27 @@ What will NOT fix it on its own — both look like the right move, and both were
     makes you the owner, and ownership's implicit rights are READ_CONTROL and WRITE_DAC only — so it
     supplies the DACL half and still not WRITE_OWNER, the right this call needs.
   icacls "D:\ws" /reset /T /C
-    restores inheritance, and inheritance is what supplied the Modify-only ACE above.
+    restores inheritance, and inheritance is what supplied the Modify-only ACE above. Where it strips the last
+    entry naming you, the directory ends up in exactly the state the diagnosis above describes — its only access
+    the inherited `Authenticated Users:(M)` (#8314 measured that follow-on failure).
+
+What the grant leaves behind, once it applies — worth knowing before you run the command above, because the
+backend does not take it back:
+  The three entries are STANDING, deliberately, and nothing revokes them. ... They outlive the session and the
+  harness exiting (`sandbox-windows-acl/src/grant.ts`, `src/index.ts`).
+  The Low integrity label is INHERITABLE (`(OI|CI)`) and it lives in the SACL — which is why the `icacls /reset`
+  above does not take it off: that command rebuilds the DACL. Windows starts a process at the minimum of the
+  user's and the program's integrity, so anything started from a tree the harness has written to runs at LOW
+  integrity, and none of the symptoms names DSH (#8312 collects them): ... (#7709), ... (#8175), ... (#7735).
+  It can also leave the workspace. An NTFS hard link is a SECOND NAME for one file object, so both names share
+  one security descriptor — and a pnpm workspace is largely hard links (`node_modules` pointing into a
+  content-addressed store on the same volume). ... `vite build` unable to remove its own temp file, `pnpm
+  install` unable to replace a hook (#8314 measured the whole chain). ...
+  It is also why the label is not simply removable here: ... This advisory hands over no removal command: the
+  maintainers' own skill does not, and an unverified one would be the defect this plugin exists to answer.
+None of this makes the command above the wrong move — without it, nothing sandboxed runs in this workspace. It
+is what the harness does to a directory it has been pointed at, and it is worth knowing before rather than
+discovering it as a broken build in some other project later.
 
 One thing to know before asking for a weaker grant, because that is the next idea after this diagnosis —
 and it is not a smaller version of the same grant:
@@ -256,6 +281,54 @@ unconditional one-liner was printed, with a sentence noting it assumed
 ownership; that would have sent the second environment to a command that is
 denied — the same defect this plugin exists to answer.
 
+#### What the grant leaves behind (added in 0.10.0)
+
+[Discussion #8312] and [discussion #8314] report the other half of this backend,
+and the advisory now states it — before the reader runs the command it is being
+handed, because that command is what makes the backend's grant apply:
+
+- **The three entries are standing, by design, and nothing revokes them.** The
+  workspace grant is a *reuse cache*: the backend's dispose path revokes the
+  revocable (temp) grants and leaves the workspace edits, and its fail-closed
+  cleanup says the same in plainer words — standing ACEs "are NOT revoked — they
+  are the intended end state (the reuse cache), not an error artifact"
+  (`src/grant.ts`, `src/index.ts`). They outlive the session and the harness
+  exiting. ([#8312] arrived at this from the README's own description of the
+  cache; the source is quoted in the advisory.)
+- **The Low integrity label is inheritable, and it lives in the SACL.** That is
+  why `icacls /reset` — already listed as a non-fix for a different reason — does
+  not remove it: the command rebuilds the DACL. Windows starts a process at
+  `min(user, image)` integrity, so anything started from a tree the harness has
+  written to runs at Low integrity, and none of the symptoms points at DSH:
+  an Electron/Chromium app exiting `0x80000003` with no output ([#7709]),
+  msbuild / dotnet / npm refusing or warning about the files as if they came from
+  the Internet when no `Zone.Identifier` exists ([#8175]), a double-clicked
+  `.exe` / `.cmd` reporting "publisher could not be verified" ([#7735]).
+- **It can leave the workspace.** An NTFS hard link is a second name for one
+  file object, so both names share one security descriptor — and a pnpm workspace
+  is largely hard links (`node_modules` pointing into a content-addressed store
+  on the same volume). The inheritable label therefore lands on the *store's*
+  objects and stays there, after which every project building from that store
+  gets executables that start at Low integrity and failures that name the build
+  tool ([#8314] measured the whole chain: `vite build` unable to remove its own
+  temp file, `pnpm install` unable to replace a hook). The backend's own suite
+  pins the reach as a known boundary — *"a workspace hard link lets the grant
+  reach an external file object"* (`tests/runner.spec.ts`) — and its README calls
+  refusing multiply-linked files unviable for ordinary pnpm installs, which
+  leaves the out-of-tree reach open rather than unknown.
+- **No removal command is shipped.** The maintainers' own
+  `diagnose-windows-sandbox-acl` skill *reports* `LOW_LABEL` and by design does
+  not remove it, and removing an integrity label needs `WRITE_OWNER` — the same
+  right this whole failure is about. This project has no Windows host to verify a
+  line on, so shipping one would be exactly the defect the rest of this module
+  exists to answer; the section says where it stops instead.
+
+The section is emitted for **every** ACL class, like the version boundary and for
+the same reason: it is a fact about the package's grant, and that grant is the
+remedy the advisory hands over in all three classes. It also closes with what the
+fact does *not* mean — the command is still the right move, because without it
+nothing sandboxed runs at all.
+
 **What is deliberately *not* shipped**: `icacls ... /grant "<user>:(OI)(CI)(WD,WO)"`,
 the two needed rights named explicitly. It is the tighter form and it is
 plausibly correct syntax, but this project has no Windows host to run it on, and
@@ -287,6 +360,27 @@ built with the **resolved** mode the failing call actually ran under — from
 `ctx.sandboxPolicy.resolve({ session })`, the same resolver the terminal layer
 calls before spawning, with the same session.
 
+**Inside a confining mode, the host binary decides** (added in 0.10.0).
+[Discussion #8322] ran the control one level deeper — same runner, same ConPTY,
+every arm — and separated what the mode alone does not: with the runner hosted by
+a plain console-subsystem `node.exe`, the confined shell starts and its prompt and
+shell-integration marks are correct; with the runner hosted by the packaged
+desktop's GUI-subsystem Electron executable, the child dies **silently** — zero
+bytes on stdout *and* stderr, and the non-interactive arm exits 0 with everything
+it printed lost. It is the same rule the `0xC0000142` family states for its own
+case: under the restricted token a console can be **inherited but not created**,
+so the binary that owns one (or owns none) is what the arms turn on. That is also
+why the same version behaves differently depending on how it was started: the
+desktop app fails where the Web UI launched from a terminal — whose
+`process.execPath` is a real `node.exe` — is reported working under the same
+confining mode ([#8313], whose sibling report is the `0xC0000142` shape of the
+same host difference). The advisory therefore names the host alongside the mode,
+says the outcome is **deterministic per (session mode × host)** rather than
+intermittent, and adds that the mode which counts is the one the **session
+records**, not the one the environment now holds — a session that recorded the
+confining mode keeps failing after the app is restarted with another mode in its
+environment, while switching it inside the session takes effect at once.
+
 The advisory that follows is addressed to **two different readers**:
 
 ```
@@ -299,6 +393,15 @@ The `bash` tool is a PERSISTENT PTY session (a shell that stays alive between ca
 `workspace-write` — not `danger-full-access`. A confining mode spawns the shell through the sandbox, and there the
 terminal backend cannot create the pseudo-console at all, so the child exits before its first prompt. ...
 
+Which sessions fail inside that combination is not chance — it is deterministic per (session mode × the host
+binary carrying the sandbox runner) ... Measured against the desktop build with the same runner and the same
+ConPTY in every arm (#8322):
+  - runner hosted by a plain console-subsystem `node.exe` → the confined shell starts ...;
+  - runner hosted by the packaged desktop's GUI-subsystem Electron executable ... → the child dies silently ...
+The rule behind both this and the `0xC0000142` family ... is the one stated there for its own case: under the
+restricted token a console can be INHERITED but not CREATED ... And the mode that decides is the one the SESSION
+records, not the one the environment now holds ...
+
 Do NOT retry, and do not look for a command that fixes it: every attempt will fail identically, and there is no
 shell to run a command in. Use your file read/write tools instead, and hand the choice below to the user.
 
@@ -309,8 +412,11 @@ What unblocks the session — the user's decision, not the model's:
      `$DSH_HOME/cordis.patch.yml` for every profile — replacing its `persistent-shell` group with
      `@deepseek-ai/dsh-tool-pwsh` (a one-shot subprocess, no PTY); the patch layer is yours, so an upgrade
      will not overwrite it; or
-  3. run the session with `danger-full-access`, which drops the very confinement the sandbox exists to give.
-     Prefer 1 or 2.
+  3. run the session from a host that owns a console instead of the packaged desktop app — the Web UI started
+     from a terminal (`process.execPath` is a real `node.exe` there) was reported working under the same
+     confining mode and the same version (#8313); or
+  4. run the session with `danger-full-access`, which drops the very confinement the sandbox exists to give.
+     Prefer 1 to 3.
 ```
 
 The model's instruction is to **stop** — not to run a command (there is no shell
@@ -331,9 +437,10 @@ the advisory never names the dead directory.
 
 ### 3. A confined child that never started (`native-init`)
 
-Four reports of one exit code: [`#7876`] and [`#8193`] (the packaged desktop
-app) and [`#7877`] (MSYS2 / Git Bash) — and [`#8208`], which found the mechanism
-the console cases share. All are `0xC0000142`
+Five reports of one exit code: [`#7876`] and [`#8193`] (the packaged desktop
+app), [`#8313`] (the same version and the same mode run as the desktop app versus
+the Web UI launched from a terminal, which works) and [`#7877`] (MSYS2 / Git
+Bash) — and [`#8208`], which found the mechanism the console cases share. All are `0xC0000142`
 `STATUS_DLL_INIT_FAILED` — the Windows
 loader terminated the process while it was initializing its native images, i.e.
 **before the program's entry point**. A command that ran and then failed exits
@@ -648,6 +755,17 @@ than one that stays silent.
   one-line experiment and the reporter's own control, and both advisories say
   where they stop. The native-init family is the one that needs no Windows to be
   faithful, because what it reads is a number inside a JSON value.
+- **The standing-grant section is source-level, and the out-of-tree reach is the
+  reporter's measurement.** What this section states about the backend's own
+  behaviour — that the workspace grant is standing, that nothing in the dispose or
+  fail-closed path revokes it, that the Low label is inheritable and lives in the
+  SACL — is read off the shipped source and the backend's own suite, and is quoted
+  as such. What it states about a hard link carrying the label onto a
+  content-addressed store is [#8314]'s measurement on their machine, which is why
+  the advisory attributes it instead of asserting it as a property of every
+  workspace, and why **no removal command is shipped**: this project has no
+  Windows host on which to verify one, and an unverified removal command is the
+  same defect this plugin exists to answer.
 - **It repairs nothing and elevates nothing.** If the directory really is
   Full-control for the caller, the remaining ACL hypothesis is
   `SeSecurityPrivilege` — i.e. the backend's documented prerequisite would be
@@ -778,3 +896,13 @@ the current runtime cannot distinguish rather than counting it as a pass.
 [#8193]: https://github.com/deepseek-ai/deepseek-harness/discussions/8193
 [#8174]: https://github.com/deepseek-ai/deepseek-harness/discussions/8174
 [#8208]: https://github.com/deepseek-ai/deepseek-harness/discussions/8208
+[discussion #8312]: https://github.com/deepseek-ai/deepseek-harness/discussions/8312
+[discussion #8314]: https://github.com/deepseek-ai/deepseek-harness/discussions/8314
+[discussion #8322]: https://github.com/deepseek-ai/deepseek-harness/discussions/8322
+[#7709]: https://github.com/deepseek-ai/deepseek-harness/discussions/7709
+[#7735]: https://github.com/deepseek-ai/deepseek-harness/discussions/7735
+[#8175]: https://github.com/deepseek-ai/deepseek-harness/discussions/8175
+[#8312]: https://github.com/deepseek-ai/deepseek-harness/discussions/8312
+[#8313]: https://github.com/deepseek-ai/deepseek-harness/discussions/8313
+[#8314]: https://github.com/deepseek-ai/deepseek-harness/discussions/8314
+[#8322]: https://github.com/deepseek-ai/deepseek-harness/discussions/8322

package/cordis.patch.yml

@@ -1,8 +1,9 @@
 # The @argszero/cordis-plugin-sandbox-grant-advisor bundle patch: mount and go.
 #
-# Three reports (#7538, #7622, #7646) describe one Windows failure with no way
-# forward: the host-side write grant for a sandboxed workspace cannot be
-# applied, so every sandboxed command fails before it runs with
+# Twelve reports (#7538, #7622, #7646, #7720, #7750, #7735, #7771, #7804,
+# #7816, #8232, #8272, #8275) describe one Windows failure with no way forward:
+# the host-side write grant for a sandboxed workspace cannot be applied, so
+# every sandboxed command fails before it runs with
 #
 #   SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)
 #
@@ -24,8 +25,39 @@
 #     (the manifest half of the merged DACL+SACL write is what needs it);
 #   - the directory's own ACL is the discriminator (`icacls <dir>`, looking for
 #     an ACE that names your SID with (F));
-#   - the remedy is one unelevated line:
-#       icacls "<dir>" /grant "$env:USERNAME:(OI)(CI)F"
+#   - the remedy is one unelevated line, forked on ownership because one command
+#     cannot serve both rights situations — the advisory hands over the check
+#     (`(Get-Acl "<dir>").Owner`) rather than guessing:
+#       icacls "<dir>" /grant "$env:USERNAME:(OI)(CI)(WO)"
+#     with Full control (`F`) offered second as the same line with more than it
+#     needs, and an elevated grant for a directory the caller does not own (where
+#     `icacls /grant` is itself refused for want of WRITE_DAC);
+#   - two version boundaries the error cannot carry: the mandatory label — and
+#     with it the SACL — arrives in `0.1.7-alpha.1` (up to `0.1.6-alpha.x` the
+#     apply touched the DACL only), and the backend's own
+#     `diagnose-windows-sandbox-acl` repair arrives with the `0.2.0` line. Neither
+#     makes downgrading a fix, and repairing the `0.1.7` file list is not a thing
+#     that can be done — there is nothing in that release to list.
+#
+# The advisory also says why a "weaker grant" is not a smaller version of the
+# same one, because that is the next idea the diagnosis invites: the label rides
+# the SAME SetNamedSecurityInfoW as the DACL (no DACL-only apply path exists), and
+# the confined token is itself lowered to Low, so the directory's Low label is
+# what lets that child write there at all.
+#
+# And it says WHAT THE GRANT LEAVES BEHIND once it applies (#8312, #8314): the
+# three entries are STANDING and nothing revokes them (the backend's own dispose
+# and fail-closed paths leave them — "the intended end state (the reuse cache)"),
+# the Low integrity label is INHERITABLE and lives in the SACL (so `icacls /reset`
+# does not remove it — that rebuilds the DACL), a process starts at
+# min(user, image) integrity, and an NTFS hard link shares one security descriptor
+# with the file object it names — so in a pnpm workspace, whose node_modules are
+# hard links into a content-addressed store, the label can reach OUTSIDE the tree
+# and stay on the store's objects, after which unrelated builds fail in ways that
+# name the build tool and not DSH. The section is stated before the reader runs
+# the command, and it ships NO removal command: the maintainers' own diagnosis
+# skill reports the label and does not remove it, and removing an integrity label
+# needs WRITE_OWNER.
 #
 # Optional config:
 #
@@ -46,15 +78,23 @@
 # this environment, and it is bounded by `maxDenials`, because a plugin that can
 # stop command execution must never be the reason a session cannot finish.
 #
-# A SECOND family is recognized on the same seam (#7638): with the `minimal`
-# preset and a confining sandbox mode, every shell call dies instantly with
+# A SECOND family is recognized on the same seam (#7638, #8322): with the
+# `minimal` preset and a confining sandbox mode, every shell call dies instantly
+# with
 #
 #   PTY shell exited during startup
 #
 # The terminal backend cannot create the pseudo-console inside the sandbox, so
 # the child exits before its first prompt; retrying never helps and `minimal`
-# mounts no fallback shell tool. That advisory states the resolved mode, tells
-# the model to STOP rather than retry, and hands the user a preset choice — it
+# mounts no fallback shell tool. Inside that combination the HOST BINARY decides
+# (#8322, one runner and one ConPTY in every arm): a console-subsystem `node.exe`
+# host starts the confined shell, while the packaged desktop's GUI-subsystem
+# Electron host kills it silently — the same console rule the third family
+# states, where a restricted token can inherit a console but not create one. The
+# outcome is deterministic per (session mode x runner host), and the mode that
+# counts is the one the session records. That advisory states the resolved mode,
+# tells the model to STOP rather than retry, and hands the user the choices — a
+# preset swap, a profile-patch row, or a host that owns a console (#8313); it
 # never names a command to run (there is no shell to run it in) and never names
 # a shell tool the failing composition does not mount. It is sent only when the
 # mode the call actually ran under confines; otherwise the failure is left
@@ -63,6 +103,28 @@
 # above deliberately does NOT cover this family: its remedy is a patch-layer
 # change the user makes between sessions, not a command that repairs the
 # running one.
+#
+# A THIRD family is recognized from a value, not from text (#7876, #7877,
+# #8193, #8208, #8313):
+#
+#   [exit code: -1073741502]        (0xC0000142 STATUS_DLL_INIT_FAILED)
+#
+# A confined Windows child died while its native images were loading, i.e.
+# before its entry point. It reaches the tool result as an ordinary nonzero
+# exit code — upstream's runner-failure rules admit only exit 127 with the
+# `windows-acl-run: ` signature, so this code is never reclassified and never
+# arrives as an error — which is why a plugin reading only error results is
+# structurally blind to it, and why the model retries a command that cannot
+# start. The read is the shell tool's own canonical value
+# (`ToolExecutionSuccess.value`, `kind: 'foreground'`), so no line of rendered
+# text can be mistaken for it. The advisory states the resolved mode, says the
+# process never reached its entry point, enumerates the measured producers
+# (an MSYS2 / Git-Bash program that cannot create its signal pipe under the
+# restricted token; the sandbox runner hosted by a GUI-subsystem Electron binary
+# or spawned without a console), carries the one conversion the model can make
+# itself (rewrite the work as PowerShell or `cmd`), names the remedy #8193
+# measured — a real node.exe host, which the desktop ships — and says plainly
+# which producers it does not know. Like the second family, it is mode-gated.
 
 - insert:
     - id: sandbox-grant-advisor

package/lib/advice.js

@@ -56,13 +56,35 @@
  *   keeps the token lowering yields a workspace the confined child cannot write
  *   to. That is stated instead of a bare "no", because a reader told only "no"
  *   reaches for the workaround without knowing what else it would have to change.
+ *
+ *   **It also states what the grant leaves behind** (`#8312`, `#8314`), because
+ *   this is the module that hands over the command applying that grant, and these
+ *   are facts a reader needs at that moment rather than from a broken build in
+ *   another project later. The three entries are standing by design — the
+ *   backend's dispose path leaves them, and its own failure-cleanup comment calls
+ *   them "the intended end state (the reuse cache)" — the Low label is
+ *   inheritable and lives in the SACL (so resetting the DACL does not remove it),
+ *   and an NTFS hard link is a second name for one file object, so a pnpm
+ *   workspace's `node_modules` → content-addressed-store links carry that label
+ *   out of the tree and leave it on objects other projects build from. The
+ *   section offers no removal command: the maintainers' own diagnosis skill
+ *   reports the label and leaves it, removing one needs `WRITE_OWNER`, and this
+ *   project has no Windows host on which to verify a line.
  * - **The persistent-shell failure** (`pty-startup`) is *not* fixable by the
  *   caller — least of all by the model, which has no shell to run anything in.
  *   So its advice says so and stops: the remedy is a user-side preset choice,
  *   and the model's instruction is to stop retrying and use its file tools.
  *   Handing the model a command here would be advice to run something that
  *   cannot run, and naming a one-shot shell tool would be advice to call a tool
- *   the failing composition does not mount.
+ *   the failing composition does not mount. **Inside a confining mode the host
+ *   binary decides**, which `#8322` separated with one runner and one ConPTY in
+ *   every arm: a console-subsystem `node.exe` host starts the confined shell,
+ *   while the packaged desktop's GUI-subsystem Electron host kills it silently.
+ *   That is the same console rule the native-init family states — under the
+ *   restricted token a console can be inherited but not created — so the advisory
+ *   names the host alongside the mode, says the outcome is deterministic per
+ *   (session mode × host) rather than intermittent, and offers the console-owning
+ *   host as a user-side option `#8313` measured working.
  * - **The native-init death** (`native-init`) is the one whose remedy is **split**:
  *   the *class* is not the model's to fix, but one of its two measured producers
  *   is. A confined child that died with `STATUS_DLL_INIT_FAILED` never ran
@@ -108,12 +130,35 @@
  * @module
  */
 import { failureLine, STATUS_DLL_INIT_FAILED } from './signature.js';
-/** The upstream threads the ACL advisory is a stopgap for. */
-export const ACL_DISCUSSIONS = '#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816 / #8232 / #8272 / #8275';
-/** The upstream thread the persistent-shell advisory is a stopgap for. */
-export const PTY_DISCUSSIONS = '#7638';
-/** The upstream threads the native-init-death advisory is a stopgap for. */
-export const NATIVE_INIT_DISCUSSIONS = '#7876 / #7877 / #8193 / #8208';
+/**
+ * The upstream threads the ACL advisory is a stopgap for.
+ *
+ * The first twelve report the provisioning failure itself (the merged DACL +
+ * label write being refused). The last two, `#8312` and `#8314`, report the
+ * other end of the same backend — what its grant leaves behind once it
+ * *succeeds* — which the advisory states because it is the fact a reader needs
+ * at the moment it hands them the command that applies that grant.
+ */
+export const ACL_DISCUSSIONS = '#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816 / #8232 / #8272 / #8275 / #8312 / #8314';
+/**
+ * The upstream threads the persistent-shell advisory is a stopgap for.
+ *
+ * `#7638` is the failure and its three-arm control (the mode is the
+ * discriminator); `#8322` is the one that separated the arms inside a confining
+ * mode and found the sandbox runner's host binary — same runner, same ConPTY,
+ * console-subsystem `node.exe` host works where a GUI-subsystem one dies
+ * silently — which is why the advisory names the host as well as the mode.
+ */
+export const PTY_DISCUSSIONS = '#7638 / #8322';
+/**
+ * The upstream threads the native-init-death advisory is a stopgap for.
+ *
+ * `#8313` is the fifth report of the same code and the one that states the host
+ * difference from the outside: the desktop build fails where the same version
+ * launched from a terminal does not, which is the same variable the PTY family
+ * now names.
+ */
+export const NATIVE_INIT_DISCUSSIONS = '#7876 / #7877 / #8193 / #8208 / #8313';
 /** The documented prerequisite, quoted from the backend's README. */
 export const PREREQUISITE = 'granted directories must be caller-owned and grant `WRITE_OWNER`';
 /**
@@ -232,7 +277,9 @@ function nonFixes(failure, path) {
         '    supplies the DACL half and still not WRITE_OWNER, the right this call needs. In the second branch above',
         '    it is a legitimate first step with elevation; it is never the fix by itself.',
         `  icacls "${path}" /reset /T /C`,
-        '    restores inheritance, and inheritance is what supplied the Modify-only ACE above.',
+        '    restores inheritance, and inheritance is what supplied the Modify-only ACE above. Where it strips the last',
+        '    entry naming you, the directory ends up in exactly the state the diagnosis above describes — its only access',
+        '    the inherited `Authenticated Users:(M)` (#8314 measured that follow-on failure).',
         '',
     ];
 }
@@ -307,6 +354,76 @@ function degradedGrant() {
         'This is not offered here as a fix, and neither is `danger-full-access`.',
     ];
 }
+/**
+ * What the grant leaves behind once it applies, and how far its label travels.
+ *
+ * The advisory hands the reader a command that makes the backend's workspace
+ * grant succeed. This section says what that grant *is* from the other side —
+ * not as a warning against running it (without it nothing sandboxed runs at
+ * all) but because the effect outlives the session and reaches outside the
+ * workspace, and a reader who learns that from a broken build three projects
+ * later has learned it too late. `#8312` collected those far-away symptoms;
+ * `#8314` measured how the label gets there.
+ *
+ * Every claim is read off the shipped source rather than repeated from the
+ * reports: the standing edits and the dispose path that leaves them
+ * (`src/grant.ts`, whose `dispose` doc says the standing edits are skipped by
+ * design, and `src/index.ts`, whose fail-closed cleanup says the same in
+ * plainer words); the label's `(OI|CI)` inheritance and its home in the SACL
+ * (`src/acl.ts`, the merged security-information flags); and the hard-link
+ * boundary, which the backend's own suite pins as a known reach
+ * (`tests/runner.spec.ts`, "a workspace hard link lets the grant reach an
+ * external file object").
+ *
+ * Two things it deliberately does **not** do. It does not offer a removal
+ * command: the maintainers' own diagnosis skill reports the label and leaves it,
+ * removing one needs `WRITE_OWNER`, and this project has no Windows host to
+ * verify a line on — shipping an unverified removal command would be the same
+ * defect the rest of this module exists to answer. And it does not present the
+ * out-of-tree reach as universally true: it is what happens when the workspace
+ * contains hard links into a store on the same volume, which is what a pnpm
+ * install produces and what the report measured.
+ *
+ * Emitted for every class, like {@link versionBoundary} and for the same reason:
+ * the fact is about the package's grant (and the remedy the advisory hands over
+ * in every class is that grant), not about which of its two calls failed.
+ * @returns the section's lines, ending with the blank separator line.
+ */
+function standingEdits() {
+    return [
+        'What the grant leaves behind, once it applies — worth knowing before you run the command above, because the',
+        'backend does not take it back:',
+        '  The three entries are STANDING, deliberately, and nothing revokes them. The workspace grant is a reuse cache:',
+        '  the dispose path is documented to revoke the revocable (temp) grants and leave "the standing workspace edits',
+        '  in place", and the failure-cleanup path says it in plainer words — standing ACEs "are NOT revoked — they are',
+        '  the intended end state (the reuse cache), not an error artifact". They outlive the session and the harness',
+        '  exiting (`sandbox-windows-acl/src/grant.ts`, `src/index.ts`).',
+        '  The Low integrity label is INHERITABLE (`(OI|CI)`) and it lives in the SACL — which is why the `icacls',
+        '  /reset` above does not take it off: that command rebuilds the DACL. Windows starts a process at the minimum',
+        '  of the user\'s and the program\'s integrity, so anything started from a tree the harness has written to runs at',
+        '  LOW integrity, and none of the symptoms names DSH (#8312 collects them): an Electron/Chromium app exiting',
+        '  `0x80000003` at startup with no output (#7709), msbuild / dotnet / npm refusing or warning about the files as',
+        '  if they came from the Internet when no `Zone.Identifier` exists (#8175), a double-clicked `.exe` / `.cmd`',
+        '  reporting "publisher could not be verified" (#7735).',
+        '  It can also leave the workspace. An NTFS hard link is a SECOND NAME for one file object, so both names share',
+        '  one security descriptor — and a pnpm workspace is largely hard links (`node_modules` pointing into a',
+        '  content-addressed store on the same volume). An inheritable label written inside the tree therefore lands on',
+        '  the STORE\'s objects and stays there, after which every project using that store builds with executables that',
+        '  start at Low integrity, and the failure surfaces as the build tool rather than the sandbox: `vite build` unable',
+        '  to remove its own temp file, `pnpm install` unable to replace a hook (#8314 measured the whole chain). The',
+        '  backend\'s own suite pins the link reach as a known boundary — "a workspace hard link lets the grant reach an',
+        '  external file object" — and its README calls refusing multiply-linked files unviable for ordinary pnpm',
+        '  installs, which leaves the out-of-tree reach open rather than unknown.',
+        '  It is also why the label is not simply removable here: the built-in `diagnose-windows-sandbox-acl` skill',
+        '  (0.2.0 and later) reports `LOW_LABEL` and by design does not remove it, and removing an integrity label needs',
+        '  WRITE_OWNER — the same right this whole failure is about. This advisory hands over no removal command: the',
+        '  maintainers\' own skill does not, and an unverified one would be the defect this plugin exists to answer.',
+        'None of this makes the command above the wrong move — without it, nothing sandboxed runs in this workspace. It',
+        'is what the harness does to a directory it has been pointed at, and it is worth knowing before rather than',
+        'discovering it as a broken build in some other project later.',
+        '',
+    ];
+}
 /**
  * Build the advisory attached to the failing tool result.
  *
@@ -395,6 +512,7 @@ function aclAdvisory(failure, href) {
         'inherits Full control for you — and open the session on that one.',
         '',
         ...nonFixes(failure, path),
+        ...standingEdits(),
         ...(failure.klass === 'apply-denied' ? [...degradedGrant(), ''] : []),
         'How to read this: the harness documents the prerequisite (' + PREREQUISITE + ') and this',
         'error does not name it yet, so the advice is delivered here instead. This is a stopgap, ' + where + '.',
@@ -542,7 +660,7 @@ function nativeInitAdvisory(failure, mode, onElectron, href) {
  * @returns the user-role notice text.
  */
 function ptyAdvisory(failure, mode, tool, href) {
-    const where = href === undefined ? `tracked upstream (discussion ${PTY_DISCUSSIONS})` : `tracked upstream: ${href}`;
+    const where = href === undefined ? `tracked upstream (discussions ${PTY_DISCUSSIONS})` : `tracked upstream: ${href}`;
     const call = tool === undefined ? 'This tool' : `The \`${tool}\` tool`;
     return [
         'Persistent shell failed to start — command execution is unavailable in this session, and retrying cannot fix it.',
@@ -556,6 +674,24 @@ function ptyAdvisory(failure, mode, tool, href) {
         'shell works under `danger-full-access`, and the one-shot shell tool works under the same confining mode:',
         'persistent PTY × confining sandbox is the combination that fails.',
         '',
+        'Which sessions fail inside that combination is not chance — it is deterministic per (session mode × the host',
+        'binary carrying the sandbox runner), so a "working now" attempt in the same session is not evidence of flakiness.',
+        'Measured against the desktop build with the same runner and the same ConPTY in every arm (#8322):',
+        '  - runner hosted by a plain console-subsystem `node.exe` → the confined shell starts, prompt and shell-integration',
+        '    marks correct;',
+        '  - runner hosted by the packaged desktop\'s GUI-subsystem Electron executable (started with',
+        '    `ELECTRON_RUN_AS_NODE=1`) → the child dies silently: zero bytes on stdout AND stderr, and the non-interactive',
+        '    arm exits 0 with everything it printed lost.',
+        'The rule behind both this and the `0xC0000142` family is the one stated there for its own case: under the',
+        'restricted token a console can be INHERITED but not CREATED — so the host binary, the thing that owns a console',
+        'or owns none, is what the arms above turn on. It is also why the same build behaves differently depending on how',
+        'it was started: the same version run as the desktop app fails, while the Web UI started from a terminal —',
+        'whose `process.execPath` is a real `node.exe` — is reported working under the same confining mode (#8313).',
+        'And the mode that decides is the one the SESSION records, not the one the environment now holds: a session',
+        'whose stream recorded the confining mode keeps failing',
+        'after the app is restarted with a different mode in the environment, while switching it inside that session',
+        'takes effect immediately (#8322).',
+        '',
         'Do NOT retry, and do not look for a command that fixes it: every attempt will fail identically, and there is no',
         'shell to run a command in. Use your file read/write tools instead, and hand the choice below to the user.',
         '',
@@ -566,8 +702,11 @@ function ptyAdvisory(failure, mode, tool, href) {
         `     \`${GLOBAL_PATCH}\` for every profile — replacing its \`persistent-shell\` group with`,
         `     \`${ONE_SHOT_SHELL}\` (a one-shot subprocess, no PTY); the patch layer is yours, so an upgrade`,
         '     will not overwrite it; or',
-        '  3. run the session with `danger-full-access`, which drops the very confinement the sandbox exists to give.',
-        '     Prefer 1 or 2.',
+        '  3. run the session from a host that owns a console instead of the packaged desktop app — the Web UI started',
+        '     from a terminal (`process.execPath` is a real `node.exe` there) was reported working under the same',
+        '     confining mode and the same version (#8313); or',
+        '  4. run the session with `danger-full-access`, which drops the very confinement the sandbox exists to give.',
+        '     Prefer 1 to 3.',
         '',
         'How to read this: the failure names no cause and points at no remedy, so the diagnosis is delivered here instead.',
         'This is a stopgap, ' + where + '. Unless the mode is `danger-full-access`, this plugin stays silent, because a',

package/lib/types/advice.d.ts

@@ -56,13 +56,35 @@
  *   keeps the token lowering yields a workspace the confined child cannot write
  *   to. That is stated instead of a bare "no", because a reader told only "no"
  *   reaches for the workaround without knowing what else it would have to change.
+ *
+ *   **It also states what the grant leaves behind** (`#8312`, `#8314`), because
+ *   this is the module that hands over the command applying that grant, and these
+ *   are facts a reader needs at that moment rather than from a broken build in
+ *   another project later. The three entries are standing by design — the
+ *   backend's dispose path leaves them, and its own failure-cleanup comment calls
+ *   them "the intended end state (the reuse cache)" — the Low label is
+ *   inheritable and lives in the SACL (so resetting the DACL does not remove it),
+ *   and an NTFS hard link is a second name for one file object, so a pnpm
+ *   workspace's `node_modules` → content-addressed-store links carry that label
+ *   out of the tree and leave it on objects other projects build from. The
+ *   section offers no removal command: the maintainers' own diagnosis skill
+ *   reports the label and leaves it, removing one needs `WRITE_OWNER`, and this
+ *   project has no Windows host on which to verify a line.
  * - **The persistent-shell failure** (`pty-startup`) is *not* fixable by the
  *   caller — least of all by the model, which has no shell to run anything in.
  *   So its advice says so and stops: the remedy is a user-side preset choice,
  *   and the model's instruction is to stop retrying and use its file tools.
  *   Handing the model a command here would be advice to run something that
  *   cannot run, and naming a one-shot shell tool would be advice to call a tool
- *   the failing composition does not mount.
+ *   the failing composition does not mount. **Inside a confining mode the host
+ *   binary decides**, which `#8322` separated with one runner and one ConPTY in
+ *   every arm: a console-subsystem `node.exe` host starts the confined shell,
+ *   while the packaged desktop's GUI-subsystem Electron host kills it silently.
+ *   That is the same console rule the native-init family states — under the
+ *   restricted token a console can be inherited but not created — so the advisory
+ *   names the host alongside the mode, says the outcome is deterministic per
+ *   (session mode × host) rather than intermittent, and offers the console-owning
+ *   host as a user-side option `#8313` measured working.
  * - **The native-init death** (`native-init`) is the one whose remedy is **split**:
  *   the *class* is not the model's to fix, but one of its two measured producers
  *   is. A confined child that died with `STATUS_DLL_INIT_FAILED` never ran
@@ -109,12 +131,35 @@
  */
 import type { ProvisioningFailure, RecognizedFailure } from './signature.js';
 import type { SandboxModeName } from './mode.js';
-/** The upstream threads the ACL advisory is a stopgap for. */
-export declare const ACL_DISCUSSIONS = "#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816 / #8232 / #8272 / #8275";
-/** The upstream thread the persistent-shell advisory is a stopgap for. */
-export declare const PTY_DISCUSSIONS = "#7638";
-/** The upstream threads the native-init-death advisory is a stopgap for. */
-export declare const NATIVE_INIT_DISCUSSIONS = "#7876 / #7877 / #8193 / #8208";
+/**
+ * The upstream threads the ACL advisory is a stopgap for.
+ *
+ * The first twelve report the provisioning failure itself (the merged DACL +
+ * label write being refused). The last two, `#8312` and `#8314`, report the
+ * other end of the same backend — what its grant leaves behind once it
+ * *succeeds* — which the advisory states because it is the fact a reader needs
+ * at the moment it hands them the command that applies that grant.
+ */
+export declare const ACL_DISCUSSIONS = "#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816 / #8232 / #8272 / #8275 / #8312 / #8314";
+/**
+ * The upstream threads the persistent-shell advisory is a stopgap for.
+ *
+ * `#7638` is the failure and its three-arm control (the mode is the
+ * discriminator); `#8322` is the one that separated the arms inside a confining
+ * mode and found the sandbox runner's host binary — same runner, same ConPTY,
+ * console-subsystem `node.exe` host works where a GUI-subsystem one dies
+ * silently — which is why the advisory names the host as well as the mode.
+ */
+export declare const PTY_DISCUSSIONS = "#7638 / #8322";
+/**
+ * The upstream threads the native-init-death advisory is a stopgap for.
+ *
+ * `#8313` is the fifth report of the same code and the one that states the host
+ * difference from the outside: the desktop build fails where the same version
+ * launched from a terminal does not, which is the same variable the PTY family
+ * now names.
+ */
+export declare const NATIVE_INIT_DISCUSSIONS = "#7876 / #7877 / #8193 / #8208 / #8313";
 /** The documented prerequisite, quoted from the backend's README. */
 export declare const PREREQUISITE = "granted directories must be caller-owned and grant `WRITE_OWNER`";
 /**

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. Family 2, the persistent shell (#7638): 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. 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, states the resolved mode, tells the model to stop rather than retry, and hands the user-side preset choice over \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.9.0",
+  "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",
   "type": "module",
   "main": "lib/index.js",
   "types": "lib/types/index.d.ts",