dsh-multi-folder 0.2.2 → 0.2.4

package/README.md

@@ -71,10 +71,10 @@ Each confined command runs under **exactly ONE writable root** — the workspace
 
 - A command whose cwd stays the **primary workspace cannot create files inside a secondary directory**. `git -C <secondary> commit`, `cd <secondary>` inside a script, `git clone <url> <secondary>`, or absolute-path writes all fail with an OS-level `Permission denied` (e.g. `fatal: Unable to create '.../.git/index.lock': Permission denied`).
 - Symmetrically, a command re-rooted to a secondary directory cannot write to the **primary workspace** (or another secondary directory) in the same invocation.
-- **Rule for file-creating commands: set `workdir` to the directory the command writes into.** For git, run the command from inside the repository (pass `workdir` pointing at it) instead of using `git -C` from the primary workspace.
+- **Rule for file-creating commands: set `workdir` to the directory the command writes into**, and pass it as an **absolute** path — a relative `workdir` is resolved against the primary workspace, and changing the process directory inside the command (`Set-Location` / `cd`) does not widen the writable root (the write then fails with an OS-level denial, Windows error 5). For git, run the command from inside the repository (pass `workdir` pointing at it) instead of using `git -C` from the primary workspace. The rule applies to `run_in_background: true` runs exactly as to foreground ones.
 - Reads are unrestricted and need no `workdir`.
 
-When a shell run ends in such a denial and references a configured secondary directory, the plugin attaches a short diagnostic hint to the tool result explaining the workdir fix.
+When a shell run ends in such a denial and references a configured secondary directory, the plugin attaches a short diagnostic hint to the tool result explaining the workdir fix. A **background** run's denial surfaces later instead — in that job's `job_output` stream, after the tool call has already returned — so read the job output and re-run it with an absolute `workdir`.
 
 ## How it works
 

package/README.zh.md

@@ -71,10 +71,10 @@ Agent 无需任何额外操作：`read` / `glob` / `grep` 随处可用；`write`
 
 - cwd 停留在**主工作区**的命令**不能在副目录创建文件**。`git -C <副目录> commit`、脚本内 `cd <副目录>`、`git clone <url> <副目录>`、按绝对路径写文件等都会以操作系统级 `Permission denied` 失败（例如 `fatal: Unable to create '.../.git/index.lock': Permission denied`）。
 - 对称地，被换根到副目录的命令在同一次调用中也**不能写主工作区**（或另一个副目录）。
-- **创建文件的命令必须把 `workdir` 设为它要写入的目录。** 对 git 而言，请进入仓库目录执行（`workdir` 指向该仓库），而不是从主工作区用 `git -C`。
+- **创建文件的命令必须把 `workdir` 设为它要写入的目录，且必须使用该目录的绝对路径**——相对 `workdir` 只会相对主工作区解析；在命令内部切换进程目录（`Set-Location` / `cd`）也不会扩大可写根（写入会以操作系统级拒绝失败，Windows 错误码 5）。对 git 而言，请进入仓库目录执行（`workdir` 指向该仓库），而不是从主工作区用 `git -C`。该规则同样适用于 `run_in_background: true` 的后台任务。
 - 读操作不受限制，无需 `workdir`。
 
-当 shell 命令以这类拒绝失败且命令引用了已配置的副目录时，插件会在工具结果后附带一条简短的诊断提示，说明 workdir 的修正方式。
+当 shell 命令以这类拒绝失败且命令引用了已配置的副目录时，插件会在工具结果后附带一条简短的诊断提示，说明 workdir 的修正方式。**后台任务**的拒绝发生在工具调用返回之后，只出现在该任务的 `job_output` 输出里，那时不会再附带提示——请读取任务输出，并用绝对 `workdir` 重跑。
 
 ## 工作原理
 

package/docs/design.md

@@ -42,13 +42,25 @@ A listener on the `tools/execute` around-dispatch waterfall handles `write`, `ed
      request registered through the generic jobs runtime (`ctx.jobs`) exactly like
      the shipped shell tools (`kind` = tool name, `owner` = calling agent, streamed
      reads shaped for `job_output` with sandbox markers, terminal outcome in the
-     `completed`/`killed` vocabulary). A caller-aborted call falls through to the
+     `completed`/`killed`/`failed` vocabulary). `shell.start` is **async** (it
+     publishes the handle only once launch preparation — Windows ACL grants
+     included — succeeded, and rejects when preparation is cancelled or fails), so
+     the launch is adapted to the jobs runtime's synchronous `run(): JobHooks`
+     contract the same way the shipped tools' `processJob` does: the handle is
+     awaited, the job-owned `AbortSignal` travels into `shell.resolve` (a cancelled
+     job aborts preparation, not just an already-published process), a rejected
+     preparation settles the job as `failed` with the real cause, and a read before
+     publication is empty. A caller-aborted call falls through to the
      default pipeline, which raises the canonical abort error.
    The result carries the same canonical value/content shapes as the shipped tools, so
    downstream presentation keeps working.
-5. Anything else — unknown tools, paths outside every secondary directory, escalation
-   arguments (`sandbox_permissions`), missing optional services (`shell`, `jobs`),
-   or any error — falls through to `next()` and the default pipeline.
+5. Anything else — unknown tools, paths outside every secondary directory, missing
+   optional services (`shell`, `jobs`), or a failure **before** the target is
+   resolved into a secondary directory (path resolution, config lookup, service
+   lookup) — falls through to `next()` and the default pipeline. An explicit
+   escalation request (`sandbox_permissions` carrying a non-empty mode string) also
+   belongs to the default pipeline, which owns the approval flow; a `null`/empty
+   value is not a request and is intercepted normally.
 
 **Why mode parity is free:** the mode field of the standing policy is never touched.
 The DSH sandbox backends treat the per-call policy as fully specified and fence by its
@@ -269,6 +281,16 @@ window.__ModuleLoader__.load({
   Lifting this to real multi-root confinement needs an upstream change
   (`SandboxExecutionPolicy` carrying extra write roots and the ACL runner
   accepting several workspace write SIDs).
+- A **relative** `workdir` never re-roots a run: the shipped shell tools resolve
+  it against the session workspace (the primary root), so only an ABSOLUTE path
+  into a secondary directory is intercepted. Likewise, changing the process
+  directory inside the command (`Set-Location` / `cd`) moves the process cwd but
+  not the ACL write root — the reported symptom is an OS-level access denial on
+  the file write (Windows error 5, e.g. `torch.save`'s
+  `open file failed with error code: 5`), not a sandbox marker. On a BACKGROUND
+  run that denial surfaces in the job's `job_output` stream after the tool call
+  has already returned, so the `tools/post-execute` hint cannot see it; the fix
+  is the same — re-run with an absolute `workdir` inside the secondary directory.
 - Intercepted secondary-directory mutations do not participate in the
   `fs/write-intent` / `fs/edit-intent` intent guards (the interception calls
   the backend unconditionally, as a full replacement of the tool body), but

package/lib/index.js

@@ -16,6 +16,13 @@
  *    here with the session's standing sandbox policy re-rooted to that
  *    directory — identical semantics to the primary workspace in every mode
  *    (read-only denies, workspace-write allows, danger-full-access allows).
+ *    Interception OWNS such a call from the moment its target is resolved
+ *    inside a secondary directory: an interception failure is reported as the
+ *    call's own error and NEVER falls through to the default pipeline, which
+ *    fences every call against the PRIMARY workspace root and would therefore
+ *    turn any ordinary failure (a missing `old_string`, a locked target, an
+ *    unreadable file) into the spurious
+ *    `[sandbox: file access denied under workspace-write mode]` marker.
  *    Interception hydrates the configuration AWAITED (never a fire-and-forget
  *    read) and looks the dirs up by BOTH the policy root and the header cwd
  *    spelling, so a cold first call and a symlinked workspace cannot fall
@@ -25,7 +32,12 @@
  *    Background shell runs (`run_in_background: true`) register with the
  *    generic jobs runtime (`ctx.jobs`) under the same re-rooted policy,
  *    mirroring the shipped pwsh/bash tools so `job_output` / `job_kill` and
- *    finish notices keep working. Reads (read/glob/grep) are unfenced and
+ *    finish notices keep working. `shell.start` is ASYNC (it publishes the
+ *    handle only once launch preparation, Windows ACL grants included,
+ *    succeeded), so the launcher is adapted to the jobs runtime's synchronous
+ *    hooks contract exactly like the shipped tools' `processJob`: the job-owned
+ *    AbortSignal drives preparation cancellation and a rejected preparation
+ *    settles the job as `failed`. Reads (read/glob/grep) are unfenced and
  *    already work.
  * 3. Prompt injection: one ordered system-prompt section rendered per
  *    assembly from the configured directories of the assembling session.
@@ -445,8 +457,9 @@ export function apply(ctx) {
         '\nYou have the SAME read/write/edit and command-execution permissions on these directories as on the primary workspace under the current sandbox mode, ' +
         'but each command can write inside only ONE root — the directory its workdir resolves to. ' +
         'A command whose cwd stays the primary workspace CANNOT create files inside a secondary directory. ' +
-        'For shell tools, pass `workdir` pointing inside one of these directories — foreground and background (`run_in_background`) runs alike. ' +
-        'File-creating commands, git included, MUST set `workdir` to the secondary directory: do not run `git -C <secondary>` or `cd <secondary>` inside a command launched from the primary workspace. ' +
+        'For shell tools, pass `workdir` holding the ABSOLUTE path of one of these directories — foreground and background (`run_in_background`) runs alike. ' +
+        'A relative `workdir` is resolved against the PRIMARY workspace, never against a secondary directory. ' +
+        'File-creating commands, git included, MUST set `workdir` to the secondary directory: do not run `git -C <secondary>` or `cd <secondary>` inside a command launched from the primary workspace — changing the process directory inside the command (`Set-Location` / `cd`) does NOT widen the writable root, so writes into a secondary directory then fail with an OS-level access denial (Windows error 5). ' +
         'Reads from these directories work without `workdir`. The primary workspace remains the default working directory.'
       )
     },
@@ -515,6 +528,52 @@ export function apply(ctx) {
     }
   }
 
+  /**
+   * Adapt one asynchronous background launch to the jobs runtime's SYNCHRONOUS
+   * hooks contract, mirroring the shipped pwsh/bash tools' `processJob`.
+   *
+   * `shell.start` is ASYNC — it resolves the process handle only after launch
+   * preparation (Windows ACL grants included) and rejects when preparation is
+   * cancelled or fails — so the handle can never be dereferenced from `run()`.
+   * Calling it as if it returned a process made every background run in a
+   * secondary directory fail immediately with
+   * `Cannot read properties of undefined (reading 'then')` (`proc.done` read
+   * off the un-awaited promise). The job-owned AbortSignal travels into
+   * `shell.resolve`, so `cancel` stops a launch that has not published a handle
+   * yet, and a rejected preparation settles the job as `failed` instead of
+   * leaving it running forever. A background process outlives the tool call, so
+   * no CALLER signal is forwarded; `shell.start` ignores `timeoutMs` by design.
+   */
+  const startBackgroundJob = (shell, request) => {
+    const controller = new AbortController()
+    let proc
+    const done = (async () => {
+      try {
+        proc = await shell.start(shell.resolve({ ...request, signal: controller.signal }))
+        try {
+          if (controller.signal.aborted) proc.kill()
+        } finally {
+          await proc.done
+        }
+        return processOutcome(proc)
+      } catch (error) {
+        return {
+          status: controller.signal.aborted && proc === undefined ? 'killed' : 'failed',
+          detail: error && error.message !== undefined ? String(error.message) : String(error),
+        }
+      }
+    })()
+    return {
+      cancel: (reason) => {
+        if (controller.signal.aborted) return
+        controller.abort(reason)
+        if (proc !== undefined) proc.kill()
+      },
+      done,
+      readOutput: () => (proc === undefined ? '' : renderProcessRead(proc.readOutput(), proc.sandbox)),
+    }
+  }
+
   /**
    * One consuming background read, shaped for `job_output`: the raw delta plus
    * loss/spill notices and sandbox markers, mirroring the shipped pwsh/bash
@@ -544,6 +603,30 @@ export function apply(ctx) {
     return read.delta + (read.delta.length > 0 && !read.delta.endsWith('\n') ? '\n' : '') + notices.join('\n')
   }
 
+  /**
+   * Model-facing failure for a call the interception OWNS (see the ownership
+   * rule below). A claimed call is never handed back to the default pipeline,
+   * so its real error reaches the model in the shipped tools' error envelope —
+   * `Error: <message>` plus the `FS_*` code — instead of the primary-rooted
+   * sandbox denial. A genuine sandbox denial (read-only mode) keeps the standard
+   * marker plus the one-shot escalation hint, exactly as the shipped
+   * `write`/`edit` tools render it, so the escalation flow is unchanged.
+   */
+  const ownedFailure = (error, policy) => {
+    const code = error && typeof error.code === 'string' && error.code.length > 0 ? error.code : undefined
+    const message =
+      code === 'FS_SANDBOX_DENIED'
+        ? '[sandbox: file access denied under ' + policy.mode + ' mode]\n' +
+          '[sandbox: escalation available \u2014 retry this exact operation once with sandbox_permissions ' +
+          '(the narrowest wider mode that suffices) + justification; the approval prompt asks the user]'
+        : String(error && error.message ? error.message : error)
+    return {
+      isError: true,
+      error: { message, ...(code === undefined ? {} : { info: { code } }) },
+      content: [{ type: 'text', text: 'Error: ' + message }],
+    }
+  }
+
   ctx.on('tools/execute', async (exec, next) => {
     // Hydration must be AWAITED on the interception path, not fire-and-forget:
     // a first call that arrives before the config read resolves would see an
@@ -560,12 +643,21 @@ export function apply(ctx) {
       await loadDirs(headerCwd)
     }
     if (!INTERCEPT_TOOLS.has(exec.name)) return next()
+    // Non-null once the call's target has been resolved into a configured
+    // secondary directory: from that point the interception OWNS the call and a
+    // failure must be reported as this call's error, never handed back to the
+    // default pipeline (which fences against the PRIMARY workspace root and
+    // would answer any failure with the spurious workspace-write denial).
+    let owned = null
     try {
       const args = exec.arguments
       const standing = sandboxPolicy.resolve(exec.agent ? { session: exec.agent.session } : {})
       const primary = standing.workspaceRoot
-      // An explicit escalation request belongs to the default pipeline.
-      if (args && args.sandbox_permissions !== undefined) return next()
+      // An explicit escalation request belongs to the default pipeline (it owns
+      // the approval flow). Only a non-empty mode string is a request: a
+      // null/empty value is not, and must not hand a secondary-directory
+      // mutation to the primary-rooted pipeline.
+      if (args && typeof args.sandbox_permissions === 'string' && args.sandbox_permissions.length > 0) return next()
       // The policy root is realpath-canonicalized by sandbox-policy while
       // hydration is keyed by the session cwd as spelled in the header; on a
       // workspace reached through a symlinked/junctioned ancestor the two
@@ -579,7 +671,20 @@ export function apply(ctx) {
         if (filePath === null) return next()
         // Resolve first so `..`, symlinks, and case differences canonicalize
         // before containment matching (same cwd the shipped tools use).
-        const target = await fs.resolve(filePath, { cwd: primary })
+        let target
+        try {
+          target = await fs.resolve(filePath, { cwd: primary })
+        } catch (error) {
+          // An unresolvable ABSOLUTE path that is lexically inside a secondary
+          // directory is still this plugin's call to answer: the default pipeline
+          // would resolve it against the PRIMARY root and report the sandbox
+          // denial, hiding the resolution failure.
+          if (dirs !== null && isAbsolute(filePath)) {
+            const rawHit = longestRootFirst(dirs).find((d) => pathInside(filePath, d))
+            if (rawHit !== undefined) return ownedFailure(error, { ...standing, workspaceRoot: rawHit })
+          }
+          return next()
+        }
         const abs = fs.processPath(target)
         // Security boundary: configuration is user-managed. Reject direct
         // write/edit attempts against the host-owned config file, even before
@@ -601,6 +706,7 @@ export function apply(ctx) {
         const policy = { ...standing, workspaceRoot: hit }
 
         if (exec.name === 'write') {
+          owned = { policy }
           const outcome = await fs.writeText(target, String(args.content), undefined, exec.signal, policy)
           // Keep the observation layer coherent with the shipped write tool's
           // contract: a successful create/update is a presence observation.
@@ -628,6 +734,7 @@ export function apply(ctx) {
         const newString = args && typeof args.new_string === 'string' ? args.new_string : null
         if (oldString === null || newString === null) return next()
         const replaceAll = args.replace_all === true
+        owned = { policy }
         const outcome = await fs.editText(
           target,
           { oldString, newString, replaceAll },
@@ -675,27 +782,19 @@ export function apply(ctx) {
         // Background runs get the SAME re-rooted policy as foreground runs.
         // They register with the generic jobs runtime (`ctx.jobs`) exactly
         // like the shipped pwsh/bash tools do, so `job_output` / `job_kill`
-        // and the finish notice keep working for the intercepted job. A
-        // background process outlives the tool call, so no caller signal is
-        // forwarded; `shell.start` ignores `timeoutMs` by design.
+        // and the finish notice keep working for the intercepted job.
         if (args && args.run_in_background === true) {
           // An aborted call belongs to the default pipeline, which raises the
           // canonical abort error before anything starts.
           if (exec.signal && exec.signal.aborted) return next()
           const jobs = ctx.get('jobs')
           if (jobs === undefined) return next()
+          owned = { policy }
           const jobId = jobs.start({
             kind: exec.name,
             label: String(args.command),
             ...(exec.agent ? { owner: exec.agent } : {}),
-            run: () => {
-              const proc = shell.start(shell.resolve(request))
-              return {
-                cancel: () => void proc.kill(),
-                done: proc.done.then(() => processOutcome(proc)),
-                readOutput: () => renderProcessRead(proc.readOutput(), proc.sandbox),
-              }
-            },
+            run: () => startBackgroundJob(shell, request),
           })
           return {
             isError: false,
@@ -704,6 +803,7 @@ export function apply(ctx) {
           }
         }
 
+        owned = { policy }
         const result = await shell.run(shell.resolve({ ...request, signal: exec.signal }))
         if (result.aborted) {
           return {
@@ -744,9 +844,14 @@ export function apply(ctx) {
         return { isError: false, value, content: [{ type: 'text', text: shellRender(value) }] }
       }
       return next()
-    } catch {
-      // Any interception failure falls back to the default pipeline.
-      return next()
+    } catch (error) {
+      // A failure BEFORE the call was claimed (path resolution, config lookup,
+      // shell service lookup) falls back to the default pipeline. A failure
+      // AFTER the claim — the mutation or the shell run itself — does not: the
+      // default pipeline fences the call against the PRIMARY workspace root, so
+      // it could only answer with the spurious workspace-write denial and would
+      // hide the real cause (for example a missing `old_string`).
+      return owned === null ? next() : ownedFailure(error, owned.policy)
     }
   })
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-multi-folder",
-  "version": "0.2.2",
+  "version": "0.2.4",
   "description": "DeepSeek Harness plugin: secondary working directories for a project. The agent keeps the primary workspace as cwd, gains equal write/exec permissions on configured secondary directories under workspace-write mode, and is notified of configuration changes at the next message boundary. Configurable from the session header AND from the session-creation page (before the first message) through a sessionless multiFolder remote API.",
   "keywords": [
     "dsh-plugin",
@@ -42,6 +42,7 @@
     "compatibility": {
       "node": ">=20",
       "dshReleases": {
+        "0.1.6-alpha.1": "compatible",
         "0.1.2-alpha.5": "compatible",
         "0.1.2-alpha.4": "compatible",
         "0.1.2-alpha.3": "compatible",