Development record
Agents stall at the host's permission prompt when they write a command the host cannot check. On 2026-10-16 a background agent ran a bash -c script built from variables that deleted files. The host could not check it, so it asked 'This shell -c script runs rm and could not be checked. Do you want to proceed?', and the agent waited for a person. No bundled rule teaches the forms the host can check.
issueresolvedminoriss-2610161612200864
Agents stall at the host's permission prompt when they write a command the host cannot check. On 2026-10-16 a background agent ran a bash -c script built from variables that deleted files. The host could not check it, so it asked 'This shell -c script runs rm and could not be checked. Do you want to proceed?', and the agent waited for a person. No bundled rule teaches the forms the host can check.
Grounds
- pursued: an agent told why and how to rewrite a variable-built -c delete before it runs stops writing commands a host must ask a person about; a host prompt on a -c delete an agent wrote after this rule was taught would show it wrong
Frontmatter
| id | iss-2610161612200864 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2610161612200864-agents-stall-at-the-host-s-permission.md
open on GitHub ↗ · commit history ↗
mentions3
- dcn-26101616122696472026-10-16 — Agents keep running past the host's permission prompts in two ways (product thinker, 2026-10-16): abcd teaches agents the command forms the host can check (iss-2610161612200864), and, for the agents abcd itself starts without a terminal, abcd answers the prompts per launch with its guard rules (iss-2610161612203555). abcd does not approve commands in interactive sessions, does not sandbox, and never edits the person's host settings.
- dcn-26101616210286132026-10-16 — The product thinker changed the brief for iss-2610161612200864 from teaching alone to teaching and enforcement: the guard refuses a bash -c or sh -c script built from variables that runs rm, rmdir, unlink or shred, and the refusal says how to rewrite it (write the script to a file in one command and run it in the next; delete with literal paths through /bin/rm -f --, or a variable guarded as "${VAR:?}", outside the -c string), rather than warning. The agent gets the reason back and rewrites the command before the host would stop to ask a person. Only that shape is refused: a -c script with no deleting command, or one with no variable in it, still passes.
- dcn-26101616210880502026-10-16 — The refusal of a bash -c or sh -c script built from variables that deletes (iss-2610161612200864) is read in code beside the payload reading, under the reserved id shell-c-variable-delete, and its SHELL rule is generated beside it, as the script reading's is (guard.ScriptLesson). Not a registry entry: the pattern language matches one command's words, and cannot say a -c string that holds a variable and a deleting command. Not a hand-written rule in defaults/rules.json: SHELL may not be declared there, and a new domain would be a second copy of the refusal's words, free to drift. Where the refusal and rm-unguarded-variable-path fire on the same line, the refusal speaks, because its rewrite includes that entry's; every other blocker keeps its own message.