@argszero/cordis-plugin-sandbox-grant-advisor 0.4.0 → 0.5.0

package/README.md

@@ -113,18 +113,56 @@ confines deletes to the workspace, and reverting it reintroduces the escape it c
 Confirm the cause (unelevated) — `icacls` is a normal user command:
   icacls "D:\ws"
 
-Fix it (unelevated, one line) and then run the command again:
+Ownership decides which of the two commands below can work, so read it first — PowerShell 5.1 or later:
+  (Get-Acl "D:\ws").Owner      # compare with: whoami
+
+IF YOU OWN THE DIRECTORY — the usual workspace, on a data volume as much as on C::
+  one unelevated line, then run the command again:
   PowerShell: icacls "D:\ws" /grant "$env:USERNAME:(OI)(CI)(WO)"
   cmd:        icacls "D:\ws" /grant "%USERNAME%:(OI)(CI)(WO)"
-
-What will NOT fix it — both look like the right move, and both were tried and reported:
+  ... Full control works just as well — the same line with `F` in place of `(WO)`
+
+IF YOU DO NOT OWN IT — a directory an installer or another account created, e.g. owner
+`BUILTIN\Administrators`:
+  the line above cannot run at all. Changing a DACL takes WRITE_DAC, which you hold neither as owner nor
+  through any ACE, so `icacls /grant` is refused with `Access is denied` — for the very command that would
+  fix it. ... Run the grant once from an account that already holds both — that is, from an ELEVATED prompt:
+  icacls "D:\ws" /grant "<your-account>:(OI)(CI)F"
+  ... or take ownership first (also elevated; it wants SeTakeOwnership), after which the unelevated `(WO)`
+  line above applies: icacls "D:\ws" /setowner "<your-account>"
+  ... or sidestep the ACL: create the workspace under `%USERPROFILE%`.
+
+What will NOT fix it on its own — both look like the right move, and both were tried and reported:
   takeown /F "D:\ws" /R /D Y
-    makes you the owner, but ownership's implicit rights are READ_CONTROL and WRITE_DAC only.
-    The owner does not implicitly hold WRITE_OWNER, which is the right this call needs.
+    makes you the owner, and ownership's implicit rights are READ_CONTROL and WRITE_DAC only — so it
+    supplies the DACL half and still not WRITE_OWNER, the right this call needs.
   icacls "D:\ws" /reset /T /C
     restores inheritance, and inheritance is what supplied the Modify-only ACE above.
 ```
 
+**Why the remedy forks** (added in 0.5.0). The same error covers two different
+rights situations, and one command cannot serve both. Where the caller **owns**
+the directory, the owner's implicit `WRITE_DAC` satisfies the DACL half of the
+merged write, `WRITE_OWNER` is the single missing right, and the unelevated
+`icacls /grant` that supplies it can itself run — [#7750] measured exactly that
+fix working. Where the caller **does not own** it ([#7771]: owner
+`BUILTIN\Administrators`, held deny-only for that token), `WRITE_DAC` is missing
+too, so the very same command is refused before it does anything, and `(WO)`
+alone would not be enough even if it went through. The failure text is identical
+in both, so the classifier cannot pick a branch — the advisory hands over the
+**ownership check** as the selector instead of guessing, which is also the
+actionable-guidance half of what [#7771] asked for. Until 0.5.0 a single
+unconditional one-liner was printed, with a sentence noting it assumed
+ownership; that would have sent the second environment to a command that is
+denied — the same defect this plugin exists to answer.
+
+**What is deliberately *not* shipped**: `icacls ... /grant "<user>:(OI)(CI)(WD,WO)"`,
+the two needed rights named explicitly. It is the tighter form and it is
+plausibly correct syntax, but this project has no Windows host to run it on, and
+shipping an unverified command in a remedy whose whole point is that it works is
+the failure mode being fixed. `F` (verified by [#7804]'s reporter) and
+`/setowner` (named by both reports) are given instead.
+
 ### 2. Persistent shell startup (`pty-startup`)
 
 [Discussion #7638] reports the second shape: with the **`minimal` preset** on
@@ -399,4 +437,10 @@ the current runtime cannot distinguish rather than counting it as a pass.
 [discussion #7720]: https://github.com/deepseek-ai/deepseek-harness/discussions/7720
 [discussion #7750]: https://github.com/deepseek-ai/deepseek-harness/discussions/7750
 [discussion #7735]: https://github.com/deepseek-ai/deepseek-harness/discussions/7735
+[discussion #7771]: https://github.com/deepseek-ai/deepseek-harness/discussions/7771
+[discussion #7804]: https://github.com/deepseek-ai/deepseek-harness/discussions/7804
+[discussion #7816]: https://github.com/deepseek-ai/deepseek-harness/discussions/7816
+[#7750]: https://github.com/deepseek-ai/deepseek-harness/discussions/7750
+[#7771]: https://github.com/deepseek-ai/deepseek-harness/discussions/7771
+[#7804]: https://github.com/deepseek-ai/deepseek-harness/discussions/7804
 [discussion #7638]: https://github.com/deepseek-ai/deepseek-harness/discussions/7638

package/lib/advice.js

@@ -20,6 +20,24 @@
  *   separates "this is the label failure" from "this is something else", and
  *   because rolling back is the reach it invites while making the very problem
  *   it closed come back.
+ *
+ *   **The remedy is forked on ownership, because one command cannot serve both
+ *   environments.** The reports split into two rights situations behind an
+ *   identical error: a workspace **the caller owns** (`#7622`, `#7646`, `#7720`,
+ *   `#7750`, `#7804`), where the owner's implicit `WRITE_DAC` satisfies the DACL
+ *   half and `(WO)` is the whole of what is missing — so the `icacls /grant`
+ *   that supplies it *can itself run*, unelevated; and a directory **the caller
+ *   does not own** (`#7771`: owner `BUILTIN\Administrators`, held deny-only for
+ *   their token), where `WRITE_DAC` is missing too, so `icacls /grant` is denied
+ *   for the very command that would fix it, and `(WO)` alone would not be enough
+ *   even if it went through. The classifier cannot tell these apart — the text is
+ *   identical — so the advisory does what it can do instead of guessing: it hands
+ *   over the **ownership check** (`(Get-Acl "<dir>").Owner`) as the branch
+ *   selector, then gives each branch the command that actually works there, and
+ *   says why the other branch's command is not a fallback. A single unconditional
+ *   one-liner would send the second environment to a command that is refused
+ *   before it runs — the same defect this module exists to answer, a remedy that
+ *   does not work delivered confidently.
  * - **The persistent-shell failure** (`pty-startup`) is *not* fixable by the
  *   caller — least of all by the model, which has no shell to run anything in.
  *   So its advice says so and stops: the remedy is a user-side preset choice,
@@ -40,7 +58,7 @@
  */
 import { failureLine } from './signature.js';
 /** The upstream threads the ACL advisory is a stopgap for. */
-export const ACL_DISCUSSIONS = '#7538 / #7622 / #7646 / #7720 / #7750 / #7735';
+export const ACL_DISCUSSIONS = '#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816';
 /** The upstream thread the persistent-shell advisory is a stopgap for. */
 export const PTY_DISCUSSIONS = '#7638';
 /** The documented prerequisite, quoted from the backend's README. */
@@ -111,7 +129,7 @@ function diagnosis(failure) {
             return [
                 'Why it is refused: this is the same merged write, but the Win32 code is not ERROR_ACCESS_DENIED (5), so',
                 'the missing-rights story above does not apply verbatim — a missing path, a non-directory target, or a',
-                'filesystem that does not carry ACLs are all possibilities. The one-line fix below is safe to try; if the',
+                'filesystem that does not carry ACLs are all possibilities. The commands below are safe to try; if the',
                 'code persists, it is a different failure and worth reporting with the code.',
             ].join('\n');
     }
@@ -129,7 +147,11 @@ function diagnosis(failure) {
  *   diagnosis.
  *
  * A negative claim still has to be earned: the failure to avoid is advice that
- * is confidently wrong in the other direction.
+ * is confidently wrong in the other direction. That is why the `takeown` line
+ * claims only what is true in **both** ownership branches: it supplies the DACL
+ * half and never `WRITE_OWNER`, so it is not the fix by itself — while still
+ * being a legitimate first step (with elevation) where the caller is not the
+ * owner. Calling it useless outright would have been the mirror-image error.
  * @param failure - the recognized provisioning failure.
  * @param path - the directory the error named, or the placeholder.
  * @returns the section's lines, or an empty array for a class it does not fit.
@@ -138,10 +160,11 @@ function nonFixes(failure, path) {
     if (failure.klass !== 'apply-denied')
         return [];
     return [
-        'What will NOT fix it — both look like the right move, and both were tried and reported:',
+        'What will NOT fix it on its own — both look like the right move, and both were tried and reported:',
         `  takeown /F "${path}" /R /D Y`,
-        "    makes you the owner, but ownership's implicit rights are READ_CONTROL and WRITE_DAC only.",
-        '    The owner does not implicitly hold WRITE_OWNER, which is the right this call needs.',
+        "    makes you the owner, and ownership's implicit rights are READ_CONTROL and WRITE_DAC only — so it",
+        '    supplies the DACL half and still not WRITE_OWNER, the right this call needs. In the second branch above',
+        '    it is a legitimate first step with elevation; it is never the fix by itself.',
         `  icacls "${path}" /reset /T /C`,
         '    restores inheritance, and inheritance is what supplied the Modify-only ACE above.',
         '',
@@ -214,17 +237,36 @@ 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.',
         '',
-        'Fix it (unelevated, one line) and then run the command again:',
+        '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.',
+        '',
+        'IF YOU OWN THE DIRECTORY — the usual workspace, whether on the system drive or a data volume:',
+        '  one unelevated line, then run the command again:',
         `  PowerShell: icacls "${path}" /grant "$env:USERNAME:(OI)(CI)(WO)"`,
         `  cmd:        icacls "${path}" /grant "%USERNAME%:(OI)(CI)(WO)"`,
         'WRITE_OWNER is exactly the right the prerequisite names, so this grants nothing the harness did not ask for,',
         'and (OI)(CI) makes the ACE inheritable, so one command reaches the workspace\'s existing subdirectories.',
         'Full control works just as well — the same line with `F` in place of `(WO)`:',
         `  icacls "${path}" /grant "$env:USERNAME:(OI)(CI)F"`,
-        'Both assume you own the directory: owner-implicit rights cover the DACL half of the merged write, so',
-        'WRITE_OWNER is the single missing piece. A directory owned by someone else is a bigger change than a',
-        'one-liner — that is the harness\'s documented prerequisite, and it is why this failure is loud instead of',
-        'silently skipped.',
+        'Why `(WO)` is the whole of what is missing there: an owner holds READ_CONTROL and WRITE_DAC implicitly,',
+        'and WRITE_DAC is what `icacls /grant` itself needs — so the DACL half of the merged write already has what',
+        'it wants, and WRITE_OWNER is the single missing piece.',
+        '',
+        'IF YOU DO NOT OWN IT — a directory an installer or another account created, e.g. owner',
+        '`BUILTIN\\Administrators`:',
+        '  the line above cannot run at all. Changing a DACL takes WRITE_DAC, which you hold neither as owner nor',
+        '  through any ACE, so `icacls /grant` is refused with `Access is denied` — for the very command that would',
+        '  fix it. The merged write wants WRITE_DAC and WRITE_OWNER together, so `(WO)` alone would not be enough',
+        '  here even if it went through. Run the grant once from an account that already holds both — that is, from an',
+        '  ELEVATED prompt:',
+        `  icacls "${path}" /grant "<your-account>:(OI)(CI)F"`,
+        'Full control is used because it is the rights set covering both halves; the other reach both reports name is',
+        'to take ownership first, which also needs elevation (it wants SeTakeOwnership), after which the unelevated',
+        '`(WO)` line above applies:',
+        `  icacls "${path}" /setowner "<your-account>"`,
+        'Or sidestep the ACL entirely: create the workspace under `%USERPROFILE%` — a directory created there',
+        'inherits Full control for you — and open the session on that one.',
         '',
         ...nonFixes(failure, path),
         'How to read this: the harness documents the prerequisite (' + PREREQUISITE + ') and this',

package/lib/signature.js

@@ -30,17 +30,32 @@
  *   the advisory can quote the exact line the model and the user are looking
  *   at, and the path can be re-used in the fix command.
  *
- * One signature covers two environments, and the text is identical in both, so
- * the classifier cannot and must not try to tell them apart: a workspace the
- * caller created with `mkdir` that inherits "Authenticated Users: Modify" from
- * the drive root (`#7622`, `#7646`, `#7720`), and a directory on a data volume
- * where **no ACE names the caller at all** so that the inherited entry is the
- * whole of their access (`#7750` on D:/E:, `#7735`'s second defect). Both are
- * the same gate — `WRITE_OWNER` on the directory — and the same one-line remedy
- * satisfies both, which is why they share a class and the advisory names both
- * shapes instead of guessing which one it is looking at. What the text *does*
- * carry that the failure does not is the version boundary: the merged
- * DACL + label write exists only from `0.1.7-alpha.1` on
+ * One signature covers three environments, the text is identical in all of them,
+ * and the classifier cannot and must not try to tell them apart — but the
+ * *remedy* is not the same in all of them, which is why the advisory forks on a
+ * check the user runs rather than on a guess this module cannot make:
+ *
+ * - a workspace the caller created with `mkdir` that inherits "Authenticated
+ *   Users: Modify" from the drive root (`#7622`, `#7646`, `#7720`);
+ * - a directory on a data volume where **no ACE names the caller at all**, so
+ *   the inherited entry is the whole of their access (`#7750` on D:/E:,
+ *   `#7735`'s second defect);
+ * - a directory **the caller does not own** — an installer- or
+ *   administrator-created one, `#7771` (owner `BUILTIN\Administrators`, held
+ *   deny-only for that token), which `#7804` reached from the other direction.
+ *
+ * In the first two the caller is the owner, so their implicit `WRITE_DAC`
+ * satisfies the DACL half and `WRITE_OWNER` is the single missing right — one
+ * unelevated `icacls /grant` supplies exactly it, and `#7750` measured that
+ * remedy working. In the third `WRITE_DAC` is missing as well, so that same
+ * `icacls` is refused for the very command that would fix it and `(WO)` alone
+ * would not be enough even if it went through. The advisory therefore hands over
+ * the ownership check (`(Get-Acl "<dir>").Owner`) as the branch selector and
+ * gives each branch the command that works there — the same class, two rights
+ * situations, and no guess about which one this is.
+ *
+ * What the text *does* carry that the failure does not is the version boundary:
+ * the merged DACL + label write exists only from `0.1.7-alpha.1` on
  * (`packages/sandbox/sandbox-windows-acl/src/acl.ts`, flag
  * `DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION`), so on an older line
  * the same string belongs to a different cause space.

package/lib/types/advice.d.ts

@@ -20,6 +20,24 @@
  *   separates "this is the label failure" from "this is something else", and
  *   because rolling back is the reach it invites while making the very problem
  *   it closed come back.
+ *
+ *   **The remedy is forked on ownership, because one command cannot serve both
+ *   environments.** The reports split into two rights situations behind an
+ *   identical error: a workspace **the caller owns** (`#7622`, `#7646`, `#7720`,
+ *   `#7750`, `#7804`), where the owner's implicit `WRITE_DAC` satisfies the DACL
+ *   half and `(WO)` is the whole of what is missing — so the `icacls /grant`
+ *   that supplies it *can itself run*, unelevated; and a directory **the caller
+ *   does not own** (`#7771`: owner `BUILTIN\Administrators`, held deny-only for
+ *   their token), where `WRITE_DAC` is missing too, so `icacls /grant` is denied
+ *   for the very command that would fix it, and `(WO)` alone would not be enough
+ *   even if it went through. The classifier cannot tell these apart — the text is
+ *   identical — so the advisory does what it can do instead of guessing: it hands
+ *   over the **ownership check** (`(Get-Acl "<dir>").Owner`) as the branch
+ *   selector, then gives each branch the command that actually works there, and
+ *   says why the other branch's command is not a fallback. A single unconditional
+ *   one-liner would send the second environment to a command that is refused
+ *   before it runs — the same defect this module exists to answer, a remedy that
+ *   does not work delivered confidently.
  * - **The persistent-shell failure** (`pty-startup`) is *not* fixable by the
  *   caller — least of all by the model, which has no shell to run anything in.
  *   So its advice says so and stops: the remedy is a user-side preset choice,
@@ -41,7 +59,7 @@
 import type { ProvisioningFailure, RecognizedFailure } from './signature.js';
 import type { SandboxModeName } from './mode.js';
 /** The upstream threads the ACL advisory is a stopgap for. */
-export declare const ACL_DISCUSSIONS = "#7538 / #7622 / #7646 / #7720 / #7750 / #7735";
+export declare const ACL_DISCUSSIONS = "#7538 / #7622 / #7646 / #7720 / #7750 / #7735 / #7771 / #7804 / #7816";
 /** The upstream thread the persistent-shell advisory is a stopgap for. */
 export declare const PTY_DISCUSSIONS = "#7638";
 /** The documented prerequisite, quoted from the backend's README. */

package/lib/types/signature.d.ts

@@ -30,17 +30,32 @@
  *   the advisory can quote the exact line the model and the user are looking
  *   at, and the path can be re-used in the fix command.
  *
- * One signature covers two environments, and the text is identical in both, so
- * the classifier cannot and must not try to tell them apart: a workspace the
- * caller created with `mkdir` that inherits "Authenticated Users: Modify" from
- * the drive root (`#7622`, `#7646`, `#7720`), and a directory on a data volume
- * where **no ACE names the caller at all** so that the inherited entry is the
- * whole of their access (`#7750` on D:/E:, `#7735`'s second defect). Both are
- * the same gate — `WRITE_OWNER` on the directory — and the same one-line remedy
- * satisfies both, which is why they share a class and the advisory names both
- * shapes instead of guessing which one it is looking at. What the text *does*
- * carry that the failure does not is the version boundary: the merged
- * DACL + label write exists only from `0.1.7-alpha.1` on
+ * One signature covers three environments, the text is identical in all of them,
+ * and the classifier cannot and must not try to tell them apart — but the
+ * *remedy* is not the same in all of them, which is why the advisory forks on a
+ * check the user runs rather than on a guess this module cannot make:
+ *
+ * - a workspace the caller created with `mkdir` that inherits "Authenticated
+ *   Users: Modify" from the drive root (`#7622`, `#7646`, `#7720`);
+ * - a directory on a data volume where **no ACE names the caller at all**, so
+ *   the inherited entry is the whole of their access (`#7750` on D:/E:,
+ *   `#7735`'s second defect);
+ * - a directory **the caller does not own** — an installer- or
+ *   administrator-created one, `#7771` (owner `BUILTIN\Administrators`, held
+ *   deny-only for that token), which `#7804` reached from the other direction.
+ *
+ * In the first two the caller is the owner, so their implicit `WRITE_DAC`
+ * satisfies the DACL half and `WRITE_OWNER` is the single missing right — one
+ * unelevated `icacls /grant` supplies exactly it, and `#7750` measured that
+ * remedy working. In the third `WRITE_DAC` is missing as well, so that same
+ * `icacls` is refused for the very command that would fix it and `(WO)` alone
+ * would not be enough even if it went through. The advisory therefore hands over
+ * the ownership check (`(Get-Acl "<dir>").Owner`) as the branch selector and
+ * gives each branch the command that works there — the same class, two rights
+ * situations, and no guess about which one this is.
+ *
+ * What the text *does* carry that the failure does not is the version boundary:
+ * the merged DACL + label write exists only from `0.1.7-alpha.1` on
  * (`packages/sandbox/sandbox-windows-acl/src/acl.ts`, flag
  * `DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION`), so on an older line
  * the same string belongs to a different cause space.
@@ -73,10 +88,14 @@
 export type FailureClass = 
 /**
  * `SetNamedSecurityInfoW` returned `ERROR_ACCESS_DENIED` (5): the merged
- * DACL + label write was refused. Both environments in the module doc land
- * here — the `mkdir`-inherited Modify workspace and the data-volume directory
- * with no ACE naming the caller — because the failure text cannot separate
- * them and the remedy is the same `WRITE_OWNER` grant.
+ * DACL + label write was refused. All three environments in the module doc
+ * land here — the `mkdir`-inherited Modify workspace, the data-volume
+ * directory with no ACE naming the caller, and the directory owned by another
+ * account — because the failure text cannot separate them. The first two are
+ * the same rights situation (the caller owns it; `WRITE_OWNER` is the whole of
+ * what is missing) and share the unelevated remedy; the third is missing
+ * `WRITE_DAC` as well, which is why the advisory hands over the ownership
+ * check and forks the command on it.
  */
 'apply-denied'
 /** `SetNamedSecurityInfoW` failed with a Win32 code other than `ERROR_ACCESS_DENIED`. */

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@argszero/cordis-plugin-sandbox-grant-advisor",
-  "description": "Turns two sandbox environment failures that name neither their cause nor a remedy into a diagnosis with a path forward. Family 1, the Windows workspace ACL: six reports (#7538, #7622, #7646, #7720, #7750, #7735) 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. Family 2, the persistent shell (#7638): with the `minimal` preset under a confining sandbox mode every shell call dies instantly with `PTY shell exited during startup` because the terminal backend cannot create the pseudo-console inside the sandbox, retrying never helps, and `minimal` mounts no fallback shell tool. The plugin observes the public `tools/post-execute` waterfall, classifies both signatures narrowly (only the two `...NamedSecurityInfoW` operations; the PTY message matched on a whole line, never as a substring, and only under a mode the policy resolver reports as confining), and attaches ONE durable user-role advisory per agent per family through `additionalContexts`. The ACL advisory names the missing right, both environments the identical text can describe (an inherited Modify-only entry, and a data volume where no ACE names the caller at all), the version boundary that arrived with the mandatory label (0.1.7-alpha.1, flag 20, versus the DACL-only flag 4 up to 0.1.6-alpha.x) together with why downgrading is not the remedy, the discriminator, the unelevated `icacls ... :(OI)(CI)(WO)` fix — the narrowest form of the exact right the backend's prerequisite names, with Full control offered second — and the two remedies that look right and are not (`takeown`, `icacls /reset`), each with the reason it fails; the PTY advisory names the failing combination, states the resolved mode, tells the model to stop rather than retry, and hands the user-side preset choice over — it never names a shell tool the failing composition does not mount. 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, 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.4.0",
+  "description": "Turns two sandbox environment failures that name neither their cause nor a remedy into a diagnosis with a path forward. Family 1, the Windows workspace ACL: nine reports (#7538, #7622, #7646, #7720, #7750, #7735, #7771, #7804, #7816) of one signature — every sandboxed command fails before it runs with `SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)`, because the merged DACL + mandatory-label write needs WRITE_OWNER on the directory (an object right the caller can self-grant), not SeSecurityPrivilege and not elevation; the host grant is materialized lazily and caches nothing on the failure path, so the same failure repeats per command. Family 2, the persistent shell (#7638): with the `minimal` preset under a confining sandbox mode every shell call dies instantly with `PTY shell exited during startup` because the terminal backend cannot create the pseudo-console inside the sandbox, retrying never helps, and `minimal` mounts no fallback shell tool. The plugin observes the public `tools/post-execute` waterfall, classifies both signatures narrowly (only the two `...NamedSecurityInfoW` operations; the PTY message matched on a whole line, never as a substring, and only under a mode the policy resolver reports as confining), and attaches ONE durable user-role advisory per agent per family through `additionalContexts`. The ACL advisory names the missing right, both environments the identical text can describe (an inherited Modify-only entry, a data volume where no ACE names the caller at all, and a directory owned by another account), the version boundary that arrived with the mandatory label (0.1.7-alpha.1, flag 20, versus the DACL-only flag 4 up to 0.1.6-alpha.x) together with why downgrading is not the remedy, the discriminator, the remedy forked on an ownership check the user runs (`(Get-Acl \"<dir>\").Owner`), because one command cannot serve both rights situations: where the caller owns the directory, the unelevated `icacls ... :(OI)(CI)(WO)` is the whole of what is missing — 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; the PTY advisory names the failing combination, states the resolved mode, tells the model to stop rather than retry, and hands the user-side preset choice over — it never names a shell tool the failing composition does not mount. 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, 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.5.0",
   "type": "module",
   "main": "lib/index.js",
   "types": "lib/types/index.d.ts",