@argszero/cordis-plugin-sandbox-grant-advisor 0.9.1 → 0.11.0

package/README.md

@@ -1,13 +1,15 @@
 # @argszero/cordis-plugin-sandbox-grant-advisor
 
 Turns a sandbox environment failure that has **no path forward** into a
-diagnosis the model — and the user reading the transcript — can act on. Three
+diagnosis the model — and the user reading the transcript — can act on. Four
 signatures, one mechanism:
 
 ```
 SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\ws)   # Windows workspace ACL
 PTY shell exited during startup                             # persistent shell × confining mode
 [exit code: -1073741502]  (0xC0000142)                      # a confined child that never started
+[exit code: 1]  sandbox: { mode: "workspace-write", denied: true }
+                                                            # denied INSIDE the workspace
 ```
 
 **This plugin is the stopgap for "the error does not name the outstanding
@@ -15,7 +17,7 @@ condition".** It repairs nothing: no ACL is written, no privilege is requested,
 nothing is elevated, no environment variable is set for another process, no
 preset is installed and no mode is changed.
 
-## The three failures it recognizes
+## The four failures it recognizes
 
 The first two are recognized on the public **`tools/post-execute`** waterfall
 (`@deepseek-ai/dsh-tools`) from the failure text. That seam is the one that has
@@ -24,9 +26,9 @@ all three of what a diagnosis needs: the failure
 `isError` result), an agent identity to attribute it to (`exec.agent`), and a
 channel that speaks to the model in the same step (`PostToolDecision`'s
 `additionalContexts`, which the agent loop turns into a durable user-role message
-— `packages/core/agent-loop/src/tool-calls.ts`). The third is recognized at the
-**same seam** from the canonical value of a result the pipeline calls a
-*success*, for a reason §3 gives in full.
+— `packages/core/agent-loop/src/tool-calls.ts`). The third and fourth are
+recognized at the **same seam** from the canonical value of a result the pipeline
+calls a *success*, for reasons §3 and §4 give in full.
 
 That seam, not `ctx.sandbox.confine`: `confine(argv, policy, signal)` sees the
 confinement failure too, but its signature carries no agent, so a wrapper could
@@ -44,6 +46,11 @@ inherited `Authenticated Users: Modify` is the whole of their access). In each o
 every sandboxed command fails the same way, before it runs, and the error names
 neither the missing right nor a remedy.
 
+Two further reports — [discussion #8312] and [discussion #8314] — describe the
+other end of the same backend: what its grant leaves behind *after* it applies.
+The advisory states that too (see [What the grant leaves behind](#what-the-grant-leaves-behind-added-in-0100)),
+because the advisory is the thing handing over the command that applies the grant.
+
 `#8232` contributes two facts about the *shape* of the failure rather than its
 cause, and both are in the advisory now. One is that the failure belongs to the
 **workspace, not the command**: there a `Get-Date` failed exactly like anything
@@ -229,7 +236,27 @@ What will NOT fix it on its own — both look like the right move, and both were
     makes you the owner, and ownership's implicit rights are READ_CONTROL and WRITE_DAC only — so it
     supplies the DACL half and still not WRITE_OWNER, the right this call needs.
   icacls "D:\ws" /reset /T /C
-    restores inheritance, and inheritance is what supplied the Modify-only ACE above.
+    restores inheritance, and inheritance is what supplied the Modify-only ACE above. Where it strips the last
+    entry naming you, the directory ends up in exactly the state the diagnosis above describes — its only access
+    the inherited `Authenticated Users:(M)` (#8314 measured that follow-on failure).
+
+What the grant leaves behind, once it applies — worth knowing before you run the command above, because the
+backend does not take it back:
+  The three entries are STANDING, deliberately, and nothing revokes them. ... They outlive the session and the
+  harness exiting (`sandbox-windows-acl/src/grant.ts`, `src/index.ts`).
+  The Low integrity label is INHERITABLE (`(OI|CI)`) and it lives in the SACL — which is why the `icacls /reset`
+  above does not take it off: that command rebuilds the DACL. Windows starts a process at the minimum of the
+  user's and the program's integrity, so anything started from a tree the harness has written to runs at LOW
+  integrity, and none of the symptoms names DSH (#8312 collects them): ... (#7709), ... (#8175), ... (#7735).
+  It can also leave the workspace. An NTFS hard link is a SECOND NAME for one file object, so both names share
+  one security descriptor — and a pnpm workspace is largely hard links (`node_modules` pointing into a
+  content-addressed store on the same volume). ... `vite build` unable to remove its own temp file, `pnpm
+  install` unable to replace a hook (#8314 measured the whole chain). ...
+  It is also why the label is not simply removable here: ... This advisory hands over no removal command: the
+  maintainers' own skill does not, and an unverified one would be the defect this plugin exists to answer.
+None of this makes the command above the wrong move — without it, nothing sandboxed runs in this workspace. It
+is what the harness does to a directory it has been pointed at, and it is worth knowing before rather than
+discovering it as a broken build in some other project later.
 
 One thing to know before asking for a weaker grant, because that is the next idea after this diagnosis —
 and it is not a smaller version of the same grant:
@@ -256,6 +283,54 @@ unconditional one-liner was printed, with a sentence noting it assumed
 ownership; that would have sent the second environment to a command that is
 denied — the same defect this plugin exists to answer.
 
+#### What the grant leaves behind (added in 0.10.0)
+
+[Discussion #8312] and [discussion #8314] report the other half of this backend,
+and the advisory now states it — before the reader runs the command it is being
+handed, because that command is what makes the backend's grant apply:
+
+- **The three entries are standing, by design, and nothing revokes them.** The
+  workspace grant is a *reuse cache*: the backend's dispose path revokes the
+  revocable (temp) grants and leaves the workspace edits, and its fail-closed
+  cleanup says the same in plainer words — standing ACEs "are NOT revoked — they
+  are the intended end state (the reuse cache), not an error artifact"
+  (`src/grant.ts`, `src/index.ts`). They outlive the session and the harness
+  exiting. ([#8312] arrived at this from the README's own description of the
+  cache; the source is quoted in the advisory.)
+- **The Low integrity label is inheritable, and it lives in the SACL.** That is
+  why `icacls /reset` — already listed as a non-fix for a different reason — does
+  not remove it: the command rebuilds the DACL. Windows starts a process at
+  `min(user, image)` integrity, so anything started from a tree the harness has
+  written to runs at Low integrity, and none of the symptoms points at DSH:
+  an Electron/Chromium app exiting `0x80000003` with no output ([#7709]),
+  msbuild / dotnet / npm refusing or warning about the files as if they came from
+  the Internet when no `Zone.Identifier` exists ([#8175]), a double-clicked
+  `.exe` / `.cmd` reporting "publisher could not be verified" ([#7735]).
+- **It can leave the workspace.** An NTFS hard link is a second name for one
+  file object, so both names share one security descriptor — and a pnpm workspace
+  is largely hard links (`node_modules` pointing into a content-addressed store
+  on the same volume). The inheritable label therefore lands on the *store's*
+  objects and stays there, after which every project building from that store
+  gets executables that start at Low integrity and failures that name the build
+  tool ([#8314] measured the whole chain: `vite build` unable to remove its own
+  temp file, `pnpm install` unable to replace a hook). The backend's own suite
+  pins the reach as a known boundary — *"a workspace hard link lets the grant
+  reach an external file object"* (`tests/runner.spec.ts`) — and its README calls
+  refusing multiply-linked files unviable for ordinary pnpm installs, which
+  leaves the out-of-tree reach open rather than unknown.
+- **No removal command is shipped.** The maintainers' own
+  `diagnose-windows-sandbox-acl` skill *reports* `LOW_LABEL` and by design does
+  not remove it, and removing an integrity label needs `WRITE_OWNER` — the same
+  right this whole failure is about. This project has no Windows host to verify a
+  line on, so shipping one would be exactly the defect the rest of this module
+  exists to answer; the section says where it stops instead.
+
+The section is emitted for **every** ACL class, like the version boundary and for
+the same reason: it is a fact about the package's grant, and that grant is the
+remedy the advisory hands over in all three classes. It also closes with what the
+fact does *not* mean — the command is still the right move, because without it
+nothing sandboxed runs at all.
+
 **What is deliberately *not* shipped**: `icacls ... /grant "<user>:(OI)(CI)(WD,WO)"`,
 the two needed rights named explicitly. It is the tighter form and it is
 plausibly correct syntax, but this project has no Windows host to run it on, and
@@ -287,6 +362,27 @@ built with the **resolved** mode the failing call actually ran under — from
 `ctx.sandboxPolicy.resolve({ session })`, the same resolver the terminal layer
 calls before spawning, with the same session.
 
+**Inside a confining mode, the host binary decides** (added in 0.10.0).
+[Discussion #8322] ran the control one level deeper — same runner, same ConPTY,
+every arm — and separated what the mode alone does not: with the runner hosted by
+a plain console-subsystem `node.exe`, the confined shell starts and its prompt and
+shell-integration marks are correct; with the runner hosted by the packaged
+desktop's GUI-subsystem Electron executable, the child dies **silently** — zero
+bytes on stdout *and* stderr, and the non-interactive arm exits 0 with everything
+it printed lost. It is the same rule the `0xC0000142` family states for its own
+case: under the restricted token a console can be **inherited but not created**,
+so the binary that owns one (or owns none) is what the arms turn on. That is also
+why the same version behaves differently depending on how it was started: the
+desktop app fails where the Web UI launched from a terminal — whose
+`process.execPath` is a real `node.exe` — is reported working under the same
+confining mode ([#8313], whose sibling report is the `0xC0000142` shape of the
+same host difference). The advisory therefore names the host alongside the mode,
+says the outcome is **deterministic per (session mode × host)** rather than
+intermittent, and adds that the mode which counts is the one the **session
+records**, not the one the environment now holds — a session that recorded the
+confining mode keeps failing after the app is restarted with another mode in its
+environment, while switching it inside the session takes effect at once.
+
 The advisory that follows is addressed to **two different readers**:
 
 ```
@@ -299,6 +395,15 @@ The `bash` tool is a PERSISTENT PTY session (a shell that stays alive between ca
 `workspace-write` — not `danger-full-access`. A confining mode spawns the shell through the sandbox, and there the
 terminal backend cannot create the pseudo-console at all, so the child exits before its first prompt. ...
 
+Which sessions fail inside that combination is not chance — it is deterministic per (session mode × the host
+binary carrying the sandbox runner) ... Measured against the desktop build with the same runner and the same
+ConPTY in every arm (#8322):
+  - runner hosted by a plain console-subsystem `node.exe` → the confined shell starts ...;
+  - runner hosted by the packaged desktop's GUI-subsystem Electron executable ... → the child dies silently ...
+The rule behind both this and the `0xC0000142` family ... is the one stated there for its own case: under the
+restricted token a console can be INHERITED but not CREATED ... And the mode that decides is the one the SESSION
+records, not the one the environment now holds ...
+
 Do NOT retry, and do not look for a command that fixes it: every attempt will fail identically, and there is no
 shell to run a command in. Use your file read/write tools instead, and hand the choice below to the user.
 
@@ -309,8 +414,11 @@ What unblocks the session — the user's decision, not the model's:
      `$DSH_HOME/cordis.patch.yml` for every profile — replacing its `persistent-shell` group with
      `@deepseek-ai/dsh-tool-pwsh` (a one-shot subprocess, no PTY); the patch layer is yours, so an upgrade
      will not overwrite it; or
-  3. run the session with `danger-full-access`, which drops the very confinement the sandbox exists to give.
-     Prefer 1 or 2.
+  3. run the session from a host that owns a console instead of the packaged desktop app — the Web UI started
+     from a terminal (`process.execPath` is a real `node.exe` there) was reported working under the same
+     confining mode and the same version (#8313); or
+  4. run the session with `danger-full-access`, which drops the very confinement the sandbox exists to give.
+     Prefer 1 to 3.
 ```
 
 The model's instruction is to **stop** — not to run a command (there is no shell
@@ -331,9 +439,10 @@ the advisory never names the dead directory.
 
 ### 3. A confined child that never started (`native-init`)
 
-Four reports of one exit code: [`#7876`] and [`#8193`] (the packaged desktop
-app) and [`#7877`] (MSYS2 / Git Bash) — and [`#8208`], which found the mechanism
-the console cases share. All are `0xC0000142`
+Five reports of one exit code: [`#7876`] and [`#8193`] (the packaged desktop
+app), [`#8313`] (the same version and the same mode run as the desktop app versus
+the Web UI launched from a terminal, which works) and [`#7877`] (MSYS2 / Git
+Bash) — and [`#8208`], which found the mechanism the console cases share. All are `0xC0000142`
 `STATUS_DLL_INIT_FAILED` — the Windows
 loader terminated the process while it was initializing its native images, i.e.
 **before the program's entry point**. A command that ran and then failed exits
@@ -514,6 +623,110 @@ 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)
+
+[#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
+every command died before it ran; here the grant **was** applied — on the
+workspace root, once — and part of the tree still refuses writes, forever. The
+report's shape: under `workspace-write` on Windows, a command writing into a
+subdirectory that was created or **moved in from outside** the session (an
+installer, an editor, another harness running under its own account) is denied,
+while the same command against a directory the harness itself created succeeds.
+
+```
+[exit code: 1]  sandbox: { mode: "workspace-write", denied: true }
+```
+
+**The signature is a value, not a message**, and this family is invisible from
+the error path for the same structural reason §3 is: a denied command exits
+nonzero, and the shipped shell tools report a nonzero exit as a finished run
+rather than as `isError`
+(`packages/shell/tool-pwsh/src/render.ts` reports `[exit code: N]` and drops a
+denial marker). The fact therefore arrives in `ToolExecutionSuccess.value`,
+where `tool-bash` / `tool-pwsh` project what the sandbox executor stamped
+(`packages/shell/bash-sandbox/src/index.ts`, `pwsh-sandbox`): the mode the call
+actually ran under, whether the backend's own refusal dialect appears in the
+**captured stderr**, and the enforcement that applied. Reading the executors'
+own stamp rather than a sentence means this plugin is reporting the harness's
+reading of its own sandbox, not a guess about a line of output.
+
+**What the advisory says.** Four things, and one it refuses:
+
+- **That retrying is provably useless.** The host-side grant is written once, on
+  the workspace **root**, and relies on Windows ACE inheritance to reach the
+  tree beneath it. Writing an inherited ACE into an *already-existing* child
+  needs `WRITE_DAC` on that child; where the caller does not hold it, Windows
+  skips the child silently — no error, no return value, no log line. The backend
+  then checks only the root (`hasExactGrant(workspaceRoot)` in
+  `packages/sandbox/sandbox-windows-acl/src/acl.ts`) and returns early once the
+  grant is there, which it is from the first call onwards. The descendants that
+  missed the propagation are never revisited — not later in this session, not in
+  any later one.
+- **Which objects miss it, and how many.** It is a fact about *who created
+  them*: objects the harness creates inherit the ACE, and objects that already
+  existed do not. [#423] measured 170 of 729 objects missing it, **including
+  root-level files** — so "write at the workspace root instead" is not a safe
+  move either.
+- **The discriminator, and its second half.** The advisory prints the path it
+  keyed on beside the root it tested it against, so the reader can audit the
+  claim instead of taking a statement about two strings on faith. Then the
+  measurement a single check gets wrong: reading and listing use the **normal**
+  token while writing and deleting use the **restricted** (low-integrity) one,
+  and both sides must pass — so an object whose DACL names only
+  `Administrators`/`SYSTEM` plus the capability SID is refused on the read side
+  too, and looks fine to a check that merely greps for the capability SID.
+  [#423] measured exactly that on a `.cache` directory.
+- **The second measured variant of the same shape.** The coverage that is
+  missing can be the mandatory-integrity **label** rather than a DACL entry —
+  reported in the same thread on 2026-09-29, against a `0.2.0-rc.1` install,
+  under the same root-only short-circuit. From inside a session the two are
+  indistinguishable; from outside, the repository's own diagnosis skill
+  separates them (`diagnose-windows-sandbox-acl`, 0.2.0 and later, reports
+  `hasExactDeny()` for the DACL half and `LOW_LABEL` — `S-1-16-4096` — for the
+  label half).
+- **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
+  reaches the child. The line that *would* work needs `WRITE_DAC` on the object,
+  which is the right in question. The advisory states the mechanism, names the
+  ceiling, and says out loud that it prints no command because this project has
+  no Windows host to verify one on — the same standard §1's standing-grant
+  section is held to, and for the same reason.
+
+**What it refuses to explain, and why that is the design.** A denial is the
+*sanctioned* outcome in three other situations, and advising about a missing
+inherited grant in any of them would be a confidently wrong cause:
+
+- **Outside the workspace** — a confining sandbox denying a path outside its
+  writable roots is the whole point, and the denial surface's one-shot escalation
+  offer is correct there.
+- **Under `read-only`** — that mode denies every write by construction, so an
+  in-workspace denial under it is the mode working.
+- **A runner failure** — the executor refuses to call a run denied when the
+  runner itself failed, and such a value is left alone for the same reason.
+
+What is left is exactly the anomaly: a denial under `workspace-write` of a path
+inside the session's own workspace. That is why the family reads the mode off
+the **value** (the executor stamped the mode it actually ran under, so no policy
+lookup can disagree with it), tests containment against the root the policy
+resolver reports, and speaks only when **every** absolute path the command's own
+arguments name lies under that root. A command that names an outside path as
+well — an interpreter under `C:\Program Files`, an output directory on another
+volume — is refused rather than guessed at, and so is a command naming only
+relative paths: in both cases the plugin cannot say *which* path was denied, and
+silence is the fail-closed direction. The platform gate is real here and cannot
+be dropped: the mechanism is ACE inheritance, which no other backend has.
+
+**On a denial it cannot finish placing** — a root the policy resolver does not
+report, or no mounted policy service at all — the plugin withholds the advisory
+and says so once on the host log. That is the disclosure rule §1's mode gate
+follows as well: silence alone would make "the sandbox is not the cause"
+indistinguishable from "this plugin could not tell".
+
+[#423] is a Discussion (the repository has issues disabled), and the reply
+covering this family is posted there.
+
 ## What it does with a recognized failure
 
 1. **One durable advisory per agent, per family.** An agent that hits two
@@ -524,10 +737,12 @@ relaxed.
    `warn` line, so the fact survives outside the transcript too.
 2. **A disclosure when it withholds.** The PTY and native-init advisories are
    only sent when the
-   resolved mode actually confines. If the mode is `danger-full-access`, or
-   cannot be resolved at all (no `sandboxPolicy` service mounted, no agent
-   session, a resolver that throws), the failure is left exactly as it was
-   **and the host log says so once**. Silence alone would make "the sandbox is
+   resolved mode actually confines, and the workspace-denial advisory only when
+   the workspace root is resolvable — the fact its containment claim is tested
+   against. If the mode is `danger-full-access`, or either fact cannot be
+   resolved at all (no `sandboxPolicy` service mounted, no agent session, a
+   resolver that throws, a policy without a root), the failure is left exactly as
+   it was **and the host log says so once**. Silence alone would make "the sandbox is
    not the cause" and "this plugin could not tell" indistinguishable from the
    outside. Withholding is never a guess: an unresolvable mode is *not* an
    invitation to fall back to the deployment default.
@@ -542,8 +757,8 @@ relaxed.
    refused twice — while a session can always make progress by spending the
    budget it has.
 
-   **Why the blocking half does not extend to the two mode-gated families** (it
-   is ACL-only by construction, in the parameter type): the ACL remedy is a
+   **Why the blocking half covers one family only** (it is ACL-only by
+   construction, in the parameter type): the ACL remedy is a
    command
    the user can run *while the session continues*, so refusing further identical
    calls cannot make the session unfinishable — spending the budget always lets
@@ -552,8 +767,11 @@ relaxed.
    native-init remedy is a launch fix on the user's side — whose one in-session
    part, rewriting an MSYS2 command, the model does by calling a *different*
    command, which has a different call key and is therefore never the call being
-   refused. Refusing calls in those families could only pad a session that is
-   already unable to do the thing being refused.
+   refused. The workspace-internal denial is not covered either, and for a
+   stronger version of the same reason: its remedy is not a command at all — the
+   object was skipped when the grant was written and nothing revisited it — so
+   refusing calls could only pad a session that is already unable to do the thing
+   being refused.
 
 ## Install
 
@@ -627,6 +845,15 @@ than one that stays silent.
   `[exit code: -1073741502]`, or any value that is not the shipped shell
   projection (`kind: 'foreground'`), is not this family — a line of text can
   never be mistaken for a loader status.
+- **A denial is not this family unless the plugin can place it.** A denial under
+  `read-only`, under `danger-full-access`, or on a host that is not Windows; a
+  value the executor marked as a runner failure (`denied` is not set when the
+  runner itself failed); a command naming a path outside the workspace; a command
+  naming an outside path as well as an inside one; and a command naming only
+  relative paths — all six are refused, and the first three are the *sanctioned*
+  outcomes rather than puzzles. The plugin reads the executors' own stamp rather
+  than a sentence, so a command whose output contains `denied: true` is not this
+  family either.
 - **Only one advisory per agent, per family.** The environment is explained
   once; repeating it per failed command would be noise competing with the
   failure itself.
@@ -635,9 +862,11 @@ than one that stays silent.
 
 - **The Windows path itself cannot be witnessed on macOS**, where this plugin
   was built. What the test suite proves is the decision layer — classification
-  of all three families (the third from the producer's own canonical value,
+  of all four families (the third from the producer's own canonical value,
   built by the suite with the reported `-1073741502` and the report's stderr
-  line), the once-per-agent-per-family rule, the sandbox-mode gate
+  line; the fourth from the executors' own stamp, built by the suite with the
+  mode, the `denied` flag and the refusal dialect the executor matches), the
+  once-per-agent-per-family rule, the sandbox-mode gate
   and its fail-closed behaviour, the fail-fast budget and its self-feeding
   guard, and the wiring to a real cordis `Context` and the real `ToolRuntime` —
   driven by fixtures that throw the producers' exact error shapes
@@ -647,7 +876,25 @@ than one that stays silent.
   a given Windows host reproduces the PTY startup failure; those are the user's
   one-line experiment and the reporter's own control, and both advisories say
   where they stop. The native-init family is the one that needs no Windows to be
-  faithful, because what it reads is a number inside a JSON value.
+  faithful, because what it reads is a number inside a JSON value. The
+  workspace-denial family is exercised the same way and **does** need the
+  platform fact, which the suite supplies by stubbing `process.platform` for the
+  arms that need `win32` and restoring it — the plugin reads the real fact rather
+  than a config knob, because a knob would be a backdoor into a shipped decision.
+  What that proves is the decision layer against the producers' stamped values;
+  the ACE-inheritance path itself is still unwitnessed here, and the advisory
+  says as much by shipping no repair command.
+- **The standing-grant section is source-level, and the out-of-tree reach is the
+  reporter's measurement.** What this section states about the backend's own
+  behaviour — that the workspace grant is standing, that nothing in the dispose or
+  fail-closed path revokes it, that the Low label is inheritable and lives in the
+  SACL — is read off the shipped source and the backend's own suite, and is quoted
+  as such. What it states about a hard link carrying the label onto a
+  content-addressed store is [#8314]'s measurement on their machine, which is why
+  the advisory attributes it instead of asserting it as a property of every
+  workspace, and why **no removal command is shipped**: this project has no
+  Windows host on which to verify one, and an unverified removal command is the
+  same defect this plugin exists to answer.
 - **It repairs nothing and elevates nothing.** If the directory really is
   Full-control for the caller, the remaining ACL hypothesis is
   `SeSecurityPrivilege` — i.e. the backend's documented prerequisite would be
@@ -667,7 +914,7 @@ than one that stays silent.
   outside the seam this plugin subscribes to. The report and its proposed fix
   stay with the maintainers; all this plugin can do is explain the provisioning
   failure that shares its root.
-- **The real fix is upstream, in all three families.** For the ACL failure,
+- **The real fix is upstream, in all four families.** For the ACL failure,
   `grantWrite` already computes `hasExactGrant` / `hasExactDeny` /
   `hasExactLabel` and discards which one was false, so the diagnostic that turns
   a 52-minute detour into one line belongs at that site. For the PTY failure,
@@ -676,7 +923,12 @@ than one that stays silent.
   the runner should be launched with the environment its own execution needs
   (`ELECTRON_RUN_AS_NODE=1` when `argv[0]` is an Electron binary — [`#7876`]'s
   three candidate fixes) or refuse, in a checkable way, an MSYS2 program under a
-  restricted token. This plugin is the stopgap for all three.
+  restricted token. For the workspace-internal denial the site is the same
+  `grantWrite`: its early return asks only whether the **root** already carries
+  the ACE, so the descendants that missed the propagation are never repaired —
+  the check would have to look past the root, or the denial surface would have to
+  say *which* path was refused instead of only that one was. This plugin is the
+  stopgap for all four.
 
 ## Compatibility
 
@@ -767,6 +1019,7 @@ the current runtime cannot distinguish rather than counting it as a pass.
 [discussion #7876]: https://github.com/deepseek-ai/deepseek-harness/discussions/7876
 [discussion #7877]: https://github.com/deepseek-ai/deepseek-harness/discussions/7877
 [discussion #8208]: https://github.com/deepseek-ai/deepseek-harness/discussions/8208
+[#423]: https://github.com/deepseek-ai/deepseek-harness/discussions/423
 [#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
@@ -778,3 +1031,13 @@ the current runtime cannot distinguish rather than counting it as a pass.
 [#8193]: https://github.com/deepseek-ai/deepseek-harness/discussions/8193
 [#8174]: https://github.com/deepseek-ai/deepseek-harness/discussions/8174
 [#8208]: https://github.com/deepseek-ai/deepseek-harness/discussions/8208
+[discussion #8312]: https://github.com/deepseek-ai/deepseek-harness/discussions/8312
+[discussion #8314]: https://github.com/deepseek-ai/deepseek-harness/discussions/8314
+[discussion #8322]: https://github.com/deepseek-ai/deepseek-harness/discussions/8322
+[#7709]: https://github.com/deepseek-ai/deepseek-harness/discussions/7709
+[#7735]: https://github.com/deepseek-ai/deepseek-harness/discussions/7735
+[#8175]: https://github.com/deepseek-ai/deepseek-harness/discussions/8175
+[#8312]: https://github.com/deepseek-ai/deepseek-harness/discussions/8312
+[#8313]: https://github.com/deepseek-ai/deepseek-harness/discussions/8313
+[#8314]: https://github.com/deepseek-ai/deepseek-harness/discussions/8314
+[#8322]: https://github.com/deepseek-ai/deepseek-harness/discussions/8322

package/cordis.patch.yml

@@ -45,6 +45,20 @@
 # the confined token is itself lowered to Low, so the directory's Low label is
 # what lets that child write there at all.
 #
+# And it says WHAT THE GRANT LEAVES BEHIND once it applies (#8312, #8314): the
+# three entries are STANDING and nothing revokes them (the backend's own dispose
+# and fail-closed paths leave them — "the intended end state (the reuse cache)"),
+# the Low integrity label is INHERITABLE and lives in the SACL (so `icacls /reset`
+# does not remove it — that rebuilds the DACL), a process starts at
+# min(user, image) integrity, and an NTFS hard link shares one security descriptor
+# with the file object it names — so in a pnpm workspace, whose node_modules are
+# hard links into a content-addressed store, the label can reach OUTSIDE the tree
+# and stay on the store's objects, after which unrelated builds fail in ways that
+# name the build tool and not DSH. The section is stated before the reader runs
+# the command, and it ships NO removal command: the maintainers' own diagnosis
+# skill reports the label and does not remove it, and removing an integrity label
+# needs WRITE_OWNER.
+#
 # Optional config:
 #
 #   - set:
@@ -64,15 +78,23 @@
 # this environment, and it is bounded by `maxDenials`, because a plugin that can
 # stop command execution must never be the reason a session cannot finish.
 #
-# A SECOND family is recognized on the same seam (#7638): with the `minimal`
-# preset and a confining sandbox mode, every shell call dies instantly with
+# A SECOND family is recognized on the same seam (#7638, #8322): with the
+# `minimal` preset and a confining sandbox mode, every shell call dies instantly
+# with
 #
 #   PTY shell exited during startup
 #
 # The terminal backend cannot create the pseudo-console inside the sandbox, so
 # the child exits before its first prompt; retrying never helps and `minimal`
-# mounts no fallback shell tool. That advisory states the resolved mode, tells
-# the model to STOP rather than retry, and hands the user a preset choice — it
+# mounts no fallback shell tool. Inside that combination the HOST BINARY decides
+# (#8322, one runner and one ConPTY in every arm): a console-subsystem `node.exe`
+# host starts the confined shell, while the packaged desktop's GUI-subsystem
+# Electron host kills it silently — the same console rule the third family
+# states, where a restricted token can inherit a console but not create one. The
+# outcome is deterministic per (session mode x runner host), and the mode that
+# counts is the one the session records. That advisory states the resolved mode,
+# tells the model to STOP rather than retry, and hands the user the choices — a
+# preset swap, a profile-patch row, or a host that owns a console (#8313); it
 # never names a command to run (there is no shell to run it in) and never names
 # a shell tool the failing composition does not mount. It is sent only when the
 # mode the call actually ran under confines; otherwise the failure is left
@@ -81,6 +103,62 @@
 # above deliberately does NOT cover this family: its remedy is a patch-layer
 # change the user makes between sessions, not a command that repairs the
 # running one.
+#
+# A THIRD family is recognized from a value, not from text (#7876, #7877,
+# #8193, #8208, #8313):
+#
+#   [exit code: -1073741502]        (0xC0000142 STATUS_DLL_INIT_FAILED)
+#
+# A confined Windows child died while its native images were loading, i.e.
+# before its entry point. It reaches the tool result as an ordinary nonzero
+# exit code — upstream's runner-failure rules admit only exit 127 with the
+# `windows-acl-run: ` signature, so this code is never reclassified and never
+# arrives as an error — which is why a plugin reading only error results is
+# structurally blind to it, and why the model retries a command that cannot
+# start. The read is the shell tool's own canonical value
+# (`ToolExecutionSuccess.value`, `kind: 'foreground'`), so no line of rendered
+# text can be mistaken for it. The advisory states the resolved mode, says the
+# process never reached its entry point, enumerates the measured producers
+# (an MSYS2 / Git-Bash program that cannot create its signal pipe under the
+# restricted token; the sandbox runner hosted by a GUI-subsystem Electron binary
+# or spawned without a console), carries the one conversion the model can make
+# itself (rewrite the work as PowerShell or `cmd`), names the remedy #8193
+# measured — a real node.exe host, which the desktop ships — and says plainly
+# which producers it does not know. Like the second family, it is mode-gated.
+#
+# A FOURTH family is the other half of the FIRST one's backend (#423). There the
+# grant could not be applied at all; here it WAS applied — on the workspace root,
+# once — and Windows ACE inheritance silently skipped the objects whose DACL the
+# caller could not write, so commands writing into a subdirectory created or moved
+# in from outside (an installer, an editor, another harness under its own account)
+# are denied forever while the same command against a directory the harness itself
+# created succeeds. The backend's provisioning check short-circuits on the root
+# (`hasExactGrant` returns early once the root carries the ACE), so those
+# descendants are never revisited. It is read from a value rather than from text,
+# like the third family and for the same reason (a denial exits nonzero and the
+# shipped shell tools report that as a finished run), but it needs no bespoke code:
+# the executors stamp the denial onto the value as
+#
+#   sandbox: { mode: "workspace-write", denied: true }
+#
+# produced by matching the backend's own refusal dialect in the captured stderr —
+# so this plugin reads the harness's own reading of its own sandbox. It speaks
+# only when the host is Windows, the stamped mode is `workspace-write`, and EVERY
+# absolute path the command names lies inside the session's workspace: a denial
+# anywhere else (outside the workspace, under `read-only`, a runner failure) is
+# the sandbox working as designed and is left alone. The advisory prints the path
+# it keyed on beside the root it tested it against, says that retrying is provably
+# useless, gives the DISCRIMINATOR — reading/listing use the normal token while
+# writing/deleting use the restricted one, and both sides must pass, so an object
+# whose DACL names only Administrators/SYSTEM plus the capability SID looks granted
+# to a check that just greps for the SID — names the second measured variant of
+# the same shape (the coverage missing on the mandatory-integrity LABEL rather
+# than on the DACL, separated from outside a session by the repository's own
+# `diagnose-windows-sandbox-acl`), and states the Windows ceiling that closes the
+# obvious repair (a recursive `icacls /grant` for a capability SID is refused with
+# ERROR_NONE_MAPPED (1332), because that SID has no name to map). It ships NO
+# repair command, for the reason the standing-grant section ships none: this
+# project has no Windows host to verify a line on.
 
 - insert:
     - id: sandbox-grant-advisor