Until we hit v1.x.x, only the latest minor version is supported.

By default (toolExec: "worker", docs/config-reference.md) the tools tagged for the execution plane -- today bash, read, grep -- run in pooled out-of-process executors, not inside the agent process:

• Tool crashes are events, not process deaths.
• Provider keys and websocket auth secrets never enter the tool plane (env is scrubbed at the broker spawn; the config files are not mounted into the jail). envScrubbing: false is honored plane-wide: that opt-out hands the broker -- and through it every pool entry -- the full environment copy, so the "keys never enter" property is exactly as switched-off as it is inline.
• Session-log records are physically unwritable by tool-executed code when the fence is up and the sessions directory lives outside the workspace roots. With the fence down (toolExec: "inline", a failed probe) or a sessions dir inside a jail's rw roots, the records are ordinary files and only the workspace checks stand between tool code and them.
• Workspace roots and deny patterns become OS-enforced for tagged tools where the platform fence works (execFence: "probe"): on Linux with bubblewrap, each entry gets a fresh tmpfs root with read-only system dirs and read-write ONLY the session's workspace roots, inside its own PID/IPC/UTS namespaces (jailed code sees and can signal no host process). On macOS with seatbelt (sandbox-exec), each entry gets an allowlist profile: read-only system dirs, read-write ONLY the session's workspace roots plus its scratch dir, network shared -- strictly weaker than bwrap (see the list below). Both: no $HOME, no config chain, no sibling session roots. hotdog info reports the posture (fence: bwrap, fence: seatbelt, off, or none -- probe failed); the plane never fails open silently. The posture is runtime-toggleable by the operator (/fence on|off in the interactive CLI, or a click on the webui's header posture strip, both per session and never persisted): the toggle applies to the named session only -- other sessions and future subagent sessions follow the boot policy -- and every change is recorded as a logged transcript notice in that session's log. The webui control acts on the client's ATTACHED session behind the same authorization as the other session-scoped websocket controls (an authenticated socket on an accepted origin, the frame naming a live session of this server), and switching a session off requires an explicit confirm naming the UNFENCED consequence.
• Per-session jails: cross-workspace reads via bash are structurally impossible for tagged tools when the fence is up.

What the plane does NOT buy:

• Prompt-injection defense (the marker mangler and spoof neutralizer, unchanged).
• In-fence abuse: deleting the workspace, egress over the permitted network, or exfiltration through the model channel itself.
• Allowlist quality is policy: anything bound into the jail is readable.
• toolExec: "inline" or a failed probe: the plane is pooled but unfenced, and says so. The general advice stands -- a dedicated host, VM, or container is recommended.
• macOS seatbelt is weaker than bubblewrap by construction: there are no PID/IPC/UTS namespaces, so host pids remain visible and sysctl-read (granted; bun and libc need it) leaks process info. The profile denies process-signal explicitly, so jailed code cannot kill or signal host processes, but process-info secrecy is not the equivalent of a private namespace. /usr/bin/sandbox-exec is a deprecated Apple shim: the backend is probe-guarded (two legs prove mediation is live before any fence is claimed), and its disappearance means pooled-but-unfenced, reported loudly, never silent.
• Windows has no jail backend: pooled but unfenced there, and the status line says so.

Disclosure shift: for tagged tools behind a working fence, the workspace/deny guarantee moves from advisory to enforced. A jail or plane escape is a reportable vulnerability under this policy.

Report any discovered vulnerability to devoidfury at hotdog.agent.hotline@gmail.com or via furycodes.com. I will acknowledge your report within a week, review the issue, and then either reject or accept the report. If accepted I'll prioritize getting this fixed, released, and announced as soon as possible, with your credit in the release notes.