dsh-multi-folder 0.2.3 → 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,7 +42,15 @@ 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.
@@ -273,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

@@ -32,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.
@@ -452,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.'
       )
     },
@@ -522,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
@@ -730,9 +782,7 @@ 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.
@@ -744,14 +794,7 @@ export function apply(ctx) {
             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,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-multi-folder",
-  "version": "0.2.3",
+  "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",