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

Внешняя мутация - самое чувствительное, что дают эти интеграции, и к ней подходят осторожно. Создать или изменить issue, отправить сообщение, поменять состояние задачи - это действия с последствиями во внешней системе, а не безобидное чтение. Их подчиняют тем же принципам, что и любое side-effecting действие: подтверждение там, где нужно, узкие права, ясность в том, что именно и от чьего имени меняется. Безопасная внешняя мутация - это осознанно выданное узкое право, а не побочный эффект удобной интеграции.

Смысл интеграций со Slack и Linear - вписать Codex в реальный поток работы команды, а не создать обходной канал. Запустить задачу из обсуждения, где она возникла, и вернуть результат туда же - это дёшево и удобно. Но удобство не отменяет границ: авторизация сервиса, проверка контекста и идентичности, осторожность с внешней мутацией. Интеграция полезна ровно настолько, насколько вы понимаете, что она реально видит, от чьего имени действует и что может изменить снаружи.

Типичные провалы вокруг Slack и Linear предсказуемы. Кинуть ссылку и ждать доступа без установленного и авторизованного коннектора. Не проверить связанный репозиторий или команду и запустить работу по не тому контексту. Упустить чувствительные данные в треде, которые не стоило тащить в задачу. И допустить внешнюю мутацию без осознанно выданного узкого права и проверки идентичности. Авторизуйте сервис явно, проверяйте контекст и идентичность и относитесь к внешней мутации как к side-effecting действию.