ACP profile: agentOptions() only passes provider/model — sandbox/permission config is dropped, fs tools escape the workspace boundary (0.2.0-rc.2)

[huxiaoqiao]

Version: @deepseek-ai/dsh 0.2.0-rc.2 (npm) — posting here since issues are disabled on this repo.

Summary

With the same composed patch (fs-sandbox cwd + permission preset workspace-write/ask), fs tool writes outside the session cwd behave differently per channel:

• headless / web sessions: correctly denied — the write tool returns sandbox: file access denied under workspace-write mode (fail-closed).
• ACP sessions (dsh --profile acp): the same write succeeds — the file is created on disk outside the workspace. No sandbox denial, no permission request.

Code path

@deepseek-ai/dsh-acp/lib/index.js builds the agent creation options via:

function agentOptions(config) {
  return {
    ...config.provider !== void 0 ? { provider: config.provider } : {},
    ...config.model !== void 0 ? { model: config.model } : {}
  };
}

This is passed as agentOptions to AcpSession.create(...) / AcpSession.resume(...) for both session/new and session/resume. Other channel entry points surface sandbox/permission configuration to the agent; the ACP path reduces it to {provider, model}, so a workspace-write sandbox configured in the patch (or in the deployment config) never reaches agents created through ACP sessions.

Repro

1. Compose a patch with fs-sandbox: {cwd: <workspace>} and the permission preset row (workspace-write sandbox, ask approval, defaultPreset: workspace-write).
2. Start dsh --profile acp --patch <patch>, initialize, then session/new with cwd: <workspace>.
3. Prompt the model to create a file with the fs write tool at an absolute path outside <workspace> (shell tools disallowed in the prompt).
4. Observed: the write tool executes successfully and the file exists on disk outside the workspace. Expected: the tool result is a sandbox denial (as in headless sessions with the same patch).

The composed patch itself is correct — dsh dump-config shows the sandbox/permission rows; a headless session with the identical patch denies the same request. session/request_permission works fine over ACP, so the approval plumbing is there; only the sandbox wiring is dropped.

Impact & workaround

Embedders driving DSH over ACP (the standard Agent Client Protocol surface) silently lose the workspace-write path boundary; the channel difference is invisible from the patch/config side. We worked around it in our product with a host-side plugin that gates the tools/pre-execute waterfall (path policy per tool call), which fully restores the boundary for fs tools — but the underlying gap looks unintended for rc.2.

[argszero]

Thanks for the write-up — the code path is right. I'd sharpen the diagnosis in one place, because it moves where the fix has to go.

agentOptions() (packages/acp/acp/src/index.ts) really does return {provider?, model?}. But AgentOptions (packages/core/agent/src/runtime-types.ts) is only {provider, model, reasoningEffort, maxTokens} — there is no sandbox or permission field to forward. So the dropped wiring is not a missing field in that literal; the ACP session never composes the rows at all. The comment immediately above the first AcpSession.create(...) says it in as many words:

No preset composition: the ACP bundle keeps the model-facing rows in the host plane, so this agent reads them from the global layer. A deployment that configures a roster has to join one here first.

That is the channel difference you measured: a deployment whose sandbox/permission rows live in a preset gets them for headless/web sessions, which join the deployment preset, and gets none for ACP sessions, which join nothing. It is not listed in the package README's "Known Limitations and Deferred Work" either. I'd file it as the composition gap rather than "sandbox not forwarded", because "add the field to agentOptions" is not an available fix.

On the workaround, one caveat worth writing down for whoever reads this later: a tools/pre-execute gate is a policy boundary, not a capability boundary. The decision vocabulary is allow | deny | cancel | ask (packages/core/tools/src/index.ts) — there is no arm that rewrites arguments, so a path gate can only refuse a call, and the waterfall sees the calls that go through the tool registry, so anything reached from a shell subprocess or an MCP server is outside it. We ship plugins on that same seam (for example @argszero/dsh-destructive-command-guard, which denies destructive shell invocations before dispatch), and it is the right place for that kind of policy. It is the wrong place to re-establish a boundary the host stopped enforcing: it turns "escapes the workspace" into "escapes the workspace unless the model routes through a registered tool", which is not the same property.

So I'd keep the gate as defence in depth, but treat the boundary itself as belonging back in the composition.