Память Codex унесла чат локального провайдера в OpenAI

Функция памяти Codex способна выбрать прошлый диалог, созданный под сторонним провайдером, и отправить его через провайдера, активного в текущей сессии: в контролируемом захвате пять из шести видимых модели элементов исходного диалога ушли на chatgpt.com/backend-api/codex/responses. Отчёт с разбором опубликован на GitHub; по словам автора, проверка велась на стандартном бинарнике Codex для Windows 0.150.0-alpha.12.2.

Коротко

• Задание на генерацию памяти обращается к селектору прошлых сессий с параметром model_providers: None, а сам запрос уходит через клиент модели, созданный из конфигурации той сессии, которая запустила обработку.
• Захваченный кадр response.create весом 38 095 байт содержал три элемента ввода: инструкции памяти на 31 000 символов, служебное сообщение с инструментами и обёртку с 3 092 байтами исходного диалога.
• Отключение аналитики и перевод всех экспортёров OpenTelemetry в none канал не закрывают: единственный работающий глобальный переключатель для этого пути, по данным отчёта, флаг [features] memories = false.

Для разработчиков, которые сознательно направляют часть работы на локальную или стороннюю модель, граница провайдера и есть основная гарантия конфиденциальности. Описанный канал выглядит как её обход по умолчанию: контент прежних сессий уходит наружу без отдельного согласия, а привычные тумблеры приватности к нему не применяются. Автор трактует произошедшее как передачу данных за выбранную границу без осознанного согласия, и, если содержимое таких запросов действительно попадает в контур модерации, вопрос смещается из инженерной плоскости в правовую.

Пять из шести видимых модели элементов совпали с исходным диалогом структурно точно

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

Разработческое сообщение исходной сессии, а также записи сессии, хода, событий и состояния мира в выборку не попали. Путь к файлу записи и рабочий каталог ушли за пределы области, к которой применяется редактирование. Запрос помечен как request_kind = «memory», с полями store = false и prompt_cache_retention = «24h».

Сервер ответил событиями response.created и response.completed. В завершении указана модель gpt-5.6-luna и расход 7 337 входных токенов, 983 выходных и 8 320 суммарно. Сгенерированная запись памяти на 3 405 символов несколько раз повторила уникальные маркеры из исходного диалога, включая пользовательский, ассистентский, инструментальный и синтетический почтовый.

Селектор кандидатов вызывается с параметром model_providers: None

По разбору автора, в текущем теге исходников путь состоит из трёх стадий. Отбор кандидатов не привязан к провайдеру: задание памяти передаёт селектору model_providers: None, применяя при этом другие правила пригодности, включая режим памяти, возраст записи, простой, тип источника и состояние заявки (state/src/runtime/memories.rs, строки 218-234).

Рантайм памяти создаёт провайдера из config.model_provider вместе с клиентом модели, который и выполняет запрос (memories/write/src/runtime.rs, строки 112-133 и 241-267). На первой фазе сохранённая запись загружается, фильтруется, сериализуется и укладывается в новое сообщение пользователя, которое уходит через этот клиент (phase1.rs, строки 282-322).

Автор отмечает, что отчёт связан с issue #37009, но описывает обратное направление маршрутизации: там речь об идентификаторах моделей OpenAI, уходящих к активному стороннему провайдеру, здесь о прошлых записях, отобранных без фильтра по провайдеру-источнику и отправленных через OpenAI в рамках другой сессии памяти.

Фильтр секретов ловит ключи sk-, идентификаторы AKIA и bearer-токены

Перед отправкой сериализатор вызывает redact_secrets, но выражения покрывают узкий набор шаблонов: ключи вида sk-, идентификаторы AWS AKIA, длинные bearer-токены и значения при именах api_key, token, secret и password. В отдельном тесте фильтр оставил ключ с подчёркиваниями, cookie-подобное значение, почтовый адрес и путь Windows.

Объём ограничен усечением по середине: длинные входы обрезаются на 70% эффективного окна контекста, с запасным порогом в 150 000 токенов, начало и конец сохраняются. Для короткой ветки это означает почти всю переписку пользователя и ассистента вместе с аргументами инструментов, результатами, ошибками и локальными путями.

Захват выполнен в изолированной конфигурации: память включена, [analytics] enabled = false, все экспортёры OpenTelemetry выставлены в none. Автор подчёркивает, что это трафик вывода модели, а не аналитика и не телеметрия, а раздельного переключателя, который сохранял бы память и запрещал межпровайдерную передачу, в сборке нет. Расследование, по его словам, началось после предупреждения аккаунта OpenAI за «cyber abuse».

Чего автор требует от OpenAI: привязать отбор и отправку к провайдеру исходной записи либо пропускать такие записи, сделать межпровайдерную обработку явно опциональной с указанием получателя и классов контента и закрепить изоляцию провайдеров автотестами. Пользовательская документация должна прямо описывать возможность такой передачи.

К мейнтейнерам обращены вопросы: считается ли межпровайдерная обработка задуманным поведением, какие выпуски затронуты, какие серверные правила хранения и вторичной обработки действуют для запросов request_kind = «memory» и используется ли такой контент для модерации аккаунтов. Автор просит сохранить связанные логи и решения по модерации для возможного разбирательства.