@argszero/cordis-plugin-sandbox-grant-advisor 0.12.0 → 0.13.0

package/README.md

@@ -653,7 +653,7 @@ the single shape that happened to be measured first. It never
 offers `danger-full-access` as a fix and never suggests a sandbox setting be
 relaxed.
 
-### 4. Denied inside the workspace (`workspace-denial`, added in 0.11.0)
+### 4. Denied inside the workspace (`workspace-denial`, added in 0.11.0; the two branches it forks into in 0.13.0)
 
 [#423] is one report and its own follow-up, and it is the **other end of the
 backend §1 is about**. There the workspace grant could not be applied at all and
@@ -707,14 +707,38 @@ reading of its own sandbox, not a guess about a line of output.
   `Administrators`/`SYSTEM` plus the capability SID is refused on the read side
   too, and looks fine to a check that merely greps for the capability SID.
   [#423] measured exactly that on a `.cache` directory.
-- **The second measured variant of the same shape.** The coverage that is
-  missing can be the mandatory-integrity **label** rather than a DACL entry —
-  reported in the same thread on 2026-09-29, against a `0.2.0-rc.1` install,
-  under the same root-only short-circuit. From inside a session the two are
-  indistinguishable; from outside, the repository's own diagnosis skill
-  separates them (`diagnose-windows-sandbox-acl`, 0.2.0 and later, reports
-  `hasExactDeny()` for the DACL half and `LOW_LABEL` — `S-1-16-4096` — for the
-  label half).
+- **The fork, and the second branch** (added in 0.13.0, from [#8383]). The
+  grant and the mandatory-integrity **label** go out in the same single
+  security-descriptor write, and that write lands on the workspace root (plus
+  the session's private temp directory) with **no descendant walk** — so the
+  label half can fail to reach the tree while the DACL half arrives at every
+  level, and it produces the identical denial. The backend's root-only
+  idempotency check then requires the grant, the world delete-child deny **and**
+  the exact label (`hasExactGrant()` + `hasExactDeny()` + `hasExactLabel()` all
+  matching, `acl.ts:386-388`, label read at `:198-204`) before it returns early,
+  so once the root is labelled the propagation is never attempted again and an
+  unlabelled child is never revisited — the same root-only short-circuit as the
+  DACL half, on the other half of the same call. From inside a session the two
+  are indistinguishable, so the advisory forks them on **breadth**, the one fact
+  the reader already owns: a **handful** of stubborn objects while the rest of
+  the tree writes normally is the DACL branch, and **nothing below the root
+  writable at all**, with the root itself the only writable place, is the label
+  branch. A Low-integrity child may write to a directory only if that
+  directory's own label is Low — the kernel's no-write-up check runs *in
+  addition to* the access check — so a DACL that is perfect everywhere changes
+  nothing. [#8383] measured it on `0.2.0-rc.2` with the decisive control of a
+  directory created **after** the grant: it inherits the capability ACE marked
+  `(I)` and still gets no label. (The report's own care is worth keeping: a
+  *grandchild* directory having no label proves nothing, because inheritance is
+  per-parent and the intermediate directory carries none — only a **direct**
+  child of the labelled root is evidence.) From outside a session the
+  repository's own diagnosis skill separates the halves
+  (`diagnose-windows-sandbox-acl`, 0.2.0 and later, prints the owner, the
+  caller's rights and `WRITE_DAC`/`WRITE_OWNER` for the DACL half and `LOW_LABEL`
+  — `S-1-16-4096` — for this one). And a widened DACL does not clear it either,
+  because the refusal precedes the ACL: [#8383] confirmed that adding an
+  explicit `FullControl` entry for the user on a subdirectory still left the
+  write denied.
 - **No repair command.** The obvious one, a recursive `icacls /grant` for the
   capability SID, is refused by Windows itself with `ERROR_NONE_MAPPED` (1332) —
   the tool cannot map that SID to a name, so a grant that must name it never
@@ -1073,3 +1097,4 @@ the current runtime cannot distinguish rather than counting it as a pass.
 [#8322]: https://github.com/deepseek-ai/deepseek-harness/discussions/8322
 [#8334]: https://github.com/deepseek-ai/deepseek-harness/discussions/8334
 [#8336]: https://github.com/deepseek-ai/deepseek-harness/discussions/8336
+[#8383]: https://github.com/deepseek-ai/deepseek-harness/discussions/8383

package/cordis.patch.yml

@@ -136,18 +136,19 @@
 # with why a windowless console is still an inheritable console. Like the second
 # family, it is mode-gated.
 #
-# A FOURTH family is the other half of the FIRST one's backend (#423). There the
-# grant could not be applied at all; here it WAS applied — on the workspace root,
-# once — and Windows ACE inheritance silently skipped the objects whose DACL the
-# caller could not write, so commands writing into a subdirectory created or moved
-# in from outside (an installer, an editor, another harness under its own account)
-# are denied forever while the same command against a directory the harness itself
-# created succeeds. The backend's provisioning check short-circuits on the root
-# (`hasExactGrant` returns early once the root carries the ACE), so those
-# descendants are never revisited. It is read from a value rather than from text,
-# like the third family and for the same reason (a denial exits nonzero and the
-# shipped shell tools report that as a finished run), but it needs no bespoke code:
-# the executors stamp the denial onto the value as
+# A FOURTH family is the other half of the FIRST one's backend (#423, #8383).
+# There the grant could not be applied at all; here it WAS applied — on the
+# workspace root, once — and Windows ACE inheritance silently skipped the objects
+# whose DACL the caller could not write, so commands writing into a subdirectory
+# created or moved in from outside (an installer, an editor, another harness
+# under its own account) are denied forever while the same command against a
+# directory the harness itself created succeeds. The backend's provisioning check
+# short-circuits on the root (the grant, the world delete-child deny and the
+# exact label must all match before it returns early), so those descendants are
+# never revisited. It is read from a value rather than from text, like the third
+# family and for the same reason (a denial exits nonzero and the shipped shell
+# tools report that as a finished run), but it needs no bespoke code: the
+# executors stamp the denial onto the value as
 #
 #   sandbox: { mode: "workspace-write", denied: true }
 #
@@ -157,16 +158,32 @@
 # absolute path the command names lies inside the session's workspace: a denial
 # anywhere else (outside the workspace, under `read-only`, a runner failure) is
 # the sandbox working as designed and is left alone. The advisory prints the path
-# it keyed on beside the root it tested it against, says that retrying is provably
-# useless, gives the DISCRIMINATOR — reading/listing use the normal token while
-# writing/deleting use the restricted one, and both sides must pass, so an object
-# whose DACL names only Administrators/SYSTEM plus the capability SID looks granted
-# to a check that just greps for the SID — names the second measured variant of
-# the same shape (the coverage missing on the mandatory-integrity LABEL rather
-# than on the DACL, separated from outside a session by the repository's own
-# `diagnose-windows-sandbox-acl`), and states the Windows ceiling that closes the
-# obvious repair (a recursive `icacls /grant` for a capability SID is refused with
-# ERROR_NONE_MAPPED (1332), because that SID has no name to map). It ships NO
+# it keyed on beside the root it tested it against and says that retrying is
+# provably useless — and then, before any check, forks the diagnosis on BREADTH,
+# the one fact the reader already owns:
+#
+#   - a HANDFUL of stubborn objects while the rest of the tree writes normally →
+#     the DACL branch (#423: the capability ACE did not arrive at those objects),
+#     with the two-sided discriminator that a single check gets wrong — reading
+#     and listing use the normal token while writing and deleting use the
+#     restricted one, so an object whose DACL names only Administrators/SYSTEM
+#     plus the capability SID looks granted to a check that merely greps for the
+#     SID;
+#   - NOTHING below the root writable at all, the root itself the only writable
+#     place → the LABEL branch (#8383, measured on 0.2.0-rc.2 with the decisive
+#     control of a directory created after the grant): the DACL is present and
+#     inherits correctly at every level while the Low mandatory-integrity label
+#     never reaches the children, so the kernel's no-write-up check refuses the
+#     Low-integrity child before the ACL is ever consulted — same permanent shape
+#     (the label goes out in the same single security-descriptor write as the
+#     grant, only on the paths the backend enumerates, with no descendant walk),
+#     separable from outside a session by the repository's own
+#     `diagnose-windows-sandbox-acl` and its `LOW_LABEL` (`S-1-16-4096`) report.
+#
+# It also states the Windows ceiling that closes the obvious repair (a recursive
+# `icacls /grant` for a capability SID is refused with ERROR_NONE_MAPPED (1332),
+# because that SID has no name to map; and a manually widened DACL does not clear
+# the label half either, because the refusal precedes the ACL). It ships NO
 # repair command, for the reason the standing-grant section ships none: this
 # project has no Windows host to verify a line on.
 

package/lib/advice.js

@@ -132,11 +132,16 @@
  *   normal token while writing and deleting use the restricted one, so an object
  *   whose DACL names only `Administrators`/`SYSTEM` plus the capability SID is
  *   refused on the read side too and looks granted to a grep for the SID
- *   (#423 measured it). The variant that would otherwise be missed gets its own
- *   sentence as well — the same shape with the missing coverage on the mandatory
- *   label instead of the DACL (reported 2026-09-29 in the same thread), which is
- *   indistinguishable from inside a session and separable by the repository's own
- *   diagnosis skill.
+ *   (#423 measured it). And the second branch is now **first-class rather than a
+ *   sentence**: the same root-only short-circuit on the *label* half, where the
+ *   DACL reaches every object and the mandatory-integrity label reaches none of
+ *   the subdirectories, so nothing below the root is writable at all (`#8383`,
+ *   measured against `0.2.0-rc.2` with the decisive control of a directory
+ *   created *after* the grant). The two branches are indistinguishable from
+ *   inside a session and permanent for the same reason, so the text forks them
+ *   on **breadth** — the one fact the reader already owns — before it hands over
+ *   any check, and separates them from outside by the repository's own
+ *   `diagnose-windows-sandbox-acl` and its `LOW_LABEL` report.
  *
  * 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
@@ -156,7 +161,10 @@
  * against: the reader can audit the plugin's own reasoning instead of taking a
  * claim about two strings on faith. That family's check is also the one place
  * where a single fact is not enough — reachability has two sides, and the text
- * says which one a check on the ACE alone would miss.
+ * says which one a check on the ACE alone would miss — and it is the one family
+ * with a **second cut before the check**: which half is missing is settled by how
+ * MUCH of the tree is affected, because a reader who repairs the DACL of a
+ * label-starved workspace has spent a privilege for nothing.
  *
  * @module
  */
@@ -191,15 +199,17 @@ export const PTY_DISCUSSIONS = '#7638 / #8322';
  */
 export const NATIVE_INIT_DISCUSSIONS = '#7876 / #7877 / #8193 / #8208 / #8313 / #8336 / #8334';
 /**
- * The upstream thread the workspace-denial advisory is a stopgap for.
- *
- * One thread, because this family is one report and its own follow-up: `#423`
- * is the failure and its measurements (170 of 729 objects missing the grant,
- * root-level files among them, and the two-sided reachability rule), and the
- * second comment in that thread is the mandatory-label variant of the same
- * shape.
+ * The upstream threads the workspace-denial advisory is a stopgap for.
+ *
+ * `#423` is the failure and its first measurements: 170 of 729 objects missing
+ * the grant, root-level files among them, and the two-sided reachability rule.
+ * Its second comment named the mandatory-label variant of the same shape, which
+ * `#8383` then measured on its own — the exact complement, with the DACL
+ * present and inheriting correctly at every level while the label reaches none
+ * of the subdirectories, so the variant stopped being a footnote and became the
+ * second branch the discriminator forks into.
  */
-export const WORKSPACE_DENIAL_DISCUSSIONS = '#423';
+export const WORKSPACE_DENIAL_DISCUSSIONS = '#423 / #8383';
 /**
  * The thread list each family's withholding note cites.
  *
@@ -804,19 +814,25 @@ function ptyAdvisory(failure, mode, tool, href) {
  * against**, because the family's claim is a statement about two strings and the
  * reader is entitled to audit it. It must give the **two-sided** reachability
  * rule, since a check that only looks for the capability ACE reports an object
- * as granted when the read side is refused as well. And it must name the
- * **label variant** of the same shape, because from inside a session the two are
- * indistinguishable and a reader who repairs the wrong half has learned
- * nothing.
- *
- * What it must not do is print a repair command. The obvious one is refused by
- * Windows with `ERROR_NONE_MAPPED` (1332) — a capability SID has no name for
- * `icacls` to map — and the one that would work needs `WRITE_DAC` on the object,
- * which is the right in question. This project has no Windows host to verify a
- * line on, and the standing-grant section of the ACL advisory is held to the
- * same standard for the same reason: an unverified remedy delivered confidently
- * is the defect this plugin exists to answer. The mechanism is stated instead,
- * and the reader is told why the command is absent.
+ * as granted when the read side is refused as well. And it must split the
+ * diagnosis into its **two branches** — the DACL entry that did not arrive, and
+ * the mandatory-integrity LABEL that did not (#8383) — because from inside a
+ * session they are indistinguishable, both are permanent for the same
+ * root-only-short-circuit reason, and a reader who repairs the wrong half has
+ * learned nothing. The fork is placed on **breadth**, which is the one fact the
+ * reader already has: a handful of stubborn objects is the DACL branch, and
+ * nothing below the root writable at all is the label branch.
+ *
+ * What it must not do is print a repair command. For the DACL branch the obvious
+ * one is refused by Windows with `ERROR_NONE_MAPPED` (1332) — a capability SID
+ * has no name for `icacls` to map — and the one that would work needs
+ * `WRITE_DAC` on the object, which is the right in question. For the label
+ * branch the shape of the move is a SACL write on the whole subtree, which needs
+ * the same class of object right and is not verified here either. This project
+ * has no Windows host to verify a line on, and the standing-grant section of the
+ * ACL advisory is held to the same standard for the same reason: an unverified
+ * remedy delivered confidently is the defect this plugin exists to answer. The
+ * mechanism is stated instead, and the reader is told why the command is absent.
  * @param failure - the recognized failure.
  * @param tool - the tool whose call was denied, when the caller knows it.
  * @param href - optional URL shown for the upstream thread.
@@ -829,7 +845,8 @@ function workspaceDenialAdvisory(failure, tool, href) {
     const call = tool === undefined ? 'This command' : `The \`${tool}\` command`;
     const subject = failure.paths[0] ?? '<the path from the error line above>';
     return [
-        'Denied inside your own workspace — the workspace grant does not reach that part of the tree, and retrying cannot repair it.',
+        'Denied inside your own workspace — the access the workspace is supposed to carry does not cover that part of',
+        'the tree, and retrying cannot repair it.',
         '',
         'What was reported:',
         `  ${failureLine(failure)}`,
@@ -837,8 +854,8 @@ function workspaceDenialAdvisory(failure, tool, href) {
         'path it named is inside this session\'s workspace:',
         ...failure.paths.map(path => `  ${path}`),
         `  (workspace root: ${failure.workspaceRoot})`,
-        'So this is not the sandbox declining work that belongs outside the workspace. It is the workspace\'s own grant',
-        'failing to cover an object inside it, which is why every command touching that object fails the same way.',
+        'So this is not the sandbox declining work that belongs outside the workspace. It is the workspace\'s own access',
+        'setup failing to cover an object inside it, which is why every command touching that object fails the same way.',
         '',
         'Why — and why retrying cannot fix it:',
         '  The host-side grant is written ONCE, on the workspace ROOT, and relies on Windows ACE inheritance to reach',
@@ -854,36 +871,85 @@ function workspaceDenialAdvisory(failure, tool, href) {
         '  agent harness running under its own account) are the ones the propagation skipped. #423 measured 170 of 729',
         '  objects missing it, INCLUDING root-level files — so it is not only subdirectories, and "write it at the',
         '  workspace root instead" is not a safe move either.',
+        '  The same call also writes the mandatory-integrity LABEL, and that half can fail to reach the tree while the',
+        '  ACE half arrives — that is the second branch below, and it produces this identical denial. Both halves are',
+        '  permanent for the same reason, so settling WHICH one you are looking at comes before anything else.',
         '',
-        'Confirm it — this is the discriminator, and the second half is the part a single check gets wrong:',
+        'Confirm it — and settle FIRST which of the two halves is missing, because both produce this same denial and a',
+        'reader who repairs the wrong one has learned nothing:',
         `  icacls "${subject}"`,
-        'compared with the same command against the workspace root. The root carries an inheritable ACE for the workspace',
-        'capability SID — a `S-1-4-…` that `icacls` prints as an unresolved SID rather than a name — with Modify or Full',
-        'control; the failing object does not have it. Check each path listed above the same way; the first is shown here.',
+        `  icacls "${failure.workspaceRoot}"`,
+        'BREADTH IS THE FIRST CUT, and it needs no tool — it is what your own attempts have already shown:',
+        '  - A HANDFUL of stubborn objects while the rest of the tree writes normally → the DACL half. The capability ACE',
+        '    did not arrive at those objects; the workspace is otherwise usable. This is the #423 measurement.',
+        '  - NOTHING below the root is writable at all, with the root itself the only writable place → the LABEL half',
+        '    (#8383). A Low-integrity child may write to a directory only when that directory\'s own mandatory-integrity',
+        '    label is Low as well; the kernel runs its no-write-up check IN ADDITION to the access check, so a DACL that',
+        '    is perfect everywhere changes nothing.',
+        '',
+        'Half one — the DACL ACE did not reach the object:',
+        '  The root carries an inheritable ACE for the workspace capability SID — a `S-1-4-…` that `icacls` prints as an',
+        '  unresolved SID rather than a name — with Modify or Full control; the failing object does not have it. Check each',
+        '  path listed above the same way; the first is shown here.',
         '  THE TRAP: reading and listing go through the NORMAL token, writing and deleting through the RESTRICTED',
         '  (low-integrity) one, and both sides must pass. An object whose DACL names only Administrators/SYSTEM plus the',
         '  capability SID is refused on the read side as well, so it looks granted to a check that only searches for the',
         '  capability SID — #423 measured exactly that on a `.cache` directory. A check that asks only "is the SID there?"',
         '  reports those objects as fine while LIST and WRITE are both denied.',
-        '  A SECOND measured variant has the same shape and a different object: the coverage that is missing can be the',
-        '  mandatory-integrity LABEL rather than a DACL entry. It was reported in this same thread on 2026-09-29 against a',
-        '  `0.2.0-rc.1` install, under the same root-only short-circuit. Inside a session the two are indistinguishable;',
-        '  from outside, the repository\'s own diagnosis skill separates them — `diagnose-windows-sandbox-acl` (0.2.0 and',
-        '  later) reports `hasExactDeny()` for the DACL half and `LOW_LABEL` (`S-1-16-4096`) for the label half.',
+        '  TEST: does the object show the capability ACE at all, inherited or not? Absent → this half, and the object is',
+        '  the thing to repair.',
+        '',
+        'Half two — the DACL arrived and the LABEL did not (#8383, measured 2026-09-30):',
+        '  Measured on a `0.2.0-rc.2` install (Windows 11, 26200 family, NTFS): the workspace root writable, EVERY',
+        '  subdirectory denied, and — this is what makes it the label half — the capability ACE present and correctly',
+        '  inherited on every one of them. The label, meanwhile, exists on the root alone:',
+        '    icacls "<root>"        → Mandatory Label\\Low Mandatory Level:(OI)(CI)(NW)',
+        '    icacls "<subdir>"      → no Mandatory Label line at all',
+        '  The decisive form of that measurement is a directory created AFTER the grant was materialized: it inherits the',
+        '  capability ACE (marked `(I)`) and still receives no label. That is what rules out "these objects simply predate',
+        '  the grant" and isolates the failure to the label layer. One caveat the report itself is careful about and worth',
+        '  keeping: a GRANDCHILD directory having no label proves nothing on its own, because inheritance is per-parent and',
+        '  the intermediate directory carries none — only a DIRECT child of the labelled root is evidence.',
+        '  Why it is permanent: the label goes out in the same single security-descriptor write that carries the grant,',
+        '  with the inheritance flag set, but only on the paths the backend enumerates — the workspace root (plus the',
+        '  session\'s private temp directory), with no descendant walk. The root-only idempotency check then requires the',
+        '  grant, the world delete-child deny AND the exact label (`hasExactGrant()` + `hasExactDeny()` + `hasExactLabel()`',
+        '  all matching) before it returns early, so once the root is labelled the propagation is never attempted again and',
+        '  the children that missed it are never revisited — the same root-only short-circuit as the DACL half, on the',
+        '  other half of the same call (`packages/sandbox/sandbox-windows-acl/src/acl.ts`: the guard at :386-388, the',
+        '  label read at :198-204).',
+        '  The package README describes that label as inheritable and covering the tree, and its grant materialization as',
+        '  an eager full-tree propagation. Read it as a statement about the ACE that is written, not about what the',
+        '  children ended up carrying: the inheritance flag is declared on the root, the propagation to the children is',
+        '  what is missing. From outside a session the repository\'s own diagnosis skill separates the two halves —',
+        '  `diagnose-windows-sandbox-acl` (0.2.0 and later) prints the directory\'s owner, the caller\'s rights and',
+        '  `WRITE_DAC`/`WRITE_OWNER` — the facts the DACL half turns on — and `LOW_LABEL` (`S-1-16-4096`) for this one.',
+        '  TEST: does a subdirectory show the capability ACE WITHOUT a Mandatory Label line? Yes → this half.',
         '',
         'Why the natural repair is closed — this is a Windows ceiling, not a mistake in the command:',
         '  The grant the root carries is written for a capability SID, and a recursive `icacls /grant "*S-1-4-…:…" /T /C`',
         '  is refused with ERROR_NONE_MAPPED (1332): the tool cannot map that SID to a name, so a grant that needs to name',
         '  it never reaches the child. Widening the grant to a nameable account is a different grant with different',
-        '  consequences, not this one restored.',
+        '  consequences, not this one restored. For the label half the same ceiling applies one layer over: re-labelling a',
+        '  subtree is a SACL write, which needs the object right the merged call already needed, and a manually widened',
+        '  DACL does NOT clear the failure — #8383 confirmed that adding an explicit FullControl entry for the user on a',
+        '  subdirectory still left the write denied, because the refusal happens before the ACL is ever consulted.',
         '',
         'What helps:',
         '  - The move that is yours, and the only one available inside the session: write new files under a directory the',
         '    harness itself created in this workspace. Those carry the grant, because their inheritance did apply — the',
         '    reporter\'s own measurement, that objects DSH created are complete here and externally created ones are not.',
-        '  - The user\'s move: repair the specific object from an account that already holds WRITE_DAC on it, by writing',
-        '    the ACE the root carries into the child\'s own DACL. That needs the very right that is missing, so it is not',
-        '    something an unelevated prompt can do.',
+        '    Treat this as a workaround and not a repair, and on the LABEL half expect even this to be unreliable: the',
+        '    directories the harness creates in a fresh workspace are children of a root whose label did not propagate, so',
+        '    whether any given one works is a fact about the host you have in front of you rather than something this text',
+        '    can promise.',
+        '  - The user\'s move, per half: for the DACL half, repair the specific object from an account that already holds',
+        '    WRITE_DAC on it, by writing the ACE the root carries into the child\'s own DACL. For the label half, the',
+        '    corresponding move is on the integrity label rather than the DACL, and it has to cover the tree, not one',
+        '    object; it is the same class of object write, so it is not something an unelevated prompt can do either.',
+        '  - The route that costs no rights at all, and the honest recommendation while the halves remain unrepairable from',
+        '    inside: build and run where the confinement is not the thing under test — which is a decision about what you',
+        '    are doing, not a sandbox tier to reach for silently.',
         '  No repair command is printed here on purpose. This project has no Windows host to verify one on, and shipping',
         '  an unverified line would be the same defect this plugin exists to answer. The mechanism above is what is known;',
         '  the line is yours to choose.',
@@ -892,8 +958,8 @@ function workspaceDenialAdvisory(failure, tool, href) {
         'mode. That retry can only succeed by removing the confinement itself — it repairs nothing in the workspace, and',
         'the next session meets the same gap. Take it only if that is what you mean to buy.',
         '',
-        'Do NOT retry this call unchanged: the provisioning path short-circuits on the root grant, so the object that was',
-        'skipped is never revisited.',
+        'Do NOT retry this call unchanged: the provisioning path short-circuits on the root — on the grant AND on the',
+        'label — so the object that missed the propagation is never revisited.',
         '',
         'How to read this: the denial names no cause and points at no repair, so the diagnosis is delivered here instead.',
         'This is a stopgap, ' + where + '. This plugin speaks only when the mode is `workspace-write`, the host is',

package/lib/types/advice.d.ts

@@ -132,11 +132,16 @@
  *   normal token while writing and deleting use the restricted one, so an object
  *   whose DACL names only `Administrators`/`SYSTEM` plus the capability SID is
  *   refused on the read side too and looks granted to a grep for the SID
- *   (#423 measured it). The variant that would otherwise be missed gets its own
- *   sentence as well — the same shape with the missing coverage on the mandatory
- *   label instead of the DACL (reported 2026-09-29 in the same thread), which is
- *   indistinguishable from inside a session and separable by the repository's own
- *   diagnosis skill.
+ *   (#423 measured it). And the second branch is now **first-class rather than a
+ *   sentence**: the same root-only short-circuit on the *label* half, where the
+ *   DACL reaches every object and the mandatory-integrity label reaches none of
+ *   the subdirectories, so nothing below the root is writable at all (`#8383`,
+ *   measured against `0.2.0-rc.2` with the decisive control of a directory
+ *   created *after* the grant). The two branches are indistinguishable from
+ *   inside a session and permanent for the same reason, so the text forks them
+ *   on **breadth** — the one fact the reader already owns — before it hands over
+ *   any check, and separates them from outside by the repository's own
+ *   `diagnose-windows-sandbox-acl` and its `LOW_LABEL` report.
  *
  * 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
@@ -156,7 +161,10 @@
  * against: the reader can audit the plugin's own reasoning instead of taking a
  * claim about two strings on faith. That family's check is also the one place
  * where a single fact is not enough — reachability has two sides, and the text
- * says which one a check on the ACE alone would miss.
+ * says which one a check on the ACE alone would miss — and it is the one family
+ * with a **second cut before the check**: which half is missing is settled by how
+ * MUCH of the tree is affected, because a reader who repairs the DACL of a
+ * label-starved workspace has spent a privilege for nothing.
  *
  * @module
  */
@@ -192,15 +200,17 @@ export declare const PTY_DISCUSSIONS = "#7638 / #8322";
  */
 export declare const NATIVE_INIT_DISCUSSIONS = "#7876 / #7877 / #8193 / #8208 / #8313 / #8336 / #8334";
 /**
- * The upstream thread the workspace-denial advisory is a stopgap for.
+ * The upstream threads the workspace-denial advisory is a stopgap for.
  *
- * One thread, because this family is one report and its own follow-up: `#423`
- * is the failure and its measurements (170 of 729 objects missing the grant,
- * root-level files among them, and the two-sided reachability rule), and the
- * second comment in that thread is the mandatory-label variant of the same
- * shape.
+ * `#423` is the failure and its first measurements: 170 of 729 objects missing
+ * the grant, root-level files among them, and the two-sided reachability rule.
+ * Its second comment named the mandatory-label variant of the same shape, which
+ * `#8383` then measured on its own — the exact complement, with the DACL
+ * present and inheriting correctly at every level while the label reaches none
+ * of the subdirectories, so the variant stopped being a footnote and became the
+ * second branch the discriminator forks into.
  */
-export declare const WORKSPACE_DENIAL_DISCUSSIONS = "#423";
+export declare const WORKSPACE_DENIAL_DISCUSSIONS = "#423 / #8383";
 /**
  * The thread list each family's withholding note cites.
  *

package/package.json

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