The post has been translated automatically. Original language: Russian
The open Agent for Goose developers has received two versions in a row: 1.49.0 was released on September 3, 2026, and 1.50.0 was released on September 8. If 1.49.0 was mainly about convenience (auto-updating a desktop application, builds for Linux ARM64, background loading of extensions, built-in web search and browser skills), then 1.50.0 almost entirely consists of edits to the access model: which of the agent's sessions has the right to call, what a person sees before confirmation, and how the issued data is stored. and revoked permissions.
Delegated sessions are no longer equal to user sessions
The main change in 1.50.0 is the differentiation of rights between the main session and the subagents. Now changes in the extension manager are authorized by the caller's saved session, and the delegated session cannot create an equal user session through the orchestrator. The path through message passing is also closed: previously, a delegated session could send a message to a user session and thus reach privileged tools. Now the recipients are limited to sibling sessions in the same saved delegation chain, and if the session of the calling party could not be resolved, the operation fails. At the same time, only state—altering tools are hidden - detection and normal interaction remain available.
Revocation of permissions is going through a process race
The second edit concerns the permissions file. If the user has several agent processes running at the same time, the old process with its copy of the permission card could return an earlier state to the disk at the next write, that is, cancel the revocation of rights that had already been made. Now map changes are serialized between processes through an adjacent file lock: under the lock, the current state is re-read from disk, the permissions file is replaced atomically, and symbolic links to it are saved. The authors honestly define the boundary: the edit does not touch the live reading caches in already running processes, it only prevents the outdated writer from making his snapshot long-term.
What is visible before confirming the tool
The third edit is about the approval interface on the command line. The full tool confirmation request is now brought to the place where the person makes the decision, and the name of the tool and its arguments are shown without truncation and with the terminal control sequences being escaped. The difference is practical: previously, a long delegated command was approved, seeing only its beginning. In the same row is the edit of session naming.: The definition of the header by a "magic substring" has been replaced with an explicit provider capability that only a trusted naming pipeline uses. Also in 1.50.0, encryption became mandatory for connections with Snowflake, and the refusal to capture the contents of messages in telemetry is now respected for outdated trace field names.
What does this mean in practice?
When updating, I would pay attention to two places. First— a separate "fast model" has disappeared: session naming, tool call labels, chain summaries, context consolidation, and orchestrator digests now go through the main session model, with reasoning disabled and writing to the cache of promptos. The environment variable for the fast model, the rollback mechanism, and the provider's metadata have been removed, so that configurations where a cheaper model was installed for business operations will start counting them at the basic rate — the expense should be rechecked during the first sessions. Secondly, the agent communication protocol client and its executable file have been released in separate npm packages; installation scripts designed for a single package will have to be corrected.
The file lock edit is reminiscent of a typical error of single-process tools: a configuration file that is read into memory and completely overwritten turns into a record-loss race when the second process appears.
The draft text was prepared with the participation of AI, the facts were checked against the original source — official notes for Goose releases 1.49.0 and 1.50.0 and descriptions of the corresponding pool requests of the project.
Открытый агент для разработчиков Goose получил две версии подряд: 1.49.0 вышла 3 сентября 2026 года, 1.50.0 — 8 сентября. Если 1.49.0 была в основном про удобство (автообновление настольного приложения, сборки для Linux ARM64, фоновая загрузка расширений, встроенные навыки веб-поиска и работы с браузером), то 1.50.0 почти целиком состоит из правок модели доступа: кто из сессий агента что имеет право вызывать, что видит человек перед подтверждением и как хранятся выданные и отозванные разрешения.
Делегированные сессии больше не равны пользовательским
Главное изменение 1.50.0 — разграничение прав между основной сессией и подагентами. Теперь изменения в менеджере расширений авторизуются по сохранённой сессии вызывающей стороны, а делегированная сессия не может через оркестратор создать равноправную пользовательскую сессию. Закрыт и путь через передачу сообщений: раньше делегированная сессия могла отправить сообщение пользовательской сессии и так дотянуться до привилегированных инструментов. Теперь адресаты ограничены сессиями-братьями в той же сохранённой цепочке делегирования, а если сессию вызывающей стороны разрешить не удалось, операция завершается отказом. При этом скрываются только изменяющие состояние инструменты — обнаружение и обычное взаимодействие остаются доступными.
Отзыв разрешений переживает гонку процессов
Вторая правка касается файла разрешений. Если у пользователя одновременно работают несколько процессов агента, старый процесс со своей копией карты разрешений мог при очередной записи вернуть на диск более раннее состояние — то есть отменить уже сделанный отзыв прав. Теперь изменения карты сериализуются между процессами через соседний файловый замок: под замком актуальное состояние перечитывается с диска, файл разрешений заменяется атомарно, символические ссылки на него сохраняются. Авторы честно оговаривают границу: живые кеши чтения в уже запущенных процессах правка не трогает, она лишь не даёт устаревшему писателю сделать свой снимок долговременным.
Что видно перед подтверждением инструмента
Третья правка — про интерфейс одобрения в командной строке. Полный запрос подтверждения инструмента теперь доводится до места, где человек принимает решение, а имя инструмента и его аргументы показываются без усечения и с экранированием управляющих последовательностей терминала. Разница практическая: раньше длинную делегированную команду одобряли, видя лишь её начало. В том же ряду — правка именования сессий: определение заголовка по «магической подстроке» заменено на явную возможность провайдера, которую использует только доверенный конвейер именования. Также в 1.50.0 стало обязательным шифрование для соединений со Snowflake, а отказ от захвата содержимого сообщений в телеметрии теперь соблюдается и для устаревших имён полей трассировки.
Что это значит на практике
При обновлении я бы обратил внимание на два места. Первое — исчезла отдельная «быстрая модель»: именование сессий, метки вызовов инструментов, сводки цепочек, уплотнение контекста и дайджесты оркестратора теперь идут через основную модель сессии, с отключёнными рассуждениями и записью в кеш промптов. Переменная окружения для быстрой модели, механизм отката и метаданные провайдера удалены, так что конфигурации, где на служебные операции ставили модель подешевле, начнут считать их по основному тарифу — расход стоит перепроверить на первых сессиях. Второе — клиент протокола общения агентов и его исполняемый файл выехали в отдельные пакеты npm; сценарии установки, рассчитанные на единый пакет, придётся поправить.
Правка с файловым замком напоминает про типичную ошибку однопроцессных по происхождению инструментов: конфигурационный файл, который читается в память и целиком перезаписывается, при появлении второго процесса превращается в гонку с потерей записей.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальные заметки к релизам Goose 1.49.0 и 1.50.0 и описания соответствующих пул-реквестов проекта.
Share
