_KermanandTianyi Cui
fb79a944f5
Give durable user context its producer-owned source kind instead of a generic plugin wrapper. The V3-to-V4 conversion preserves the frozen rename and collision rules, all own JSON metadata, event coordinates, and historical request-only kinds. Native catalog and JSONL admission retain source validation so unknown attribution can survive without its producer while malformed owned sources are refused. Use an explicit user-only RequestUserInput for auxiliary LLM prompts that do not own durable message identity. Auto Review and compaction remove their request-only source registrations while retaining prompt content and freezing; provider serializers and projections keep the same wire data, assistant replay isolation, image ordering, and tool correlation. Session writes, Agent delivery, and recorded title requests continue to require identified durable messages. Bind the saved compatibility policy only to user sources and qualify tmux location attribution without weakening fixed system, model, or tool semantics. Rebuild the current inventory and unpublished V4 acknowledgement on the actual tool-role parent, preserving its rationale and all accepted historical records. The catalog format version records tooling metadata; Session remains V4. Developer-role policy and activation belong to their own feature. The latest-master Messages adapter, serialization, request-input typing, EpochHeader reservation, and attribution checks pass 103 tests across five files. The retained V3 Messages input-history snapshot passes through the source profile; Host/Client typechecks and all 41 documentation gates pass. The generated comparison records four changed roots and 447 unchanged type fingerprints. Latest-master ARIA changes are retained, with producer source labels applied independently; new Messages fixtures retain their producer names as declared source kinds and use the fixed system-message helper; recorded Session generations are unchanged by this regrouping. 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.