dsh-shell-select

LIMITATIONS

Known limitations

**No `<shell>` executable found.** The plugin looked for the shell by name and found nothing. Install it, or set `executable` to its full path. The error lists every location that was probed. **Refused under the current permission mode.** The selected shell cannot be confined by the sandbox the session resolved. On Windows this is expected for Git Bash and WSL Bash under `workspace-write` and `read-only`. The refusal names the shell and the mode; pick a shell the mode can confine. **Automatic shows *unknown*.** You have staged an `executable` path that the host has not resolved yet. Automatic is resolved from the saved selection, so save the path and the card will name the shell it picks. **Test shell reports a refusal or the wrong shell.** Test runs the *saved* selection. If you have staged edits, save them first, or discard them. **`cmd` quirks.** The command reaches `cmd.exe` in one pass, so a `%NAME%` in your command stays literal; write `call echo %CD%` when you need expansion. Non-ASCII output depends on the console code page, so it can arrive as replacement characters. Unicode paths and filenames are unaffected. **Routes the selector does not control.** Agent commands go through the selected shell, but `run_code` program bodies, PTY-based terminal tools, and out-of-process subagents spawn their own processes. The full list, with reasons, is in [architecture.md](docs/architecture.md#execution-routes-covered-and-not-covered). Shell selection is not destructive-command protection. The sandbox restricts write-class access according to the session's permission mode; this plugin adds no destructive-command detection and is not a safety layer. The other known limitations are listed in [testing.md](docs/testing.md#known-limitations).