@argszero/cordis-plugin-sandbox-grant-advisor 0.7.1 → 0.8.1

package/README.md

@@ -35,12 +35,24 @@ stuck.
 
 ### 1. Workspace provisioning — the Windows ACL failure (`acl-provisioning`)
 
-Six reports describe this exact line: [discussion #7538], [discussion #7622],
-[discussion #7646], [discussion #7720], [discussion #7750], [discussion #7735]
-(the last two on data-volume workspaces, where *no* ACE names the caller at all —
-the inherited `Authenticated Users: Modify` is the whole of their access). In each
-one every sandboxed command fails the same way, before it runs, and the error names
-neither the missing right nor a remedy.
+Seven reports describe this exact line: [discussion #7538], [discussion #7622],
+[discussion #7646], [discussion #7720], [discussion #7750], [discussion #7735] and
+[discussion #8232] (the last three on data-volume workspaces, where *no* ACE names
+the caller at all — the inherited `Authenticated Users: Modify` is the whole of
+their access). In each one every sandboxed command fails the same way, before it
+runs, and the error names neither the missing right nor a remedy.
+
+`#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
+that writes, because the grant is materialized before the command runs at all. The
+other is the **scope of the repair**: the `(OI)(CI)(WO)` line covers *this*
+directory and its children, so a second workspace root on the same volume is a
+sibling rather than a child and needs the same line once more — which is why that
+reporter saw a second workspace fail on a machine whose first one was already
+repaired. The report also reaches the same root cause on its own (the merged write
+wanting `WRITE_OWNER`, which owner-implicit rights do not carry), matching the
+backend's documented prerequisite.
 
 `#7720` is worth reading for where the failure lands: the grant is materialized
 at sandbox **initialization**, so this is not one refused operation but *every*
@@ -93,6 +105,13 @@ Two consequences follow from that one line:
    what confines deletes to the workspace, and reverting it reintroduces the
    escape it closed. `#7750` asks for exactly this and explains why it is a
    usability regression traded for a security fix.
+5. **The repair is per-directory, and the report is what established that.** `#8232`
+   applied the `(WO)` line, watched the workspace start working, and then hit the
+   same error on a *second* workspace root on the same volume. `(OI)(CI)` carries
+   the ACE into *children* of the directory that received it and nowhere else, so a
+   sibling root is untouched by it. One line per workspace root is therefore the
+   correct shape of the remedy, not one line per machine — and the advisory says so,
+   because the natural reading of "it worked" is "it is fixed".
 
 The grant is materialized lazily, on the first confined call, and **nothing is
 cached when it throws** — so the same failure repeats per command (850 calls
@@ -236,8 +255,9 @@ the advisory never names the dead directory.
 
 ### 3. A confined child that never started (`native-init`)
 
-Three reports of one exit code: [`#7876`] and [`#8193`] (the packaged desktop
-app, measured twice) and [`#7877`] (MSYS2 / Git Bash). All are `0xC0000142`
+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`
 `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
@@ -259,65 +279,101 @@ Two producers have been measured under a confining mode:
    (`@deepseek-ai/dsh-base/cordis.patch.yml`), so the combination is likely
    never covered upstream. The **one conversion a model can make itself** is to
    write the same work as a PowerShell or `cmd` command.
-2. **The packaged desktop app's sandbox runner** ([`#7876`], [`#8193`]).
+2. **The packaged desktop app's sandbox runner** ([`#8193`], [`#8208`]).
    `dsh-sandbox-local` launches the runner as `[process.execPath, entry]`, and
-   in the packaged build `process.execPath` is the Electron executable. Two
-   measurements of that host exist and — from inside a session — they are
-   indistinguishable, so the advisory names **both** instead of asserting one:
-   **(a)** the runner does not start at all — the Electron binary begins as an
-   *application* unless the child's environment carries `ELECTRON_RUN_AS_NODE=1`,
-   so nothing on the runner path ran ([`#7876`]); **(b)** the runner *does*
-   start — the desktop launcher sets exactly that variable — and the command
-   still dies, because the restricted token is derived from the Electron process
-   image and the child does not survive being started under it ([`#8193`]). A
-   reader outside the session separates them (is `ELECTRON_RUN_AS_NODE` set for
-   that host, and does the ACL runner appear among its processes while the
-   command runs?); from inside the session they are one finding with one remedy.
-   The unpacked node host (`node apps/cli/lib/bin.js web`) is unaffected. The
-   plugin reports whether *this* process is an Electron binary
-   (`process.versions.electron`) as a measured fact rather than assuming it,
-   because that is the check the discriminator turns on. **0.6.0 asserted shape
-   (a) alone** — "so the runner never runs" — and handed the Electron reader a
-   cause that [`#8193`] measures to be false; the single-cause sentence is gone,
-   and a test arm keeps it gone.
-
-   **The remedy is the host, and 0.7.1 says so in that order.** [`#8193`] did not
-   only split the producer — it measured the way out: hosted on the desktop's own
-   bundled standalone node
+   in the packaged build `process.execPath` is the Electron executable. **The
+   mechanism is the runner's console, not its token** ([`#8208`]): the confined
+   child inherits a console from the runner, and a runner that owns none leaves
+   the child to ask for one of its own — which a restricted token may not have.
+   The capture is three lines: `conhost.exe` is created *by the restricted child*,
+   exits `0xC0000022 STATUS_ACCESS_DENIED`, and the child then dies with
+   `0xC0000142`. Two console-less configurations are measured, and they share that
+   mechanism: **(a)** the host binary is a GUI-subsystem program, which never owns
+   a console — the packaged desktop, where every confined command dies this way
+   ([`#8193`]); **(b)** the host binary is a real console-subsystem `node.exe` and
+   the runner was still spawned without a console, because `DETACHED_PROCESS` was
+   set — `spawnSync(node, [runner, …], { detached: true })` returns `0xC0000142`
+   where the identical call without that flag returns `0` ([`#8208`]). Shape (b) is
+   the one worth handing over, because it needs no desktop and no particular
+   machine. **What is *not* the discriminator is the token**: [`#8208`] compared
+   `whoami /groups` and `/priv` from children of a working node host and of the
+   failing Electron host and found them identical, and a low-integrity `cmd.exe`
+   runs fine on that machine. The plugin reports whether *this* process is an
+   Electron binary (`process.versions.electron`) as a measured fact rather than
+   assuming it.
+
+   **`0.7.x` named two shapes and explained them with the wrong mechanism, and
+   `0.8.0` withdraws one of the shapes outright.** The withdrawn shape is "the
+   runner does not start at all, because `ELECTRON_RUN_AS_NODE=1` is missing": the
+   desktop sets that variable on its own host child
+   (`apps/desktop/src/host-process.ts` → `desktopNodeEnvironment()`,
+   `apps/desktop/src/node-environment.ts:15`), so nothing on the runner path can
+   fail to start for want of it — and [`#8208`] measured the variable present in
+   *both* hosts, including the one that works. The token story goes with it, for
+   the same measurement. A cause the advisory shipped twice earns its sentence
+   when it is retracted, and test arms keep both retractions in place.
+
+   **The remedy is a real node host — with one condition riding on it.** [`#8193`]
+   measured the way out: hosted on the desktop's own bundled standalone node
    (`resources/runtime/primary-runtime/dependencies/node/bin/node.exe`, v24.21.0)
    the *same* confined `pwsh.exe` / `cmd.exe` spawns succeed (exit 81 / 82), with
    workspace, temp directory, mode, SIDs, target and runner `sha256` all held
-   constant. The advisory now leads the Electron branch with that, and demotes
-   `danger-full-access` to what it actually is — a way to **confirm** the
-   diagnosis, not a fix, and on this platform one that silently removes the
-   sandbox from every shell call. The reporter's own reason is the one the plugin
-   repeats: *"the practical effect is that Windows Desktop users must escalate to
-   full access for all shell work, which silently removes the sandbox on that
-   platform"*, and they asked explicitly that this not be "fixed" with
-   `--disable-sandbox` / `--disable-gpu-sandbox` — those disable Chromium's
-   renderer sandbox, a different layer from the DSH file policy. The advisory also
-   warns off the opposite-looking move: unsetting `ELECTRON_RUN_AS_NODE` does not
-   help, because the desktop's runner **is** that Electron binary and without the
-   variable it cannot execute `runner.js` at all — the interaction [`#8193`]
-   records with [`#8174`], where a fix that tombstones the variable in the shared
-   child environment would take the ACL runner down with it, so the two changes
-   have to land together.
+   constant. [`#8208`] reproduced it (exit `0`, the command's own stdout intact)
+   on the same runtime installed for workspace dependencies
+   (`%USERPROFILE%\.dsh\dsh-runtimes\dsh-primary-runtime\dependencies\node\bin\node.exe`,
+   present once `load_workspace_dependencies` has run) and with `windowsHide` both
+   set and unset. **The condition is that the runner must be spawned *with* a
+   console** — not with `DETACHED_PROCESS` — because a real host alone is not
+   enough when that flag is set ([`#8208`]): the host binary supplies the console
+   and the spawn flag is what can take it away again. Where no real host can be
+   put in front of the runner, the same effect fits inside it: `AllocConsole`
+   before the restricted spawn, with the three standard handles restored
+   afterwards, in `dsh-win32-process`'s `createRestrictedProcess` — the funnel
+   every restricted child goes through. [`#8208`] measured `cmd /c exit` and
+   `pwsh -c "Write-Output …"` both reaching `0` with stdout intact under that
+   change, and as a no-op on a runner that already owns a console; it costs a
+   `user32` binding and one console host per runner process. `danger-full-access`
+   is demoted to what it actually is — a way to **confirm** the diagnosis, not a
+   fix, and on this platform one that silently removes the sandbox from every
+   shell call. The reporter's own reason is the one the plugin repeats: *"the
+   practical effect is that Windows Desktop users must escalate to full access for
+   all shell work, which silently removes the sandbox on that platform"*, and they
+   asked explicitly that this not be "fixed" with `--disable-sandbox` /
+   `--disable-gpu-sandbox` — those disable Chromium's renderer sandbox, a
+   different layer from the DSH file policy. The advisory also warns off the
+   opposite-looking move: unsetting `ELECTRON_RUN_AS_NODE` does not help, because
+   the desktop's runner **is** that Electron binary and dropping the variable
+   would take `runner.js` down with it — the interaction [`#8193`] records with
+   [`#8174`], where a fix that tombstones the variable in the shared child
+   environment would take the ACL runner down with it, so the two changes have to
+   land together.
 
    **What the flag vocabulary actually is.** The backend's own source records one
    inherent boundary: *"console isolation is unavailable — children share the host
    console (`CREATE_NO_WINDOW` / `CREATE_NEW_CONSOLE` children die with
    `STATUS_DLL_INIT_FAILED` under the restriction)"*
-   (`packages/sandbox/sandbox-windows-acl/src/index.ts`), echoed at
-   `packages/subprocess/win32-process/src/process.ts:454`. [`#8193`] refines that
-   recording instead of repeating it, and the refinement is worth keeping exact:
-   the restricted-token path spawns with **`CREATE_SUSPENDED` alone**
-   (`process.ts:537-545`) and the ordinary current-token path with
-   **`CREATE_SUSPENDED | CREATE_UNICODE_ENVIRONMENT`** (`process.ts:567`, i.e.
-   `0x404`); `CREATE_NO_WINDOW` (`0x08000000`) is **not a constant anywhere in
-   that source** — only those two comments name it at all. So the flags in use are
-   a necessary-but-insufficient ingredient: the same flags that are fatal under an
-   Electron host succeed under a real-node host, and the host process image is
-   what turns them fatal.
+   (`packages/sandbox/sandbox-windows-acl/README.md:119`), echoed at
+   `packages/subprocess/win32-process/src/process.ts:454`. [`#8208`] **explains**
+   that recording instead of repeating it, and the explanation is the invariant
+   the two shapes share: **in a restricted token a console can be inherited but
+   not created.** The creation flags actually passed are three sets and none of
+   them is `CREATE_NO_WINDOW` — `0` on the piped path (`process.ts:243`, the path a
+   shell call takes), `CREATE_SUSPENDED` on the inherited-job path
+   (`process.ts:542`) and `CREATE_SUSPENDED | CREATE_UNICODE_ENVIRONMENT` on the
+   ordinary path (`process.ts:567`, i.e. `0x404`); `CREATE_NO_WINDOW`
+   (`0x08000000`) is **not a constant anywhere in that source**. Those flags are
+   fatal under a console-less runner and harmless under one that owns a console —
+   so it is the console, not the flag list, that decides. `0.7.x` wrote the
+   two-set version of that list and called the flags "a necessary ingredient ...
+   the host process image is what turns it fatal"; both halves were wrong, and
+   `0.8.0` replaces them.
+
+   **One arm was applied, measured, and rejected.** Putting `DETACHED_PROCESS` on
+   the *restricted child* removes its console request and does stop the crash —
+   but `pwsh` then exits `0` with **zero bytes on stdout and stderr**, while
+   `cmd.exe` keeps its output ([`#8208`]). That trades a loud failure for a silent
+   one on the interpreter most likely to be used, so the advisory names it as a
+   non-remedy instead of offering it; the runner-side remedies keep the output.
 
 **Why this family is read from a successful result.** The producer never marks
 it an error, and that is a fact about upstream rather than a choice here:
@@ -619,13 +675,17 @@ the current runtime cannot distinguish rather than counting it as a pass.
 [discussion #7771]: https://github.com/deepseek-ai/deepseek-harness/discussions/7771
 [discussion #7804]: https://github.com/deepseek-ai/deepseek-harness/discussions/7804
 [discussion #7816]: https://github.com/deepseek-ai/deepseek-harness/discussions/7816
+[discussion #8232]: https://github.com/deepseek-ai/deepseek-harness/discussions/8232
 [discussion #7638]: https://github.com/deepseek-ai/deepseek-harness/discussions/7638
 [discussion #7876]: https://github.com/deepseek-ai/deepseek-harness/discussions/7876
 [discussion #7877]: https://github.com/deepseek-ai/deepseek-harness/discussions/7877
+[discussion #8208]: https://github.com/deepseek-ai/deepseek-harness/discussions/8208
 [#7750]: https://github.com/deepseek-ai/deepseek-harness/discussions/7750
 [#7771]: https://github.com/deepseek-ai/deepseek-harness/discussions/7771
 [#7804]: https://github.com/deepseek-ai/deepseek-harness/discussions/7804
 [#7876]: https://github.com/deepseek-ai/deepseek-harness/discussions/7876
 [#7877]: https://github.com/deepseek-ai/deepseek-harness/discussions/7877
+[#8232]: https://github.com/deepseek-ai/deepseek-harness/discussions/8232
 [#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

package/lib/advice.js

@@ -58,12 +58,21 @@
  *   is guess which producer this is: the code alone cannot say, and the two
  *   checks it hands over are facts the reader holds (what program they ran;
  *   whether this is the packaged desktop app, which the plugin reports rather
- *   than assumes). That Electron host is itself **two measurements**, not one —
- *   a runner that never started at all, and a runner that did start and whose
- *   child cannot survive the restricted token derived from an Electron process
- *   image — and the advisory names both instead of asserting the one it shipped
- *   first, because a session cannot tell them apart and a confidently wrong
- *   cause is worse than two named ones with one shared remedy.
+ *   than assumes). That Electron host was shipped as **two measurements**; since
+ *   0.8.0 it is **one mechanism, named**: the runner must own a *console* for the
+ *   confined child to inherit, and when it owns none the child's own console
+ *   request is denied under the restricted token (`#8208` traced it to
+ *   `conhost.exe` created by the restricted child, exiting `STATUS_ACCESS_DENIED`).
+ *   The two measured console-less shapes are a GUI-subsystem host image (the
+ *   packaged desktop) and a `DETACHED_PROCESS` runner under a real `node.exe`
+ *   host — the second reproducible on any machine, which is what makes it the
+ *   check worth handing over. The shape 0.7.x led with, "the runner never started
+ *   at all", is **withdrawn**: the desktop's own host child is started with
+ *   `ELECTRON_RUN_AS_NODE=1` (`apps/desktop/src/host-process.ts` ->
+ *   `desktopNodeEnvironment()`), so nothing on the runner path fails to start for
+ *   want of that variable. A withdrawn cause earns its sentence because this
+ *   advisory shipped it twice; a confidently wrong cause is worse than two named
+ *   ones with one shared remedy.
  *
  * Both give a **discriminator, not just a remedy**: applying a fix without
  * confirming the cause teaches nothing when the fix does not work. For the ACL
@@ -83,11 +92,11 @@
  */
 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';
+export const ACL_DISCUSSIONS = '#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816 / #8232';
 /** 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';
+export const NATIVE_INIT_DISCUSSIONS = '#7876 / #7877 / #8193 / #8208';
 /** The documented prerequisite, quoted from the backend's README. */
 export const PREREQUISITE = 'granted directories must be caller-owned and grant `WRITE_OWNER`';
 /**
@@ -269,6 +278,8 @@ function aclAdvisory(failure, href) {
     const where = href === undefined ? `tracked upstream (discussions ${ACL_DISCUSSIONS})` : `tracked upstream: ${href}`;
     return [
         'Sandbox provisioning failed — no sandboxed command can run in this workspace until its ACL applies.',
+        'The failure belongs to the WORKSPACE, not to the command: under this mode a command that only reads',
+        'fails identically, so trying a different or more harmless command is not a retry that can succeed.',
         '',
         'What was reported:',
         `  ${failureLine(failure)}`,
@@ -293,6 +304,9 @@ function aclAdvisory(failure, href) {
         `  cmd:        icacls "${path}" /grant "%USERNAME%:(OI)(CI)(WO)"`,
         'WRITE_OWNER is exactly the right the prerequisite names, so this grants nothing the harness did not ask for,',
         'and (OI)(CI) makes the ACE inheritable, so one command reaches the workspace\'s existing subdirectories.',
+        'The grant is still scoped to THIS directory and its children: another workspace root on the same volume is',
+        'a sibling rather than a child, so it needs the same line once — which is why a second workspace fails on a',
+        'machine where the first one was already repaired.',
         'Full control works just as well — the same line with `F` in place of `(WO)`:',
         `  icacls "${path}" /grant "$env:USERNAME:(OI)(CI)F"`,
         'Why `(WO)` is the whole of what is missing there: an owner holds READ_CONTROL and WRITE_DAC implicitly,',
@@ -367,46 +381,76 @@ function nativeInitAdvisory(failure, mode, onElectron, href) {
         '     continue — do not retry the MSYS2 program.',
         '  2. The packaged desktop application\'s sandbox runner. `dsh-sandbox-local` starts the runner as',
         '     `[process.execPath, runner.js]`, and in the packaged build `process.execPath` is the Electron',
-        '     executable. Two measurements of that host exist and from inside a session they are',
-        '     indistinguishable, so both are named here rather than one asserted:',
-        '     (a) the runner does not start at all: the Electron binary begins as an *application* unless the',
-        '         child\'s environment carries `ELECTRON_RUN_AS_NODE=1`, so nothing on the runner path ran (#7876);',
-        '     (b) the runner does start — the desktop launcher sets exactly that variable — and the command still',
-        '         dies, because the restricted token is derived from the Electron process image and the child does',
-        '         not survive being started under it (#8193).',
-        '     A reader outside the session separates them (is `ELECTRON_RUN_AS_NODE` set for that host, and does',
-        '     the ACL runner appear among its processes while the command runs?); from inside the session they are',
-        '     one finding with one remedy, so nothing here waits on telling them apart.',
+        '     executable. The mechanism behind this one is the runner\'s CONSOLE, not its token: the confined',
+        '     child inherits a console from the runner, and a runner that owns none leaves the child to ask for one',
+        '     of its own — which a restricted token is not allowed to have. #8208 captured the sequence: `conhost.exe`',
+        '     is created BY the restricted child, exits `0xC0000022 STATUS_ACCESS_DENIED`, and the child then dies',
+        '     with the code above. Both console-less configurations are measured:',
+        '     (a) the host binary is a GUI-subsystem program, which never owns a console — the packaged desktop,',
+        '         where every confined command dies this way (#8193);',
+        '     (b) the host binary is a real console-subsystem `node.exe` and the runner was still spawned without a',
+        '         console, because `DETACHED_PROCESS` was set: `spawnSync(node, [runner, …], { detached: true })`',
+        '         returns `0xC0000142` while the same call without that flag returns `0` (#8208). That arm needs no',
+        '         desktop and no particular machine, so it is the check worth running here.',
+        '     What is NOT the discriminator: the token. #8208 compared `whoami /groups` and `/priv` from children of',
+        '     a working node host and of the failing Electron host — identical, down to the group count and session —',
+        '     and a low-integrity `cmd.exe` runs fine on that machine, so neither the token nor low integrity alone',
+        '     explains this.',
         ...(onElectron
             ? [
-                '     This process IS an Electron binary (`process.versions.electron` is set), so that producer applies here.',
-                '     The way out is a real node host, not a wider mode: the packaged desktop ships one at',
-                '     `resources/runtime/primary-runtime/dependencies/node/bin/node.exe`, and the unpacked',
-                '     `node apps/cli/lib/bin.js web` host works for the same reason — the same confined `pwsh`/`cmd` calls',
-                '     start there (#8193 measured exit 81/82). The command starts there in either shape, and that — the',
-                '     host, not the flags — is the discriminator. `danger-full-access` only CONFIRMS the diagnosis: on this',
-                '     platform it silently removes the sandbox from every shell call. Do not unset `ELECTRON_RUN_AS_NODE`',
-                '     instead either — the desktop runner IS that Electron binary, so without it `runner.js` cannot',
-                '     execute at all (#8193 records this interaction with #8174).',
+                '     This process IS an Electron binary (`process.versions.electron` is set), so a GUI-subsystem host',
+                '     applies here. The way out is a real node host — the packaged desktop ships one at',
+                '     `resources/runtime/primary-runtime/dependencies/node/bin/node.exe`, and the same runtime installed',
+                '     for workspace dependencies lands at',
+                '     `%USERPROFILE%\\.dsh\\dsh-runtimes\\dsh-primary-runtime\\dependencies\\node\\bin\\node.exe` (present',
+                '     once `load_workspace_dependencies` has run) — and the unpacked `node apps/cli/lib/bin.js web` host',
+                '     works for the same reason: the same confined `pwsh`/`cmd` calls start there (#8193 measured exit',
+                '     81/82; #8208 measured exit 0 with the command\'s own stdout intact, with and without `windowsHide`).',
+                '     ONE CONDITION RIDES WITH THAT: the runner must be spawned WITH a console, i.e. not with',
+                '     `DETACHED_PROCESS`. A real host alone is not enough if that flag is set (#8208) — the host binary is',
+                '     what supplies the console, and the spawn flag is what can take it away again.',
+                '     If no real node host can be put in front of the runner, the same effect fits inside it: `AllocConsole`',
+                '     before the restricted spawn, with the three standard handles restored afterwards, in',
+                '     `dsh-win32-process`\'s `createRestrictedProcess` — the funnel every restricted child goes through.',
+                '     #8208 measured `cmd /c exit` and `pwsh -c "Write-Output …"` both reaching 0 with stdout intact under',
+                '     that change, and as a no-op on a runner that already owns a console; it costs a `user32` binding and',
+                '     one console host per runner process.',
+                '     `danger-full-access` only CONFIRMS the diagnosis: on this platform it silently removes the sandbox',
+                '     from every shell call. Do not unset `ELECTRON_RUN_AS_NODE` instead either — the desktop runner IS',
+                '     that Electron binary, so dropping the variable would take `runner.js` down with it (#8193 records',
+                '     this interaction with #8174).',
             ]
             : [
                 '     This process is NOT an Electron binary (`process.versions.electron` is unset), so the runner is a real',
-                '     Node binary here and that producer cannot be the cause. If the program was not an MSYS2 one either,',
-                '     this failure is outside both measured producers: stop and hand it to the user.',
+                '     Node binary here and a GUI-subsystem host cannot be the cause. One measured shape is still open: a',
+                '     runner that owns no console because it was spawned with `DETACHED_PROCESS` fails exactly this way on a',
+                '     real node host too (#8208) — that is a property of how this host was launched, not of the build. If the',
+                '     program was not an MSYS2 one either, and the runner was not spawned detached, this failure is outside',
+                '     both measured producers: stop and hand it to the user.',
             ]),
         '',
         'Do not retry this call: the environment has not changed, and the identical call produces the identical',
         'code. Convert the work only in case 1; otherwise stop and hand it to the user.',
         '',
         'Honest boundary — 0xC0000142 has producers this list does not have: a program that cannot load one of',
-        'its own DLLs dies this way too, and the backend\'s own source records that a child created with a hidden',
-        'console window can as well (`CREATE_NO_WINDOW` can fail restricted-token DLL initialization). #8193',
-        'refines that recording rather than repeating it: `CREATE_NO_WINDOW` is not among the flags actually passed',
-        '(they are `CREATE_SUSPENDED`, and `CREATE_SUSPENDED | CREATE_UNICODE_ENVIRONMENT` on the unrestricted',
-        'path), and the same flags succeed under a real-node host — so the flag is a necessary ingredient and the',
-        'host process image is what turns it fatal. This is not a claim that the sandbox caused the failure — the',
-        'code cannot say that. What is claimed is narrower and checkable: the process never reached its entry',
-        'point, and under this mode these two producers are known.',
+        'its own DLLs dies this way too, and the backend\'s own source records the console case as an inherent',
+        'limit of the backend (`CREATE_NO_WINDOW` / `CREATE_NEW_CONSOLE` children die with `STATUS_DLL_INIT_FAILED`',
+        'under the restriction). #8208 explains that limit instead of repeating it, and the explanation is what the',
+        'two shapes above share: in a restricted token a console can be INHERITED but not CREATED. The creation',
+        'flags actually passed are three sets and none of them is `CREATE_NO_WINDOW` — `0` on the piped path,',
+        '`CREATE_SUSPENDED` on the inherited-job path, and `CREATE_SUSPENDED | CREATE_UNICODE_ENVIRONMENT` on the',
+        'ordinary path. Those same flags are fatal under a console-less runner and harmless under one that owns a',
+        'console, so it is the console and not the flag list that decides.',
+        '',
+        'One arm of this family was applied, measured, and rejected — named so a reader does not reach for it:',
+        'putting `DETACHED_PROCESS` on the RESTRICTED CHILD removes its console request and does stop the crash,',
+        'but `pwsh` then exits 0 with zero bytes on stdout AND stderr, while `cmd.exe` keeps its output (#8208).',
+        'That trades a loud failure for a silent one on the interpreter most likely to be used, so the runner-side',
+        'remedies above — which keep the output — are the ones to take.',
+        '',
+        'This is not a claim that the sandbox caused the failure — the code cannot say that. What is claimed is',
+        'narrower and checkable: the process never reached its entry point, and under this mode these producers are',
+        'known.',
         '',
         'This is a stopgap, ' + where + '. What it is NOT: this plugin neither changes an environment nor',
         'widens the sandbox — the checks above are yours to make, and `danger-full-access` is not offered as a fix.',

package/lib/types/advice.d.ts

@@ -58,12 +58,21 @@
  *   is guess which producer this is: the code alone cannot say, and the two
  *   checks it hands over are facts the reader holds (what program they ran;
  *   whether this is the packaged desktop app, which the plugin reports rather
- *   than assumes). That Electron host is itself **two measurements**, not one —
- *   a runner that never started at all, and a runner that did start and whose
- *   child cannot survive the restricted token derived from an Electron process
- *   image — and the advisory names both instead of asserting the one it shipped
- *   first, because a session cannot tell them apart and a confidently wrong
- *   cause is worse than two named ones with one shared remedy.
+ *   than assumes). That Electron host was shipped as **two measurements**; since
+ *   0.8.0 it is **one mechanism, named**: the runner must own a *console* for the
+ *   confined child to inherit, and when it owns none the child's own console
+ *   request is denied under the restricted token (`#8208` traced it to
+ *   `conhost.exe` created by the restricted child, exiting `STATUS_ACCESS_DENIED`).
+ *   The two measured console-less shapes are a GUI-subsystem host image (the
+ *   packaged desktop) and a `DETACHED_PROCESS` runner under a real `node.exe`
+ *   host — the second reproducible on any machine, which is what makes it the
+ *   check worth handing over. The shape 0.7.x led with, "the runner never started
+ *   at all", is **withdrawn**: the desktop's own host child is started with
+ *   `ELECTRON_RUN_AS_NODE=1` (`apps/desktop/src/host-process.ts` ->
+ *   `desktopNodeEnvironment()`), so nothing on the runner path fails to start for
+ *   want of that variable. A withdrawn cause earns its sentence because this
+ *   advisory shipped it twice; a confidently wrong cause is worse than two named
+ *   ones with one shared remedy.
  *
  * Both give a **discriminator, not just a remedy**: applying a fix without
  * confirming the cause teaches nothing when the fix does not work. For the ACL
@@ -84,11 +93,11 @@
 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";
+export declare const ACL_DISCUSSIONS = "#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816 / #8232";
 /** 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";
+export declare const NATIVE_INIT_DISCUSSIONS = "#7876 / #7877 / #8193 / #8208";
 /** 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: nine reports (#7538, #7622, #7646, #7720, #7750, #7735, #7771, #7804, #7816) 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 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; 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.7.1",
+  "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: ten reports (#7538, #7622, #7646, #7720, #7750, #7735, #7771, #7804, #7816, #8232) 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 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.8.1",
   "type": "module",
   "main": "lib/index.js",
   "types": "lib/types/index.d.ts",