PTY автоматизацията на разрешения изисква граници на контекст, избор и повторение
Интерактивните CLI агенти често спират върху prompt за разрешение, но автоматичното потвърждение може да бъде опасно, ако разпознае обикновено меню като одобрение. Този workspace-синтез разглежда еднофайловия инструмент claude-auto-yes, предишното му agent guide описание и локален smoke check чрез Python компилация и help изход. Анализът показва, че безопасната автоматизация не е свойство на PTY сам по себе си, а на верига от доказателства: нормализация на екрана, контекст на разрешение, yes/no алтернатива, fingerprint дедупликация, наблюдение на background сесии, dry-run режим и guardrail за maintenance команди. Приносът е модел Permission Prompt Accountability Chain, който разделя твърдението "автоматично одобрява" от по-слабото и по-точно твърдение "отговаря само когато контекстът, изборът и повторението са проверими".
Въведение
Автоматичното избиране на разрешение в терминал изглежда малка ергономична функция, но практическата опасност е асиметрична: вярно разпознатият prompt пести време, а грешно разпознатото меню може да одобри действие, което операторът не е видял. Инспектираният инструмент е полезен именно защото не третира PTY като достатъчно доказателство. [[cite:cay_src_regex,cay_src_selector]]
Основният gap е между "има wrapper, който може да пише в PTY" и "има проверима политика кога е позволено да пише". Предишният graph guide вече описва project map и правила за промени; тази статия добавя модел за stage-bound публична претенция. [[cite:cay_src_agentwatch]]
Това фокусира изследователския въпрос върху границата на claim-а, а не върху удобството. Дори когато операторът лично иска автоматизация, публичният отчет трябва да различава detection, consent, execution и auditability.
Метод
Методът е концептуален synthesis върху source slices, graph item и локален smoke check. Кодирахме всеки източник по ролята му: входен екран, избор, повторение, background сесия, операторски контрол и отрицателни доказателства. [[cite:cay_src_cli,cay_graph_guide]]
Не е провеждан live approval експеримент. Това ограничение е съзнателно: целта е да се определи каква evidence chain трябва да съпътства такъв експеримент, преди публично да се твърди безопасна автоматизация.
Кодиращата схема постави по-висока тежест върху отрицателните случаи: unrelated menu, repaint, missing no option, changed JSON schema и maintenance invocation. Така проверката не пита само "може ли да отговори", а "кога трябва да откаже".
Резултати
Първият резултат е, че detection boundary е по-силен от обикновено търсене на "yes". Кодът нормализира екрана, извлича номерирани избори, проверява yes-подобен избран етикет и търси контекст за разрешение. [[cite:cay_src_regex,cay_smoke_compile]]
Вторият резултат е, че повторението е отделен failure mode. AutoSelector пази fingerprint-и, изчиства буфера след отговор и има resend threshold. Това намалява риска от многократно писане при repaint, но не замества fixture тестове. [[cite:cay_src_pty,cay_src_hidden]]
Третият резултат е операторски: dry-run е наличен, foreground auto-answering е изключен по подразбиране, а maintenance команди изключват background watcher. Локалният smoke check показа синтактично валиден файл и CLI help, но не доказа поведение върху реални prompt-и. [[cite:cay_src_waits]]
Фигурата кодира равномерно силни слоеве за контекст, избор, дедупликация, watcher и dry-run, но по-нисък слой за тестове. Това е ключово: отчетът не наказва проекта за наличието на риск, а прави риска измерим и видим.
Модел на отчетност
Permission Prompt Accountability Chain има шест етапа: clean screen, permission context, yes/no choice, dedupe, bounded session attach и operator dry-run. Публичното твърдение трябва да показва най-слабия доказан етап, а не да използва общата дума "auto-yes".
Практическото следствие е промяна в документацията. Вместо "автоматично казва yes", по-точното описание е "автоматично изпраща конфигуриран отговор само след permission-like контекст, yes-like избор и repeat guard, при налични режими за наблюдение".
Ограничения и пренос на твърдения
Най-важното ограничение е липсата на inspect-нати fixture тестове за unrelated менюта, ANSI-wrapped prompt-и и nested JSON session rows. Smoke check доказва синтаксис и интерфейс, но не доказва false-positive rate. [[cite:cay_smoke_compile,cay_src_waits]]
Второ, background сесиите зависят от външен CLI JSON договор. Ако бъде променен, watcher-ът може да стане сляп или прекалено широк. Затова веригата изисква тестове върху примерни payload-и и ясна политика за логиране без секрети.
Тези ограничения не обезсмислят инструмента; те определят следващия експеримент. Минималният следващ набор трябва да съдържа screen fixtures, nested agent JSON fixtures и dry-run transcript без чувствителни данни.
Заключение
Автоматичното одобрение е приемливо само като narrowly-scoped consent parser. За claude-auto-yes най-точното публично твърдение е, че workspace-ът съдържа силни предпазни слоеве и преминава евтин smoke check, но пълното safety claim изисква fixture тестове за отрицателни менюта и промени в agent JSON формата.
Следователно приносът е калибриране: проектът не трябва да се описва нито като опасна безконтролна автоматизация, нито като доказано безопасна система, а като инструмент с ясна evidence ladder за следваща проверка.
За подобни инструменти препоръката е всяка нова функция да добавя двойка тестове: един положителен prompt, който трябва да бъде разпознат, и един визуално сходен отрицателен екран, който трябва да бъде отхвърлен. Само така safety story остава поддържана, когато терминалният UI, външният CLI или формата на background session metadata се променят.
Бъдеща проверка
Бъдещата проверка трябва да започне с малки, публично безопасни fixture-и, а не с live terminal записи. Това позволява regression тестове без публикуване на raw prompt, shell history или частни директории. Всеки fixture трябва да носи очакване: answer, no-answer или parse-only.
След това може да се проведе bounded live dry-run, в който инструментът наблюдава реални prompt-и, но не пише отговор. Ако dry-run metadata остане чиста от секрети и отрицателните fixture-и продължат да минават, claim-ът може да се повиши от source-inspected към behavior-observed.