Development record
2026-10-17 — Refines dcn-2610170739186543: an approved command runs under bash, because the guard reads every command in bash's grammar, so the command it judged is the command that runs. The approval hands back cd -- '<dir>' && exec /bin/bash --noprofile --norc -c '<command>', the command one single-quoted word, so the person's login shell, zsh or bash, only changes directory and, when that succeeds, starts bash, with its profile and rc files switched off. A construct only zsh gives a meaning to (glob qualifiers, (:A) modifiers, { … } always { … }) is a syntax error to bash, and bash runs nothing of that line. The check of the text handed back reads it with the guard's own parse and approves it only when it is exactly that change of directory joined by && to that one bash call, with the whole command as its last word and nothing else, refused as tree-group-broken otherwise. It no longer reads the command's own groups, ifs, loops and cases, since nothing in the single-quoted word can end it early: a } or a fi with nothing open is bash's syntax error inside the working tree, not a refusal. The refusal of a command where an unquoted ( stands in a word, and the reading of a quoted } as a command's name, stay as a second layer.
2026-10-17 — Refines dcn-2610170739186543: an approved command runs under bash, because the guard reads every command in bash's grammar, so the command it judged is the command that runs. The approval hands back cd -- '<dir>' && exec /bin/bash --noprofile --norc -c '<command>', the command one single-quoted word, so the person's login shell, zsh or bash, only changes directory and, when that succeeds, starts bash, with its profile and rc files switched off. A construct only zsh gives a meaning to (glob qualifiers, (:A) modifiers, { … } always { … }) is a syntax error to bash, and bash runs nothing of that line. The check of the text handed back reads it with the guard's own parse and approves it only when it is exactly that change of directory joined by && to that one bash call, with the whole command as its last word and nothing else, refused as tree-group-broken otherwise. It no longer reads the command's own groups, ifs, loops and cases, since nothing in the single-quoted word can end it early: a } or a fi with nothing open is bash's syntax error inside the working tree, not a refusal. The refusal of a command where an unquoted ( stands in a word, and the reading of a quoted } as a command's name, stay as a second layer.
Frontmatter
| id | dcn-2610170805446355 |
|---|---|
| type | decision |
| date | 2026-10-17 |
.abcd/work/decisions/dcn-2610170805446355-refines-dcn-2610170739186543-an-approved.md
open on GitHub ↗ · commit history ↗
mentions2
- dcn-26101707391865432026-10-17 — Refines dcn-2610170726383253: a command where an unquoted ( stands in a word, glued to it or opening one after the command's name, is refused whole as one whose targets the line does not fix, whatever the command is, not only for the targets the guard reads. The words after the ( are not read as the command's own, so a flag there that makes it write (sed x(.) -i, cp a(.) -t dir) is not seen, and zsh may read the ( as glob qualifiers or modifiers that change the path a word names (echo hi(:A), ls x(/) are refused too). bash refuses every such line as a syntax error, so nothing a bash user runs is lost. A function definition's () after its name (f() { … }, f () { … }, function f() { … }) is not such a word and stays allowed, as does a quoted or escaped (.
- dcn-26101709370008592026-10-17 — Refines dcn-2610170805446355: the text an approval hands back is cd -- '<dir>' && /bin/bash --noprofile --norc -p -c '<command>'. It drops exec, because the host joins its own text after the approved one (&& pwd -P >| <file>, its record of the shell's working directory), which must still run, and exec guards nothing the agent controls. It adds -p after the long options, since bash 3.2 refuses a long option after a short one, so bash ignores BASH_ENV, functions exported as BASH_FUNC_* and SHELLOPTS from the environment, and the approved command runs under /bin/bash with its profile, rc and environment start-up files ignored. The check of the text handed back accepts exactly that shape and nothing else. And a command holding a NUL byte is refused under the new id command-holds-nul before the guard reads it, since the guard's reading removes a NUL before it reads a word, so the command it would judge is not the one sent.