Context
ZCode 0.16.9 (macOS arm64), driving the ZCode Protocol app-server (and --prompt) headlessly from a local automation pipeline: sessions created via session/create {workspace}, prompts via session/send {modelSelection, content}, with the embedding client answering session/requestRuntimePreferences and brokering every interaction/requestPermission.
What's missing
There is no way to fence a headless session's tool set per session:
- No deny/allow channel:
session/create accepts no tool configuration; the settings-object permission channel (permission.disallowedTools) is not reachable per session; /model-style TUI commands don't exist headless; there is no equivalent of a --disallowedTools/--strict-mcp-config flag for the protocol.
- Low-risk built-ins auto-run in every mode, with no rule consultation: measured live, in build/plan/yolo alike — the model can
Read arbitrary local files, run safe-classified Bash commands (e.g. cat), and call WebSearch (query strings leave the machine) without a permission request ever reaching the client. The broker only ever sees side-effect-classified calls (Write, Edit, destructive/network Bash, WebFetch, MCP tools).
permissionUpdates rules don't persist for an untrusted temp workspace (added rules never apply to later calls in the same session), so the request/response channel can't bootstrap a fence either.
Why it matters
Unattended automation that feeds untrusted text (session transcripts, archived logs) into a headless model child currently has to accept that a prompt-injected instruction can make the child read local files (credentials in dotfiles) and emit web-search queries, with no protocol-level way to prevent it. Filesystem-level guards and output validation mitigate, but the clean fix is the engine's.
Request
A per-session tool fence on the protocol surface, e.g.:
session/create accepting {tools: {allowed: [...], disallowed: [...]}} (built-ins + MCP tool names), enforced before the risk classifier; and/or- making
permissionUpdates rules apply within the session that returned them (session-scoped persistence), and consulted even for low-risk-classified tools when an explicit rule exists.
Happy to share the probe scripts (a minimal python driver that reproduces each auto-run class and the broker behavior) if useful.
Context
ZCode 0.16.9 (macOS arm64), driving the ZCode Protocol app-server (and
--prompt) headlessly from a local automation pipeline: sessions created viasession/create {workspace}, prompts viasession/send {modelSelection, content}, with the embedding client answeringsession/requestRuntimePreferencesand brokering everyinteraction/requestPermission.What's missing
There is no way to fence a headless session's tool set per session:
session/createaccepts no tool configuration; the settings-object permission channel (permission.disallowedTools) is not reachable per session;/model-style TUI commands don't exist headless; there is no equivalent of a--disallowedTools/--strict-mcp-configflag for the protocol.Readarbitrary local files, run safe-classifiedBashcommands (e.g.cat), and callWebSearch(query strings leave the machine) without a permission request ever reaching the client. The broker only ever sees side-effect-classified calls (Write,Edit, destructive/networkBash,WebFetch, MCP tools).permissionUpdatesrules don't persist for an untrusted temp workspace (added rules never apply to later calls in the same session), so the request/response channel can't bootstrap a fence either.Why it matters
Unattended automation that feeds untrusted text (session transcripts, archived logs) into a headless model child currently has to accept that a prompt-injected instruction can make the child read local files (credentials in dotfiles) and emit web-search queries, with no protocol-level way to prevent it. Filesystem-level guards and output validation mitigate, but the clean fix is the engine's.
Request
A per-session tool fence on the protocol surface, e.g.:
session/createaccepting{tools: {allowed: [...], disallowed: [...]}}(built-ins + MCP tool names), enforced before the risk classifier; and/orpermissionUpdatesrules apply within the session that returned them (session-scoped persistence), and consulted even for low-risk-classified tools when an explicit rule exists.Happy to share the probe scripts (a minimal python driver that reproduces each auto-run class and the broker behavior) if useful.