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

package/README.md

@@ -46,8 +46,9 @@ inherited `Authenticated Users: Modify` is the whole of their access). In each o
 every sandboxed command fails the same way, before it runs, and the error names
 neither the missing right nor a remedy.
 
-Two further reports — [discussion #8312] and [discussion #8314] — describe the
-other end of the same backend: what its grant leaves behind *after* it applies.
+Two further reports — [discussion #8312] and [discussion #8314] — and a third,
+[discussion #8412], describe the other end of the same backend: what its grant
+leaves behind *after* it applies.
 The advisory states that too (see [What the grant leaves behind](#what-the-grant-leaves-behind-added-in-0100)),
 because the advisory is the thing handing over the command that applies the grant.
 
@@ -183,6 +184,25 @@ Two consequences follow from that one line:
    one of two independent layers. The advisory says this instead of a bare "no",
    because a reader told only "no" reaches for the workaround without knowing what
    else it has to change.
+7. **The missing right was confirmed from outside, unelevated** (added in 0.14.0,
+   from `#8426`). Everything above is argued from the backend's source; `#8426`
+   measured it with none of that. On a directory whose ACL named the account only
+   through the inherited `Authenticated Users:(M)` entry, asking that directory
+   for a Low mandatory-integrity label — the label half alone, no DACL write, so
+   it isolates the right the merged call wants — was **refused**, and the
+   identical operation **succeeded** the moment the same account granted itself
+   `(OI)(CI)F`, whose mask carries `WRITE_OWNER`, and was reversible from there
+   (back to Medium works just as well). No elevation anywhere in it. That makes the
+   claim in item 2 a measurement rather than a reading: the missing right is an
+   object right on the **directory**, not `SeRelabelPrivilege` and not a token
+   privilege. The same report then repaired two real trees the same way — object
+   right first, integrity label second, 9521 and 5592 objects, no failures — an
+   order that cannot be swapped, since the second step is the one that needs what
+   the first supplies, and it is the order the advisory's own remedy already
+   follows. The probe itself is quoted here and **not** in the advisory, for the
+   reason item 6 of the `#8272` paragraph above gives: a label write is not a
+   check, because where the caller already holds Full control it succeeds and
+   writes the label. The advisory hands over only the two read-only checks.
 
 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
@@ -653,7 +673,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; the two branches it forks into in 0.13.0)
+### 4. Denied inside the workspace (`workspace-denial`, added in 0.11.0; the branches it forks into in 0.13.0 and 0.14.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,7 +727,8 @@ 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 fork, and the second branch** (added in 0.13.0, from [#8383]). The
+- **The fork, and the other two branches** (the second added in 0.13.0 from
+  [#8383] and its second instance [#8421]; the third in 0.14.0 from [#8409]). 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
@@ -718,27 +739,50 @@ reading of its own sandbox, not a guess about a line of output.
   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.
+  DACL half, on the other half of the same call. From inside a session the
+  branches 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, **nothing below the root
+  writable at all** with the root itself the only writable place is the label
+  branch, and **the root itself refused** — nothing writable, not even the root —
+  is a third branch with a different cause and a different remedy (below). 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 DACL half from the label half (`diagnose-windows-sandbox-acl`,
+  0.2.0 and later, prints the owner, the caller's rights and
+  `WRITE_DAC`/`WRITE_OWNER` for the one and `LOW_LABEL` — `S-1-16-4096` — for the
+  other). And a widened DACL does not clear the label half 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.
+- **The third branch, and the one recovery this family has** (added in 0.14.0,
+  from [#8409]). The root's own standing grant can be **gone**: the workspace
+  root's security descriptor rewritten from outside the harness (an ACL reset, a
+  restored descriptor, a tool that re-applies one) leaves nothing writable, the
+  root included. It is not a descendant missing an inherited ACE — it is the ACE
+  the harness itself wrote that is no longer there — and the reason no retry
+  reaches it is one layer **above** the backend's own check: the session-scoped
+  provider materializes the root ACE once per **provider lifetime** and keeps the
+  root in its own in-memory map, consulting the map instead of the DACL
+  thereafter (`sandbox-local/src/index.ts`: the guard at `:403-421`,
+  "materializes once per workspace per server lifetime"), so the `hasExactGrant`
+  check the other two branches turn on is not even reached again. The
+  discriminator is measured on both paths and is a fact about where the cache
+  lives, not about one path being more careful: the agentless/runner invocation
+  passes no session id (`windowsAclRunnerArgv()`), so the runner owns the DACLs
+  and re-applies the grant on **every** spawn — which really does read the DACL —
+  and heals by itself, while the desktop session does not. The recovery is the
+  only one this family has and it is the **user's**, not a command: restart the
+  provider (quit and reopen the desktop app, or open the workspace in a fresh
+  one), which empties the map and lets the next provision read the DACL, find the
+  ACE absent and write it — the reporter measured exactly that ("restarting the
+  desktop brings it back").
 - **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
@@ -1069,6 +1113,7 @@ the current runtime cannot distinguish rather than counting it as a pass.
 [discussion #8232]: https://github.com/deepseek-ai/deepseek-harness/discussions/8232
 [discussion #8272]: https://github.com/deepseek-ai/deepseek-harness/discussions/8272
 [discussion #8275]: https://github.com/deepseek-ai/deepseek-harness/discussions/8275
+[discussion #8412]: https://github.com/deepseek-ai/deepseek-harness/discussions/8412
 [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
@@ -1098,3 +1143,7 @@ the current runtime cannot distinguish rather than counting it as a pass.
 [#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
+[#8409]: https://github.com/deepseek-ai/deepseek-harness/discussions/8409
+[#8412]: https://github.com/deepseek-ai/deepseek-harness/discussions/8412
+[#8421]: https://github.com/deepseek-ai/deepseek-harness/discussions/8421
+[#8426]: https://github.com/deepseek-ai/deepseek-harness/discussions/8426

package/cordis.patch.yml

@@ -38,6 +38,16 @@
 #     `diagnose-windows-sandbox-acl` repair arrives with the `0.2.0` line. Neither
 #     makes downgrading a fix, and repairing the `0.1.7` file list is not a thing
 #     that can be done — there is nothing in that release to list.
+#   - the missing right confirmed from outside (#8426): asking a directory that
+#     names the account only through the inherited `Authenticated Users:(M)`
+#     entry for a Low mandatory-integrity label is refused unelevated — the label
+#     half alone isolates the right the merged call wants — and the identical
+#     operation succeeds the moment that account grants itself `(OI)(CI)F`, so the
+#     missing right is a right on the directory, not `SeRelabelPrivilege` and not
+#     elevation. The same report repaired two trees object-right-first and
+#     label-second (9521 and 5592 objects, no failures), the order the advisory's
+#     own remedy already follows. The probe is not offered as a check: a label
+#     write is not a read.
 #
 # The advisory also says why a "weaker grant" is not a smaller version of the
 # same one, because that is the next idea the diagnosis invites: the label rides
@@ -45,8 +55,8 @@
 # the confined token is itself lowered to Low, so the directory's Low label is
 # what lets that child write there at all.
 #
-# And it says WHAT THE GRANT LEAVES BEHIND once it applies (#8312, #8314): the
-# three entries are STANDING and nothing revokes them (the backend's own dispose
+# And it says WHAT THE GRANT LEAVES BEHIND once it applies (#8312, #8314, #8412):
+# the three entries are STANDING and nothing revokes them (the backend's own dispose
 # and fail-closed paths leave them — "the intended end state (the reuse cache)"),
 # the Low integrity label is INHERITABLE and lives in the SACL (so `icacls /reset`
 # does not remove it — that rebuilds the DACL), a process starts at
@@ -136,13 +146,13 @@
 # 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, #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
+# A FOURTH family is the other half of the FIRST one's backend (#423, #8383,
+# #8421, #8409). 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
@@ -170,15 +180,28 @@
 #     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.
+#     place → the LABEL branch (#8383, second instance #8421; 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;
+#   - THE ROOT ITSELF REFUSED, nothing writable, not even the root → a third
+#     shape, and the only branch of this family with a recovery inside the product
+#     (#8409). The standing grant is gone from the root's own DACL — rewritten
+#     from outside the harness — and the layer that would put it back has stopped
+#     looking: the session-scoped provider materializes the root ACE once per
+#     provider lifetime and consults its own in-memory map afterwards without
+#     ever re-reading the DACL, while the agentless/runner path passes no session
+#     id, owns the DACLs itself and re-applies the grant on every spawn — which
+#     is why that path heals and this one does not. No command reaches it; the
+#     move is the user's and it is the provider, not the ACL: restart the desktop
+#     app or open the workspace in a fresh one, which empties the map and lets the
+#     next provision re-read the DACL and rewrite the missing ACE.
 #
 # 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),

package/lib/advice.js

@@ -173,12 +173,19 @@ import { failureLine, STATUS_DLL_INIT_FAILED } from './signature.js';
  * The upstream threads the ACL advisory is a stopgap for.
  *
  * The first twelve report the provisioning failure itself (the merged DACL +
- * label write being refused). The last two, `#8312` and `#8314`, report the
- * other end of the same backend — what its grant leaves behind once it
- * *succeeds* — which the advisory states because it is the fact a reader needs
- * at the moment it hands them the command that applies that grant.
+ * label write being refused). `#8312` and `#8314` report the other end of the
+ * same backend — what its grant leaves behind once it *succeeds* — which the
+ * advisory states because it is the fact a reader needs at the moment it hands
+ * them the command that applies that grant. The last three arrived later and
+ * are all inside the same advisory: `#8426` is the independent, unelevated
+ * measurement of the missing `WRITE_OWNER` the diagnosis above had only ever
+ * argued for, and `#8412` is a second instance of what the grant leaves behind
+ * (the standing Low label reaching programs the user launches themselves).
+ * `#8409` is the same backend once more and belongs to both lists: one of its
+ * three defects is the provisioning failure this family explains, and another
+ * is the fourth family's third branch.
  */
-export const ACL_DISCUSSIONS = '#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816 / #8232 / #8272 / #8275 / #8312 / #8314';
+export const ACL_DISCUSSIONS = '#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816 / #8232 / #8272 / #8275 / #8312 / #8314 / #8426 / #8412 / #8409';
 /**
  * The upstream threads the persistent-shell advisory is a stopgap for.
  *
@@ -207,9 +214,13 @@ export const NATIVE_INIT_DISCUSSIONS = '#7876 / #7877 / #8193 / #8208 / #8313 /
  * `#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.
+ * second branch the discriminator forks into; `#8421` met it again, which is
+ * why the branch reads as a shape rather than as one install. `#8409` is the
+ * third branch's source and a report of the DACL half as well: the workspace
+ * root's own standing grant can be gone, and the layer that would re-apply it
+ * consults a per-lifetime map instead of the DACL, so nothing notices.
  */
-export const WORKSPACE_DENIAL_DISCUSSIONS = '#423 / #8383';
+export const WORKSPACE_DENIAL_DISCUSSIONS = '#423 / #8383 / #8421 / #8409';
 /**
  * The thread list each family's withholding note cites.
  *
@@ -422,6 +433,61 @@ function degradedGrant() {
         'This is not offered here as a fix, and neither is `danger-full-access`.',
     ];
 }
+/**
+ * The independent measurement of the missing right, from `#8426`.
+ *
+ * Everything above is argued from the backend's own source — the merged
+ * security-information flags, the owner's implicit rights, the mask an inherited
+ * `Authenticated Users` entry carries. A reader is entitled to a measurement
+ * taken by someone who had none of that, and `#8426` is one: on a directory
+ * whose ACL named the account only through that inherited Modify entry, asking
+ * the directory for a Low mandatory-integrity label — the label half alone, no
+ * DACL write, so it isolates the right the merged call wants — was refused, and
+ * the same operation succeeded the moment that account granted itself
+ * `(OI)(CI)F`, whose mask carries `WRITE_OWNER`. Unelevated throughout, and
+ * reversible afterwards (the level moved back to Medium just as easily). That is
+ * the missing right demonstrated from outside this project's reading, and it is
+ * a right on the **directory**: no `SeRelabelPrivilege`, no token privilege, no
+ * elevation.
+ *
+ * The command itself is deliberately **not** printed here, and that is a
+ * decision rather than an omission — the same one the `#8272` paragraph of the
+ * README records. A label write is not a check: where the caller holds Full
+ * control it SUCCEEDS, and then the label and its inheritance are already
+ * written. This module hands over only operations that are safe to run when they
+ * succeed, which is why the two checks above are reads. The evidence is what the
+ * report measured; the probe stays in the report.
+ *
+ * The same report then repaired two real trees the same way — object right
+ * first, integrity label second, 9521 and 5592 objects, no failures. The order
+ * is not interchangeable and is worth stating: the second step is the one that
+ * needs what the first supplies. Both halves are already in the advisory's own
+ * remedy, in the same order.
+ *
+ * The contrast with the workspace-denial family is deliberate. There the
+ * recursive grant cannot be hand-written at all, because the SID it must name
+ * has no name to map (`ERROR_NONE_MAPPED`, 1332), which is why that advisory
+ * forks on breadth instead of handing over a line.
+ * @returns the section's lines.
+ */
+function writeOwnerEvidence() {
+    return [
+        'A second confirmation, measured by a reporter who had none of the reasoning above (#8426) — unelevated, on a',
+        'directory whose ACL named the account only through the inherited `Authenticated Users:(M)` entry: asking that',
+        'directory for a Low mandatory-integrity label — the LABEL half on its own, with no DACL write, so it isolates',
+        'the one right this call wants — was refused, and the identical operation stopped being refused the moment the',
+        'same account granted itself `(OI)(CI)F`, whose mask carries WRITE_OWNER: same account, same elevation,',
+        'succeeding at once, and reversible from there (the level moves back to Medium just as easily).',
+        'So the missing right is a right on this DIRECTORY, exactly as the diagnosis above reads it: no',
+        'SeRelabelPrivilege, no token privilege, no elevation anywhere in that measurement. (That probe is not printed',
+        'here and is not offered as a check: a label write is not a read — where the caller already holds Full control',
+        'it succeeds, and then the label and its inheritance are written. This module hands over only the two reads',
+        'above.) The same report repaired two real trees that way — object right first, integrity label second, 9521',
+        'and 5592 objects, no failures — an order that cannot be swapped, since the second step is the one that needs',
+        'what the first supplies; which is why the remedy below grants first and lets the backend write the label.',
+        '',
+    ];
+}
 /**
  * What the grant leaves behind once it applies, and how far its label travels.
  *
@@ -547,6 +613,7 @@ function aclAdvisory(failure, href) {
         '(WO) / Write owner. If the strongest entry naming you is (M) / Modify — or no entry names you at all and',
         'your access comes from an inherited `Authenticated Users:(M)` — that is this failure.',
         '',
+        ...(failure.klass === 'apply-denied' ? writeOwnerEvidence() : []),
         'Ownership decides which of the two commands below can work, so read it first — PowerShell 5.1 or later:',
         `  (Get-Acl "${path}").Owner      # compare with: whoami`,
         'If that is not your own account, take the second branch: the first one is refused before it runs.',
@@ -866,6 +933,11 @@ function workspaceDenialAdvisory(failure, tool, href) {
         '  therefore never revisited — not later in this session, not in any later one — so the identical command keeps',
         '  failing and there is no number of attempts that changes that',
         '  (`packages/sandbox/sandbox-windows-acl/src/acl.ts`).',
+        '  There is a second, higher skip, and it is the one the third branch below turns on: on a session-scoped',
+        '  workspace the layer that ASKS for the grant keeps its own per-lifetime map of the roots it has already',
+        '  provisioned and consults that map instead of the DACL, so for those roots the check above is not even reached',
+        '  again (`packages/sandbox/sandbox-local/src/index.ts`: the map guard at :403-421, "materializes once per',
+        '  workspace per server lifetime").',
         '  WHICH objects miss it is a fact about who created them: objects the harness itself creates inherit the ACE,',
         '  while objects that already existed or that another account or tool created (an installer, an editor, another',
         '  agent harness running under its own account) are the ones the propagation skipped. #423 measured 170 of 729',
@@ -875,7 +947,7 @@ function workspaceDenialAdvisory(failure, tool, href) {
         '  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 — and settle FIRST which of the two halves is missing, because both produce this same denial and a',
+        'Confirm it — and settle FIRST which of the three is missing, because all three produce this same denial and a',
         'reader who repairs the wrong one has learned nothing:',
         `  icacls "${subject}"`,
         `  icacls "${failure.workspaceRoot}"`,
@@ -886,6 +958,11 @@ function workspaceDenialAdvisory(failure, tool, href) {
         '    (#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.',
+        '  - THE ROOT ITSELF IS REFUSED — nothing writes, the root included, and work that used to succeed here now',
+        '    does not → NEITHER half above (#8409). The standing grant is gone from the root\'s own DACL, and the layer',
+        '    that would put it back has stopped looking. Two things about this branch are different in kind from the',
+        '    other two: no command reaches it, and it is the one branch of this family with a recovery inside the',
+        '    product — both are in half three below.',
         '',
         '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',
@@ -917,7 +994,9 @@ function workspaceDenialAdvisory(failure, tool, href) {
         '  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).',
+        '  label read at :198-204). A second report met this same half afterwards (#8421): the label written on the root',
+        '  alone, the pre-existing subdirectories carrying none of it. That is why this branch is stated as a shape this',
+        '  backend produces rather than as one machine\'s result.',
         '  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',
@@ -926,6 +1005,33 @@ function workspaceDenialAdvisory(failure, tool, href) {
         '  `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.',
         '',
+        'Half three — the standing grant is gone from the ROOT itself (#8409, reported 2026-09-30):',
+        '  Reported as a control beside two other defects on the same install (Windows 11, NTFS) rather than as a',
+        '  theory: after the workspace root\'s own security descriptor is rewritten from OUTSIDE the harness — an ACL',
+        '  reset, a restored descriptor, a tool that re-applies one — every write inside the workspace is refused, the',
+        '  root\'s own directory included. What is missing is the ACE the harness itself wrote, not a descendant\'s',
+        '  inheritance of it:',
+        '    icacls "<root>"        → no ACE for the workspace capability SID in its own DACL',
+        '  The discriminator is what the SAME machine does on the other path, and the reporter measured both: the',
+        '  agentless/runner invocation recovered by itself with no restart, while the desktop session did not. That',
+        '  asymmetry is not one path being more careful — it is where the cache lives. The session-scoped provider',
+        '  materializes the root ACE ONCE PER PROVIDER LIFETIME and keeps that root in its own in-memory map; every later',
+        '  call consults the map and never reads the DACL again, so the exact-ACE check the two halves above turn on is',
+        '  not even reached (`packages/sandbox/sandbox-local/src/index.ts`: the guard at :403-421, "materializes once per',
+        '  workspace per server lifetime" at :359, and the standing edits it skips are called the "cross-session reuse',
+        '  cache" in `packages/sandbox/sandbox-windows-acl/src/grant.ts:22-31`). The runner path used by agentless',
+        '  sessions passes no session id (`windowsAclRunnerArgv()`, :365-380), so the runner owns the DACLs there and',
+        '  re-applies the grant on every spawn — which really does read the DACL, and that is why that path heals and',
+        '  this one does not.',
+        '  RECOVERY: this is the only branch of this family a user can leave behind, and the move is the PROVIDER rather',
+        '  than a command. RESTART IT — quit and reopen the desktop app, or open the workspace in a fresh one. That',
+        '  empties the map, so the next provision reads the DACL, finds the ACE absent and writes it again; the reporter',
+        '  measured exactly that ("restarting the desktop brings it back"). Nothing reachable from inside this session',
+        '  gets there: the map is what is being consulted, and no command you can run here changes what it holds. Do not',
+        '  reach for either repair above either — both are about propagating a grant to DESCENDANTS, and this branch has',
+        '  lost the grant the propagation starts from.',
+        '  TEST: is the workspace ROOT itself denied — no capability ACE in its own DACL? Yes → this branch.',
+        '',
         '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',
@@ -934,6 +1040,9 @@ function workspaceDenialAdvisory(failure, tool, href) {
         '  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.',
+        '  The third branch is not closed by this ceiling and does not need to be: there is nothing to write by hand',
+        '  there — the grant that went missing is the harness\'s own, and all that has to happen is for the layer holding',
+        '  the map to look at the DACL again, which the restart in half three is what makes it do.',
         '',
         'What helps:',
         '  - The move that is yours, and the only one available inside the session: write new files under a directory the',
@@ -947,6 +1056,7 @@ function workspaceDenialAdvisory(failure, tool, href) {
         '    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.',
+        '    For the third branch there is no object to repair at all: the move is the restart named in half three.',
         '  - 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.',
@@ -959,7 +1069,8 @@ function workspaceDenialAdvisory(failure, tool, href) {
         '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 — on the grant AND on the',
-        'label — so the object that missed the propagation is never revisited.',
+        'label — so the object that missed the propagation is never revisited; and in the third branch the layer still',
+        'being consulted is the provider\'s own map, which nothing inside this session can change.',
         '',
         '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

@@ -174,12 +174,19 @@ import type { SandboxModeName } from './mode.js';
  * The upstream threads the ACL advisory is a stopgap for.
  *
  * The first twelve report the provisioning failure itself (the merged DACL +
- * label write being refused). The last two, `#8312` and `#8314`, report the
- * other end of the same backend — what its grant leaves behind once it
- * *succeeds* — which the advisory states because it is the fact a reader needs
- * at the moment it hands them the command that applies that grant.
+ * label write being refused). `#8312` and `#8314` report the other end of the
+ * same backend — what its grant leaves behind once it *succeeds* — which the
+ * advisory states because it is the fact a reader needs at the moment it hands
+ * them the command that applies that grant. The last three arrived later and
+ * are all inside the same advisory: `#8426` is the independent, unelevated
+ * measurement of the missing `WRITE_OWNER` the diagnosis above had only ever
+ * argued for, and `#8412` is a second instance of what the grant leaves behind
+ * (the standing Low label reaching programs the user launches themselves).
+ * `#8409` is the same backend once more and belongs to both lists: one of its
+ * three defects is the provisioning failure this family explains, and another
+ * is the fourth family's third branch.
  */
-export declare const ACL_DISCUSSIONS = "#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816 / #8232 / #8272 / #8275 / #8312 / #8314";
+export declare const ACL_DISCUSSIONS = "#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816 / #8232 / #8272 / #8275 / #8312 / #8314 / #8426 / #8412 / #8409";
 /**
  * The upstream threads the persistent-shell advisory is a stopgap for.
  *
@@ -208,9 +215,13 @@ export declare const NATIVE_INIT_DISCUSSIONS = "#7876 / #7877 / #8193 / #8208 /
  * `#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.
+ * second branch the discriminator forks into; `#8421` met it again, which is
+ * why the branch reads as a shape rather than as one install. `#8409` is the
+ * third branch's source and a report of the DACL half as well: the workspace
+ * root's own standing grant can be gone, and the layer that would re-apply it
+ * consults a per-lifetime map instead of the DACL, so nothing notices.
  */
-export declare const WORKSPACE_DENIAL_DISCUSSIONS = "#423 / #8383";
+export declare const WORKSPACE_DENIAL_DISCUSSIONS = "#423 / #8383 / #8421 / #8409";
 /**
  * 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 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",
+  "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) and a third (#8412) 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 that independent measurement of the missing right (#8426): `icacls <dir> /setintegritylevel \"(OI)(CI)Low\"` is refused unelevated, and the identical command succeeds the moment that account grants itself `(OI)(CI)F` (whose mask carries WRITE_OWNER), which is the right demonstrated from outside this project's reading and shown to be a right on the directory rather than SeRelabelPrivilege or elevation — the same report repairing two trees object-right-first and label-second (9521 and 5592 objects, no failures), the order the advisory's own remedy already follows — 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, #8383, #8421, #8409): 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, second instance #8421, measured on 0.2.0-rc.2 with the decisive control of a directory created after the grant) — and names the third: the workspace ROOT itself refused, the standing grant gone from its own DACL and the provider's per-lifetime map the only layer still consulted, which never re-reads the DACL while the agentless runner path (no session id) re-applies the grant on every spawn and therefore heals (#8409) — and forks the three on BREADTH before any check, because from inside a session the first two are indistinguishable and a reader who repairs the wrong half has learned nothing; it gives each branch its own TEST, states that the propagation halves 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) and that the third is the one branch with a recovery inside the product — a user restart of the provider, which empties the map and lets the next provision rewrite the missing ACE — separates the first two 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 — and the third branch needs no hand-written ACE at all) — 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.14.0",
   "type": "module",
   "main": "lib/index.js",
   "types": "lib/types/index.d.ts",