_KermanandTianyi Cui
f4a32dbd0a
Represent tool results as tool-role messages and migrate released wrappers without losing outer own JSON fields, call identity, error state, or writer field order. Refuse nested or wrapper-only information that has no lossless current representation before successor publication. Validate current event relationships directly instead of projecting V4 data back into V3. Keep lifecycle, PTC, title/command, compaction, system-field and retired-syntax checks on catalog restoration and ordinary JSONL opens. The Worker JSON equality helper must inspect own keys so it cannot admit PTC arguments that Node rejects. Keep the source role change, required native admission and consumer fixture updates in one complete review layer. Explain shared-type changes in the persistence record and the native reader rationale in its existing note. Use checked branded fixture identities and discriminant narrowing instead of unknown double casts; fixture values and assertions remain intact. This recomposes the original tool-role work by _Kerman with the independently validated migration and admission repairs by Tianyi Cui. Frozen generations and snapshot input version selection are retained. Co-authored-by: Tianyi Cui <[email protected]>
description, kind
| description | kind |
|---|---|
| The bash capability family for deployments and maintainers choosing and composing a shell executor, sandboxing, and the model-facing bash and pwsh tools. | package-group |
shell/ — bash capability family
English | 中文
Summary
The shell group provides command execution to agents: run a foreground command and read its bounded output, or start a background process and poll it, on POSIX with Bash and on Windows with PowerShell. Exactly one executor implementation is mounted per composition; the sandboxing executors confine every command through the sandbox capability, and the model-facing bash and pwsh tools sit on top of whichever executor is mounted. Choose a Bash executor for POSIX, a PowerShell executor for Windows, and pick the sandboxing variant when commands need file-level confinement.
Table of Contents
Packages
| Package | Role | ctx key |
|---|---|---|
shell |
Defines the executor contract: foreground runs, background handles, and request resolution | ctx.shell |
bash-local |
Runs Bash commands as fresh bash -c processes on POSIX |
registers ctx.shell |
bash-sandbox |
Runs Bash commands confined through the sandbox capability, reporting denials as facts | registers ctx.shell |
pwsh-local |
Runs PowerShell commands as fresh pwsh -Command processes on Windows |
registers ctx.shell |
pwsh-sandbox |
Runs PowerShell commands confined through the sandbox capability | registers ctx.shell |
shell-env |
Supplies the managed DSH_* environment every shell command receives |
ctx.shellEnv |
tool-bash |
Exposes Bash execution and background jobs to the model as the bash tool |
registers on ctx.tools |
tool-bash-persistent |
Runs model shell calls in one owner-isolated persistent Bash session | registers on ctx.tools |
tool-pwsh |
Exposes PowerShell execution to the model as the pwsh tool |
registers on ctx.tools |
tool-pwsh-persistent |
Runs model shell calls in one owner-isolated persistent PowerShell session | registers on ctx.tools |
A profile layer selects exactly one executor implementation (the win32 layer swaps the POSIX rows for the pwsh ones; mounting two fails loudly at load time on the duplicate service registration) and the model-facing tools it needs. A sandboxed composition also selects a ctx.sandbox provider and ctx.sandboxPolicy; the base bundle owns the shipped wiring.
Related documentation
- Bash executor subsystem — the shared request/spec vocabulary, results, background processes, and the complete service contract.
- Sandbox subsystem — the confinement capability the sandboxing executors consume.
Dev Note
None.