Assistant v0.6.18 — a failed command is not a successful receipt
The latest assistant release closes the gap between what a tool did and what governance recorded: explicit outcomes, fail-closed subagents, and real sandbox enforcement for custom commands.
The most dangerous bug in an agent runtime is not always a crash. It is a quiet mismatch: the tool fails, but the receipt says it ran. A timeout becomes a normal string. A killed process becomes a completed action. Governance is still green because it is reporting the shape of the response instead of the outcome.
Assistant v0.6.18 is a release about making that mismatch harder to produce.
Outcomes are explicit now
Tool and governance results carry machine-readable outcomes. A run can be successful, refused, failed, timed out, or killed. The status field remains compatible with replay, while the outcome tells the operator what actually happened. Contradictory success/error states are rejected instead of being silently normalized into a cheerful receipt.
That distinction is especially important for a local agent. A failed shell command should not become a successful assistant turn just because its error text was returned as a string.
Custom commands finally use the sandbox seam
Custom TOOL.md commands were not going through the same execution boundary as the built-in tools. They could miss the write budget, resource limits, scrubbed environment, and workspace confinement that the rest of the runtime expected.
In 0.6.18, both custom-command wrappers execute through SandboxBackend.run(). The command receives the configured output and write budgets, and the declared timeout remains the wall-clock limit. Signal deaths are recognized as failures, including the 128+n status shape used when a child in a shell pipeline is killed.
The write budget is also its own number now. RLIMIT_FSIZE is no longer derived indirectly from output capture; it defaults to 64 MB and can be configured with shell_tool.max_write_mb or SHELL_TOOL_MAX_WRITE_MB. That prevents a larger stdout allowance from silently turning into a larger file-write allowance.
Subagents fail closed
A subagent launch now fails when a declared tool or skill is missing, disabled, denied, or approval-gated. Each run receives a frozen capability manifest and a requested workspace. Completion delivery is idempotent, with a shared per-user drain lock so concurrent workspace coordinators do not publish the same terminal notification twice.
These are not glamorous changes. They are the changes that make an agent dependable after the demo is over.
The assistant source carries the full changelog and test counts. The assistant page shows the product surface; the release is underneath it.