@argszero/cordis-plugin-sandbox-grant-advisor 0.10.0 → 0.12.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
@@ -437,10 +439,13 @@ the advisory never names the dead directory.
 
 ### 3. A confined child that never started (`native-init`)
 
-Five reports of one exit code: [`#7876`] and [`#8193`] (the packaged desktop
+Seven 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`
+the Web UI launched from a terminal, which works), [`#8334`] (the same code with
+the authorization side attached: the grant **succeeded** and every confined child
+still died) and [`#7877`] (MSYS2 / Git
+Bash) — and [`#8208`], which found the mechanism the console cases share, and
+[`#8336`], which measured the creation flags that mechanism turns on. 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
@@ -546,10 +551,37 @@ Two producers have been measured under a confining mode:
    ordinary path (`process.ts:567`, i.e. `0x404`); `CREATE_NO_WINDOW`
    (`0x08000000`) is **not a constant anywhere in that source**. Those flags are
    fatal under a console-less runner and harmless under one that owns a console —
-   so it is the console, not the flag list, that decides. `0.7.x` wrote the
-   two-set version of that list and called the flags "a necessary ingredient ...
-   the host process image is what turns it fatal"; both halves were wrong, and
-   `0.8.0` replaces them.
+   so **there** the console decides. `0.7.x` wrote the two-set version of that
+   list and called the flags "a necessary ingredient ... the host process image is
+   what turns it fatal"; both halves were wrong, and `0.8.0` replaces them.
+
+   **`0.11.0` and earlier concluded too much from those three sets** — "it is the
+   console and not the flag list that decides" — and [`#8336`] measured the case
+   that falsifies it: with a console-owning host, a restricted token and the Low
+   integrity level, varying only the creation flags, `CREATE_NO_WINDOW` and
+   `CREATE_NEW_CONSOLE` both died with `0xC0000142`, while `0`, `DETACHED_PROCESS`
+   and `CREATE_NEW_PROCESS_GROUP` reached the program. So the console decides
+   **whether a flag that merely shares the inherited console is fatal**, and a
+   flag that forces the child to create one of its own is fatal regardless. The
+   pair inside that matrix is what makes it a rule rather than a list of forbidden
+   flags: the same `CREATE_NO_WINDOW` on an *unrestricted* token reached the
+   program, and `STARTF_USESHOWWINDOW` with `SW_HIDE` — how the harness hides a
+   window without isolating a console — was harmless on the restricted one.
+   `0.12.0` replaces the withdrawn sentence with the rule and that matrix.
+
+   **The `windowsHide` suspicion, answered.** It is the first thing a search turns
+   up for this failure, and it points at the wrong component: the flag appears
+   once on the *ordinary* subprocess path
+   (`packages/subprocess/subprocess-local/src/spawn.ts:472`,
+   `windowsHide: platform === 'win32'`), which starts the runner rather than the
+   confined child, and the restricted spawn defines no `CREATE_NO_WINDOW` constant
+   at all. It is **not** set in `dsh-jobs` — a search there finds nothing, and
+   every `windowsHide` in the tree sits on a host-side or ordinary spawn. And
+   where it *is* set, [`#8208`] measured it both ways on a host that works: with
+   and without `windowsHide`, the confined `pwsh` reached exit `0` with its own
+   stdout intact. The reason is the rule again — a windowless console is still a
+   console, and that is what the child inherits; what decides is whether the host
+   owns a console **object**, not whether it owns a window.
 
    **One arm was applied, measured, and rejected.** Putting `DETACHED_PROCESS` on
    the *restricted child* removes its console request and does stop the crash —
@@ -621,6 +653,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
@@ -631,10 +767,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.
@@ -649,8 +787,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
@@ -659,8 +797,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
 
@@ -734,6 +875,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.
@@ -742,9 +892,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
@@ -754,7 +906,14 @@ 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
@@ -785,7 +944,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,
@@ -794,7 +953,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
 
@@ -885,6 +1049,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
@@ -906,3 +1071,5 @@ the current runtime cannot distinguish rather than counting it as a pass.
 [#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
+[#8334]: https://github.com/deepseek-ai/deepseek-harness/discussions/8334
+[#8336]: https://github.com/deepseek-ai/deepseek-harness/discussions/8336

package/cordis.patch.yml

@@ -105,7 +105,7 @@
 # running one.
 #
 # A THIRD family is recognized from a value, not from text (#7876, #7877,
-# #8193, #8208, #8313):
+# #8193, #8208, #8313, #8336, #8334):
 #
 #   [exit code: -1073741502]        (0xC0000142 STATUS_DLL_INIT_FAILED)
 #
@@ -124,7 +124,51 @@
 # 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.
+# which producers it does not know. It also states the one 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, and #8208 measured `windowsHide` both ways on a host
+# that works, so the advisory answers that suspicion with where the flag
+# actually appears — the ordinary subprocess path, not the confined one — and
+# with why a windowless console is still an inheritable console. Like the second
+# family, it is mode-gated.
+#
+# A FOURTH family is the other half of the FIRST one's backend (#423). There the
+# grant could not be applied at all; here it WAS applied — on the workspace root,
+# once — and Windows ACE inheritance silently skipped the objects whose DACL the
+# caller could not write, so commands writing into a subdirectory created or moved
+# in from outside (an installer, an editor, another harness under its own account)
+# are denied forever while the same command against a directory the harness itself
+# created succeeds. The backend's provisioning check short-circuits on the root
+# (`hasExactGrant` returns early once the root carries the ACE), so those
+# descendants are never revisited. It is read from a value rather than from text,
+# like the third family and for the same reason (a denial exits nonzero and the
+# shipped shell tools report that as a finished run), but it needs no bespoke code:
+# the executors stamp the denial onto the value as
+#
+#   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