99650a201b
A ModeDefinition may declare access: the widest sandbox access shell commands run under while the mode holds, on the SANDBOX_MODES ladder. The bash seam gains the resolution point to hang it on: BashExecutor. resolveMode(session) folds override ?? default and dispatches the new bash/resolve-mode waterfall; dsh-tool-bash consults it at both the stamping site and the escalation baseline; dsh-mode's clamp listener takes the ladder minimum per call. Two independent log folds compose at read time — the mode never writes the sandbox knob, so the two switch in any order and the knob re-emerges intact on exit. The built-in plan definition ships access: read-only with the bash trio allowlisted CONDITIONALLY: both policy layers admit bash/bash_output/ bash_kill only while a confining executor is mounted (an unconfinable shell cannot honor the cap), and a bash call carrying sandbox_permissions under a cap is denied at the gate — no widening mid-mode; the widened step belongs in the plan. examples/plan-acp-agent swaps bash-local for sandbox-local + bash-sandbox (workspace-write default, clamped read-only inside plan) plus the approval seam; the re-recorded plan-mode arc runs a real cat inside plan under the clamped sandbox, and modes-advertise now pins the sandbox-mode and approval config options. RFC amended to the landed shape (access cap section, orthogonality FAQ, deferred item resolved into effects self-declaration).
@deepseek-ai/dsh-tool-cordis
The self-referential cordis toolset: three model-facing tools over the live runtime the agent runs inside. Design home — sandbox semantics, mount lifecycle, cross-mount composition, the generated API catalog, standing decisions: the toolset RFC.
What it does
cordis_inspect— read-only report over the runtime: services, the loaded-plugin list, registered tools, the dynamic-mount table, and the catalog-backedapi/eventsreferences.cordis_mount— evaluates model-written JavaScript (the body of an async function) in anode:vmsandbox; the code mustreturna cordis plugin, which is mounted under thecordis-dynamicgroup fiber and tracked asdyn-<n>.cordis_unmount— disposes one mount by id, returning only after quiescence.
Exact model-facing schemas: the generated tool catalog.
Trust stance
The sandbox isolates the global context only — it is not a security boundary. No Node API is provided: require, the timers, and fetch are callable traps that throw a redirect to the cordis alternative (ctx.fs / ctx.web / ctx.bash / inject: ['timer'] + ctx.setTimeout); process and Buffer are undefined; globalThis writes stay inside. These traps steer honest code onto the cordis services; they do not contain a mount that goes looking — the host-realm helpers on the sandbox global (harness, console, btoa) are reachable functions, so mount code can reach the host realm and Node through one of them, which is fine because ctx is fully privileged anyway. The ctx a mounted plugin's apply receives is a whitelist façade — register tools, observe events, provide/consume services, use timers; framework internals (ctx.root, ctx.fiber, ctx.extend, ctx.plugin, …) are withheld — but the capabilities it does expose reach the real runtime, so load this plugin as deliberately as you would grant a bash tool.
Config
| Field | Default | Meaning |
|---|---|---|
vmTimeoutMs |
5000 |
Bound on the SYNCHRONOUS portion of mount-code evaluation; an async body escapes it |
The generated API catalog
src/api-catalog.ts is generated by scripts/gen-cordis-api.ts from the same AST walk as docs/cordis-catalog and freshness-gated by pnpm run verify-cordis-api (in doc-sync) — never edit it by hand. cordis_inspect intersects it with the live service store at call time.
Rendering
All three tools render generic cards (read / execute / delete); cordis_mount carries the mount code as rawInput. Presenters are pure functions of the args; results keep the default text rendering.
Export shape
Namespace plugin: named exports name / inject / Config / apply, no default export (docs/postmortem/0001).