isShellToolEnabled
isShellToolEnabled(
devTools,command?):boolean
Defined in: core/dist/config/shell-policy.d.ts:217
Normalize the GthDevToolsConfig.shell opt-in (bare boolean or
{ enabled }) to a plain boolean. Centralized so the toolkit (tool emission)
and the deep agent (interrupt wiring) agree on what “shell enabled” means.
EXT-12 / CFG-18 — default-resolution is enabled ?? default. An EXPLICIT enabled always wins
(a bare boolean, or the object form’s enabled), so shell: false / { enabled: false } remains
a hard escape hatch that fully disables the tool. When enabled is ABSENT — whether shell is
undefined OR an object that omits enabled (e.g. { timeout: 300000 }, i.e. a
{ "run_shell_command": { "timeout": 300000 } } registry entry) — the per-mode default applies:
ON in code mode (still gated — the per-command approval interrupt is wired separately and is NOT
bypassed by this), OFF everywhere else (exec, ask --write, …). This is the CFG-18 change from
the old enabled === true object semantics: configuring the shell no longer silently turns it off.
The default is code-mode only because code is the interactive agentic-coding surface where a
TTY can answer the approval prompt; the absent-config default never implies yolo.
Parameters
Section titled “Parameters”devTools
Section titled “devTools”GthDevToolsConfig | undefined
command?
Section titled “command?”The active command, so the absent-config default can be scoped to code.
Omit (or pass a non-code command) to keep the historical OFF-by-default behaviour.
Returns
Section titled “Returns”boolean