Files
deepseek-harness/examples/acp-agent/sandbox.cordis.yml
kingwl 624d8d5df4 refactor(examples): fold the sandbox composition into acp-agent as its variant
sandbox-acp-agent's whole surface moves into examples/acp-agent following
the example's existing multi-variant shape (the code-mode/both-mode
overlays): sandbox.cordis.yml + its replay overlay, the four snapshot
scenarios (config-options / mode-switching / escalation-approved /
escalation-rejected) as a 'sandbox' header class over per-scenario
configPath — goldens byte-identical, zero re-recording — and
escalation.e2e.ts unchanged apart from the config path. One ACP example
remains; demo:sandbox-acp keeps its name and boots the variant. References
(both RFCs, group/package READMEs, the examples table and test map, the
e2e workflow comment) now point at the variant.
2026-07-13 14:37:59 +08:00

61 lines
2.8 KiB
YAML

# The SANDBOX VARIANT of the acp-agent example: the sandboxed coding agent
# served over the Agent Client Protocol, with the approval seam composed —
# the live approval composition (`pnpm run demo:sandbox-acp`). A sandbox denial escalated by the model
# (sandbox_permissions + justification) reaches the EDITOR as a
# session/request_permission prompt through the ACP bridge's answerer, and an
# "Allow once" runs exactly that command under the wider mode.
#
# CRITICAL: this tree loads NO stdout logger and NO hmr — stdout is reserved
# for the ACP JSON-RPC protocol (a property of @deepseek-ai/dsh-acp-agent,
# same as the sibling cordis.yml).
#
# Requires DEEPSEEK_API_KEY (and optionally DEEPSEEK_BASE_URL) — the
# dsh-acp-agent bin loads the gitignored repo-root .env first (on STDERR only).
# The DeepSeek adapter.
- id: llm-deepseek
name: '@deepseek-ai/dsh-llm-deepseek'
config:
apiKey: !!js process.env.DEEPSEEK_API_KEY
baseURL: !!js process.env.DEEPSEEK_BASE_URL
models:
- deepseek-v4-flash
# The sandbox stack: the platform-runner provider (bwrap → per-platform
# Landlock launcher → Seatbelt, functionally probed), then the confined bash executor.
# read-only is the fail-safe default; the write boundary for an escalated
# workspace-write run is workspaceRoot + the platform's temp area. NOTE: the
# workspace root is CONFIG-FIXED for the executor's lifetime (the launch dir
# here), while each ACP session has its own cwd — a per-session root is config-
# phase future work in the sandbox RFC.
- id: sandbox
name: '@deepseek-ai/dsh-sandbox-local'
- id: bash
name: '@deepseek-ai/dsh-bash-sandbox'
config:
mode: read-only
workspaceRoot: !!js process.cwd()
# The approval seam (ctx.approval — mechanism only, no config): with it
# mounted, the bash tool's escalation gate has a channel, and the ACP bridge
# inside dsh-acp-agent answers for the sessions it owns by prompting the
# editor. Without an editor attached nothing can answer, and every ask fails
# closed.
- id: approval
name: '@deepseek-ai/dsh-user-approval'
# The ACP server app: the agent-core spine + JSONL persistence + the ACP
# bridge (whose approval answerer completes the loop).
- id: acp-agent
name: '@deepseek-ai/dsh-acp-agent'
config:
model: deepseek-v4-flash
# Persistence root: $DSH_SNAPSHOT_SESSIONS_ROOT when the snapshot harness
# sets it (so a record run's logs land where the harness harvests them),
# else the local ./.sessions default.
persistenceRoot: !!js process.env.DSH_SNAPSHOT_SESSIONS_ROOT ?? './.sessions'
persona: |
You are a coding assistant powered by the {{model}} model. Your working directory is {{cwd}}. Your bash tool runs under a file sandbox — a `[sandbox: file access denied …]` result is policy, not a command bug.
Verify your work by running the code or tests. Keep answers brief and factual.