Remote-разработка кажется просто тем же самым, но на другой машине. В агентной IDE это не так: когда код, конфиг, терминал и секреты живут на разных машинах, вопрос где именно исполняется действие перестаёт быть очевидным, а именно на этом вопросе держится вся безопасность агента.
Наивный ход - считать, что раз окно редактора одно, то и среда одна: permission, путь и команда работают там же, где вы смотрите на экран. Локальная интуиция переносится на remote автоматически и обычно незаметно - до первого расхождения, когда deny не срабатывает, а команда уходит не туда.
Ломается это на том, что место исполнения расходится с местом, где вы сидите. Devin Desktop несёт собственный Remote-SSH для Linux-хостов, и сторонние Microsoft Remote-SSH или open-remote-ssh могут с ним конфликтовать - два расширения борются за одну роль, и поведение становится непредсказуемым. Dev Containers работают с локальным и удалённым Docker и командами reopen, attach, logs. WSL помечен как beta. В каждом из этих случаев агент может действовать не на вашей машине.
Стоит развести эти сценарии, потому что у каждого своя механика. Remote-SSH переносит весь сеанс на Linux-хост, и встроенный клиент лучше держать один, без сторонних поверх него. Dev Containers дают воспроизводимое окружение в Docker: reopen открывает проект внутри контейнера, attach подключается к уже запущенному, logs показывает, что там происходит. WSL - beta-мост в Linux-подсистему Windows, удобный, но помеченный как ранний, и опираться на него как на стабильную основу процесса преждевременно. Знать, какой из трёх сценариев у вас, важнее, чем помнить их названия: от этого зависит, где искать файл, конфиг и сбой.
Ключевой сдвиг закреплён в изменениях: в stable 3.7.16 Codemaps и конфиг MCP открываются с удалённой машины для WSL, SSH и dev container. Значит, индекс кода и инструменты берутся оттуда, где живёт код, а не оттуда, где открыто окно. Это правильно по сути - агент видит настоящую файловую систему проекта, - но переворачивает наивную картину локальности, к которой вы привыкли.
Профессиональный механизм прост: до запуска агента составьте карту слоёв. Где лежит workspace, где конфиг, где процесс MCP, где терминал и где credentials. Пять ответов задают, на какой машине что произойдёт, и снимают большую часть будущих сюрпризов ещё до первого действия агента, а не после разбора, почему он сделал не то.
Почему это важнее, чем кажется. Permission-glob и исполняемые файлы могут разрешаться на remote-хосте, а не локально. Deny, написанный в расчёте на локальный путь, на удалённой машине может указывать в пустоту или в другое место. Граница безопасности следует за файловой системой, а файловая система теперь чужая - и правило, верное локально, на хосте способно молча не сработать, оставив открытым то, что вы считали закрытым.
Цена ложного предположения о локальности конкретна: команда, запущенная не там; deny, не сработавший на remote; секрет, продублированный в двух слоях и утёкший из менее защищённого. Последнее особенно коварно: один и тот же токен, положенный и локально, и на хосте, защищён по слабейшему из двух слоёв, а не по сильнейшему, и достаточно одной дыры, чтобы обесценить вторую защиту. Поэтому секрет держат в одном месте на один слой, а не размазывают между локальным и удалённым ради удобства.
Когда remote-слой оправдан. Тогда, когда код и его окружение действительно живут на хосте, в контейнере или в WSL: близость инструментов к коду важнее удобства локального окна, а воспроизводимость среды стоит своих накладных расходов. Если же проект локален, лишний remote-слой ничего не добавляет, кроме новых мест, где можно ошибиться, - и его стоит убрать, а не терпеть ради привычки.
Проверять стоит не память, а approval card. Перед подтверждением действия смотрите CWD в карточке - она называет реальный каталог и машину, на которой всё произойдёт. Убедитесь, что permission-glob покрывает именно ту файловую систему, где исполняется агент. Если работаете через сторонний Remote-SSH, проверьте, не конфликтует ли он со встроенным, и при конфликте оставьте один. Эти взгляды занимают секунды и снимают целый класс путаницы.
Типичный провал - держать один секрет в нескольких слоях; писать deny под локальный путь, а исполнять на remote; ставить сторонний Remote-SSH поверх встроенного и ловить конфликт; принимать WSL-beta за стабильную опору процесса. Признак один: про действие говорят так, будто оно исполнится где угодно одинаково. Назовите слой и посмотрите CWD - и разница, которую вы пропускали, станет видимой до, а не после действия.