Development record
an interactive cp prompt stalls an agent silently and has now cost three sessions time in one day
an interactive cp prompt stalls an agent silently and has now cost three sessions time in one day
cp is aliased to an interactive form on this machine, so a bare cp over an
existing file prints an overwrite prompt and waits. An agent has no terminal to
answer it with, so the command does not fail: it HANGS, and the agent sits on it
until something else kills the session.
Three incidents on 2026-08-30 alone:
- a sibling agent lost its job to it while restoring a mutated file (recorded in the act log at the time the itd-193 hazard was found);
- a reviewer stalled roughly sixty-eight minutes on
cp -fAFTER its test run had finished, so the work was done and only the reporting was lost; - the orchestrator hit it directly while staging a probe, and recovered only because the failure was in the foreground.
What makes it worth a record rather than a note is the SHAPE. It is silent, it
strikes at the end of a task rather than the start, and the mitigation is one
character: use cat src > dst, or command cp, or an explicit /bin/cp. Every
agent brief this session has carried the warning as boilerplate, which is the
signal that it should live in the record instead of being retyped: a lesson
whose why is a correction any agent should receive belongs in the committed
record, not in one session's prompts.
Related but distinct from itd-193. That discipline says a verifier works on a copy; this says the ordinary way of making that copy is booby-trapped on this machine. The two travel together: itd-193 sends every reviewer to copy files, which is exactly the operation this hazard sits on.
Adjacent to iss-2608291444328326, the account-name collision, as the second environmental hazard of the same kind: a machine-local property that silently breaks an otherwise correct instruction.
Remedy grounds (2026-09-29)
- The rules loader is the committed home memory-graduates-to-record names for abcd itself, and three stalls in one day meet its twice-recalled promotion signal; an rm alias of the same shape stalls the same way, so the domain can carry both lines.
- No outside-practice check: the hazard is a property of one machine's shell configuration.
- Rejected: a guard-registry entry, since the guard refuses destructive commands and a prompt that stalls is not one.
Frontmatter
| id | iss-2608301715040589 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2608301715040589-an-interactive-cp-prompt-stalls-an-agent.md
open on GitHub ↗ · commit history ↗
mentions3
- iss-2608291444328326The launch payload's `local_username` identity rule takes the username from the last segment of HOME and hard-fails every case-insensitive occurrence of it in the payload. On a machine whose account name is an ordinary word that is also product vocabulary (an account named with the same three-letter word as the `ahoy install` track-latest flag and the "-shim" install mode it names, which appears in commands/ahoy.md, commands/update.md, commands/launch.md and docs/reference/cli/commands.md), `TestPayloadTreeImplementationsResolveIdentically` and `TestRenderPayloadLeavesSourceTreeUnversioned` fail on a pristine main (9 hard-fail findings at e6efe28f), and with them `make preflight` and the pre-push hook, so the v0.6.8 release branch could not be pushed from that machine until HOME was pointed at a symlink alias of the real home directory for the push. CI, which runs under a different account name, passes.
- iss-2608301844363341a formatter hook substitutes smart quotes into edited source comments which passes gofmt and every gate and is visible only in a diff
- itd-193A verifier works on a copy: no agent mutates a live worktree to test it, and the tree is proved clean before any act that reads it