У Devin Desktop две линии - стабильная и отдельный preview Next, - и это не одна программа с галочкой "бета", а два разных состояния продукта. Спутать их - значит применять к одному то, что верно про другое, и потом искать несуществующий баг.

Наивный ход - считать, что раз это тот же Desktop, то и функции, и документация, и пути одинаковы, а Next - просто "чуть свежее". Из этого растёт привычка читать про функцию в одном месте и ожидать её в другом. Обобщение выглядит безобидным - в конце концов, приложение и правда одно, - но именно оно и приводит к тому, что приём из одной линии молча применяют в другой.

Ломается это на том, что у линий может различаться и документация, и registry path, и само поведение функций. То, что описано и работает в Next, не считается доступным в stable без отдельного подтверждения. Эта книга и вовсе фиксирует конкретный снимок - stable 3.7.16 - именно чтобы не смешивать: факт из preview не переносится в стабильную линию по умолчанию. Registry path здесь не деталь: если путь к каталогу расширений или к конфигурации в двух линиях разный, то и то, что вы туда положили, в другой линии просто не найдётся.

Профессиональный ход начинается с того, что обновление трактуют как управляемое событие, а не фоновое. Перед обновлением локальные задачи завершают или сохраняют. В 3.7.16 это подкреплено самим интерфейсом: "Restart to Update" спрашивает подтверждение, когда локальные агенты ещё работают, и сообщает, сколько их будет остановлено; cloud-сессии при этом продолжают работу. Разница неслучайна: локальный агент живёт в приложении и умрёт с рестартом, облачный исполняется в своей VM и переживёт его.

Понять это различие важнее, чем запомнить кнопку. Локальная сессия и приложение - одно целое: рестарт ради обновления обрывает её на середине, и предупреждение о числе агентов - это шанс не потерять работу. Cloud-сессия отвязана от вашего приложения, поэтому обновление Desktop её не касается. Одно и то же действие "обновиться" имеет для двух поверхностей разную цену, и интерфейс честно её показывает. Из этого следует простое правило: перед рестартом ради обновления смотрят не на версию, а на список активных локальных сессий, и решают их судьбу осознанно.

Для команды всё это перестаёт быть личным выбором. На production-репозиториях разумно закрепить один канал обновлений, договориться о коротком окне обновления и прогонять smoke test после него. Тогда все работают на одной известной версии, обновляются предсказуемо и ловят регресс сразу, а не через неделю в духе "почему у меня иначе". Разнобой версий в команде - это скрытая переменная, которая всплывает в самый неудобный момент. Закреплённый канал - это ещё и общий язык в баг-репортах: когда все на одной версии, фраза "у меня иначе" сразу указывает на конфигурацию, а не на разошедшиеся сборки.