[Bug] In-process subagents cannot write under inherited workspace-write because escalation fields remain exposed

[lorisliaoloris]

Summary

In DeepSeek Harness 0.1.1-rc.2 on Windows, in-process delegated subagents created through the built-in spawn / fork providers can read and analyze the inherited workspace, but cannot reliably call write, edit, or pwsh for ordinary workspace-local mutations.

The child correctly receives an inherited workspace-write sandbox override and the documented non-interactive approval=never policy. However, the model-facing tool surface still exposes the registry-global escalation arguments sandbox_permissions and justification. With GPT/Codex-compatible providers, ordinary calls are generated with those fields. The call is then rejected before the workspace-local operation executes.

This makes workspace-write + never children effectively read-only even though the inherited sandbox should permit workspace writes without approval.

Environment

• OS: Windows
• DSH: @deepseek-ai/dsh 0.1.1-rc.2
• @deepseek-ai/dsh-tool-pwsh 0.1.1-rc.2
• Web profile
• Parent workspace: D:\CF15
• Parent permission preset during reproduction: workspace-write + ask
• Subagent tools: built-in subagent / subagent_fork
• Providers used by those tools: in-process spawn / fork, not the optional product codex provider

Reproduction

1. Start a parent session with workspace-write + ask and workspace D:\CF15.
2. Verify the parent can create a file under D:\CF15\.tasks.
3. Create a child with the built-in subagent or subagent_fork tool.
4. Ask the child to read files under D:\CF15\Client\Assets.
5. Ask the same child to write D:\CF15\.tasks\subagent-write-probe.md.
6. The child can complete the reads, but its write is rejected before file mutation because its delegated approval policy is never and the call includes escalation fields.

We reproduced this with multiple existing children and a newly created foreground fork. A probe successfully enumerated 50 assets, and another child analyzed 92 assets, but neither could save its Markdown result.

Observed errors

Depending on the parent/child sandbox snapshot and generated arguments, the pre-execution errors include:

invalid justification: expected a non-empty sentence

and:

sandbox escalation to "danger-full-access" is not strictly wider than this call's current "danger-full-access" mode

A delegated child also reported:

The delegated session's write tool forces sandbox_permissions;
approval is disabled and the permission cannot be escalated,
so the write is rejected before execution.

Confirmed delegated-policy behavior

The documented child policy itself appears intentional. The installed implementation matches the repository design:

function captureDelegatedPolicyOverrides(parent) {
  return {
    sandboxMode: parent.ctx.get("sandboxPolicy")?.overrideOf(parent.session),
    approvalPolicy: parent.ctx.get("approval") === void 0 ? void 0 : "never"
  };
}

Installed location:

node_modules/@deepseek-ai/dsh-subagent/lib/index.js

The relevant official notes are:

• https://github.com/deepseek-ai/deepseek-harness/blob/master/.agents/notes/implemented/feature/2026-08-10-continuable-subagent-policy-inheritance.md
• https://github.com/deepseek-ai/deepseek-harness/blob/master/.agents/notes/implemented/feature/2026-08-15-product-subagent-noninteractive-permissions.md
• https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/subsystems/permission-presets.md

Therefore, the issue is not that the child has approval=never. The issue is that unavailable escalation arguments remain visible/generated even though the child should perform ordinary writes inside its inherited sandbox without escalation.

Failure chain

parent explicit workspace-write sandbox override
→ copied into the in-process child at delegation time
→ child approval policy pinned to never
→ registry-global tool schema still exposes escalation arguments
→ model generates sandbox_permissions / justification for an ordinary call
→ escalation validation runs before the workspace-local operation
→ child cannot write

Expected behavior

For an in-process child with workspace-write + never:

• Ordinary writes under the inherited workspace should execute without approval.
• The model-facing schema should expose no escalation fields when the effective approval policy is never; or the bridge should otherwise omit unavailable optional fields.
• True out-of-workspace elevation must remain denied.

A session-aware model-facing schema would ideally behave as follows:

Effective policy	Escalation fields visible to the model
read-only + ask	workspace-write, danger-full-access
workspace-write + ask	danger-full-access only
danger-full-access + ask	none
any sandbox + never	none

Impact

This prevents delegated subagents from independently completing:

• code changes and patches;
• test creation;
• documentation writes;
• contract/result files;
• work logs;
• build/test commands that need writable cache or temporary output.

The only current workaround in our workflow is:

child performs read-only analysis
→ child returns the complete patch/document in chat
→ parent mechanically writes it

That weakens role isolation, auditability, independent branch ownership, and multi-agent development workflows.

Related report and community workarounds

• Related Discussion [Bug Report] danger-full-access 下模型重试带 `sandbox_permissions` 的调用被"not strictly wider"拒绝——升级面不随当前模式裁剪，错误文案被误读为权限系统失效 #468: [Bug Report] danger-full-access 下模型重试带 `sandbox_permissions` 的调用被"not strictly wider"拒绝——升级面不随当前模式裁剪，错误文案被误读为权限系统失效 #468
• Community plugin with session-aware schema projection: https://github.com/HakureiMonika/dsh-sandbox-escalation-fix
• Community compatibility plugin that strips only provably redundant escalation arguments: https://github.com/YaoaY/dsh-gpt-compat

No third-party compatibility plugin was installed during this reproduction.

Questions

1. Is workspace-write + never an officially supported effective policy for in-process spawn / fork children, with workspace-local writes expected to succeed?
2. Should escalation fields be removed from the child-visible tool schema whenever the effective approval policy is never?
3. Is the registry-global escalation schema planned to become session-aware / exact-scope projected?
4. Is there a core fix version or milestone associated with Discussion [Bug Report] danger-full-access 下模型重试带 `sandbox_permissions` 的调用被"not strictly wider"拒绝——升级面不随当前模式裁剪，错误文案被误读为权限系统失效 #468?
5. Is there a supported profile-level workaround that preserves workspace-write + never without installing a third-party compatibility plugin?

---

中文摘要

当前内置 spawn/fork 子 Agent 会继承父会话显式的 workspace-write，同时按官方设计固定为 approval=never。它本应无需审批即可写入父工作区，但工具 Schema 仍暴露 sandbox_permissions 和 justification，GPT/Codex 兼容模型在普通写操作中生成这些字段，导致执行器先进入升级校验并拒绝调用。因此子 Agent 可以只读调查，却不能把结果写回工作区。

[173787247]

Your diagnosis matches the design notes you cited: the child should inherit workspace-write and pin approval=never, and ordinary writes under that workspace should run without a prompt.

What is broken is the model-facing schema, not the inherited policy. Escalation fields stay on the registry-global tools. GPT/Codex-compatible models fill optional sandbox_permissions / justification on a normal workspace write. Validation then treats that as an escalation. Under never, escalation cannot succeed, so the call dies before write / edit / pwsh runs. That is the same family as #468 (still open, no accepted answer, no public milestone).

Directly on your questions:

1. Yes — workspace-write + never is the intended in-process spawn / fork policy. Workspace-local writes are supposed to succeed without approval.
2. Yes — if effective approval is never, those escalation arguments should not be visible (or the bridge should drop them before validation).
3. A session-aware / exact-scope schema is the right end state. Core does not do that today; that is why the community plugins you linked exist.
4. No published core fix / milestone is attached to [Bug Report] danger-full-access 下模型重试带 `sandbox_permissions` 的调用被"not strictly wider"拒绝——升级面不随当前模式裁剪，错误文案被误读为权限系统失效 #468.
5. There is no documented first-party profile switch that keeps workspace-write + never and hides those fields. Without a plugin, the supported-looking workaround is still: child analyses, parent writes. Using a model that omits unused optional arguments may dodge it; it is not a policy fix.

Until schema projection is in core, a never child that still advertises escalation will keep looking read-only to GPT/Codex, even when the sandbox override is correct.

[liyangbing]

这个问题的根因是“有效权限策略”和“模型可见工具 schema”没有同步投影。SandBase Harness 的 delegated-agent 实现可以作为另一种边界参考：

• 子 Agent 通过父 Session 解析并复用同一个 sandbox backend，不会因为 delegation 回退到 runtime host；
• 子 Agent 默认不能继续 delegation（delegations: []、enable_general_subagent: false），避免权限/任务树无限扩展；
• delegation 有显式 roster、最大深度和 cycle/target 校验；
• 子 Agent 的工具集合在自己的 StrategyContext 中重新构建，父子执行上下文和事件日志相互隔离。

实现与测试：

• https://github.com/sandbaseai/sandbase-harness/blob/main/src/core/session/delegation-service.ts
• https://github.com/sandbaseai/sandbase-harness/blob/main/src/core/orchestrator/agent-orchestrator.ts
• https://github.com/sandbaseai/sandbase-harness/blob/main/tests/integration/delegation.test.ts

这不能直接修复 DSH 当前的 escalation 参数泄漏；仍建议在生成模型可见 schema 时按 effective sandbox/approval policy 投影字段，并在执行前再次校验 scope。关键原则是：子 Agent 可以继承父级的隔离边界，但不能继承未被明确授权的升级能力。

[PerryLink]

注：本条评论原文因编码问题曾显示为乱码，已重建为可读版（2026-09-07）。

关于「权限继承」这个坑，给一个实测可用的配置（来自 dsh-permission-rules 的实践场景）：主 agent 的子代理继承了 workspace 权限却不落盘时，显式给子代理开 escalation 即可：

# 放在 .dsh/rules.yml
- pattern: "**"
  action: allow
  agents: [subagent]      # 只放给子代理，不改变主代理
  tools: [write, edit, pwsh]

说明：agents 定位符支持三种形态（main/subagent/preset:），未命中时走 fail-closed 兜底；所有请求会先按 effective mode 收敛（工具缺省或父级 allow 时子代理仍受约束），规则有完整 schema 校验，权限决策按调用上下文判定，全部事件落盘可审计（permissionRules/decision）。安装：dsh plugin --profile web add dsh-permission-rules

[PerryLink]

Friendly nudge: my answer above covers the permission-inheritance path for in-process subagents (escalation fields and the three sandbox modes). If the write failure is still happening, reply with your escalation config and I'll trace the exact gap - and if it resolved the issue, marking the answer as the solution helps others who hit the same wall. (PerryLink, author of dsh-permission-rules / dsh-background-agents)