Спасибо за статью и сам проект. Я как раз подробно проверил yandex-metrica-mcp перед подключением к своему аналитическому агенту. Решение оставило очень хорошее впечатление: небольшой, но гибкий набор инструментов, read-only подход, PKCE и аккуратная работа с ограничениями Reporting API.
Во время проверки я заметил небольшой пропуск: поле contains_sensitive_data валидировалось при разборе ответа Метрики, но не передавалось в итоговый meta MCP-инструмента. Отправил небольшой PR #9 с исправлением и regression-тестом.
Отдельно понравилось, что проект не пытается превращать каждый отчёт в отдельный инструмент, а сохраняет гибкость метрик, измерений и фильтров. Спасибо за качественную реализацию и подробное описание технических решений — статья действительно помогает понять, что происходит под капотом.
Да, проблемы на самом деле есть. И ее признает OpenAI на своем GitHub.
Уже есть открытый PR от участника OpenAI: #29432 “Stop logging every Responses WebSocket event”. Он пока не смёржен, но прямо признаёт причину: каждый успешный WebSocket event создавал несколько локальных лог-записей и вызывал постоянный SQLite insert/prune churn.
Проверил на своём macOS/Codex Desktop. Штатного понятного флага типа “выключить SQLite feedback logs” не нашёл. sqlite_home есть, но это переносит всю SQLite-state директорию, а не только логи. feedback.disabled выглядит как настройка для отправки feedback, но не как надёжный фикс записи в logs_2.sqlite.
Сначала проверил churn:
sqlite3 ~/.codex/logs_2.sqlite \
"SELECT COUNT(*) AS rows, MAX(id) AS max_id, MAX(ts) AS max_ts FROM logs;"
sleep 20
sqlite3 ~/.codex/logs_2.sqlite \
"SELECT COUNT(*) AS rows, MAX(id) AS max_id, MAX(ts) AS max_ts FROM logs;"
В моём случае за 20 секунд COUNT(*) не изменился, но MAX(id) вырос. То есть база не обязательно растёт по числу retained rows, но Codex продолжает делать insert/prune и писать в SQLite/WAL.
Поставил обратимый SQLite workaround:
sqlite3 ~/.codex/logs_2.sqlite \
"CREATE TRIGGER IF NOT EXISTS block_log_inserts
BEFORE INSERT ON logs
BEGIN
SELECT RAISE(IGNORE);
END;"
Проверка, что trigger установлен:
sqlite3 ~/.codex/logs_2.sqlite \
"SELECT name, tbl_name
FROM sqlite_master
WHERE type='trigger'
AND name='block_log_inserts';"
После этого повторный 20-секундный замер показал: COUNT(*), MAX(id) и MAX(ts) вообще не изменились. Новые вставки в таблицу logs заблокированы, Codex Desktop при этом не упал.
sqlite3 ~/.codex/logs_2.sqlite \
"DROP TRIGGER IF EXISTS block_log_inserts;"
Почему это работает? Trigger BEFORE INSERT ON logs с RAISE(IGNORE) заставляет SQLite молча игнорировать новые вставки в таблицу диагностических логов. Это прекращает insert/prune churn в logs_2.sqlite, из-за которого MAX(id)растёт даже при стабильном COUNT(*).
Минус: локальные diagnostic logs в logs_2.sqlite больше не пишутся. История сессий и state Codex этим не должны затрагиваться. Это stopgap до нормального upstream fix, где логирование нужно фильтровать до formatting/queue/SQLite insert.
Если работать в эту сторону (СС пишет, Кодекс как аудитор кода), то нет. Более того, Кодекс всегда находит какие-то «косячки», с которыми СС соглашается, что это его промашки )
Но основное - это все-таки Серена. Вот это просто маст хэв! Да вам лучше спросить напрямую у СС о сравнении с Сиреной или без планировать и писать код
Использую мультимодельность при планировании и написании кода. СС планирует - Кодекс проверяет. СС пишет код - Кодекс оценивает результат.
Сделаны специальные скиллы по разработке и доработке. Если затрагивается более 3 файлов, то скилл код- ревью от Антропика обязателен ( это еще до внешнего аудита через Кодекс)
Для планирования и работы с кодом работать только через Serena MCP! Никаких встроенных инструментов
Тоже давно читаю весь этот околовпнный хайп. И предлагаю взглянуть на вопрос с чуть другой стороны.
Да, любое приложение на Андроиде (да и на IOS тоже) может детектировать (точнее, уверенно предположить) поднятый на устройстве впн. И даже сообщить «куда следует» ваш конечный IP. А что дальше?
Впн у нас в стране не под запретом. Поэтому важно исключить не возможность детектировать есть/нет у нас впн подключение, а как и для чего мы его используем. Или, юридическим языком, обходим мы с его помощью блокировки или нет. А вот здесь для РКН все ой как не гладко
Блокировки выявленного конечного IP по факту ничего им не дают. К примеру, мой голландский IP на прямое подключение заблочен уже почти месяц как, но и по сей день прекрасно трудится на каскаде, ибо межсерверный трафик РКН может блокировать только по принципу «сломаю пол-инета». Не пустят с включенным впн в аккредитованные приложения? Да и х… с ними. Выключу кнопку впн и зайду.
Понятно, что сейчас доступ к свободному Инету в РФ стал не просто «поставлю 3 хуи и весь мир открыт», а стал дороже и требует творчества и хотя бы 3 классов школы ИТ-инженера. Но для нашего русского ума это всего лишь легкая разминка.
Как краткий вывод, считаю, что сейчас надо направлять усилия не на поиск решения найдут «гос зловреды» впн или не найдут, а на то, чтобы впн работал несмотря ни на что и не отсвечивал «куда, как и для чего» мы его используем
Спасибо за статью и сам проект. Я как раз подробно проверил
yandex-metrica-mcpперед подключением к своему аналитическому агенту. Решение оставило очень хорошее впечатление: небольшой, но гибкий набор инструментов, read-only подход, PKCE и аккуратная работа с ограничениями Reporting API.Во время проверки я заметил небольшой пропуск: поле
contains_sensitive_dataвалидировалось при разборе ответа Метрики, но не передавалось в итоговыйmetaMCP-инструмента. Отправил небольшой PR #9 с исправлением и regression-тестом.Отдельно понравилось, что проект не пытается превращать каждый отчёт в отдельный инструмент, а сохраняет гибкость метрик, измерений и фильтров. Спасибо за качественную реализацию и подробное описание технических решений — статья действительно помогает понять, что происходит под капотом.
Да, проблемы на самом деле есть. И ее признает OpenAI на своем GitHub.
Уже есть открытый PR от участника OpenAI: #29432 “Stop logging every Responses WebSocket event”. Он пока не смёржен, но прямо признаёт причину: каждый успешный WebSocket event создавал несколько локальных лог-записей и вызывал постоянный SQLite insert/prune churn.
Проверил на своём macOS/Codex Desktop. Штатного понятного флага типа “выключить SQLite feedback logs” не нашёл.
sqlite_homeесть, но это переносит всю SQLite-state директорию, а не только логи.feedback.disabledвыглядит как настройка для отправки feedback, но не как надёжный фикс записи вlogs_2.sqlite.Сначала проверил churn:
В моём случае за 20 секунд
COUNT(*)не изменился, ноMAX(id)вырос. То есть база не обязательно растёт по числу retained rows, но Codex продолжает делать insert/prune и писать в SQLite/WAL.Поставил обратимый SQLite workaround:
Проверка, что trigger установлен:
После этого повторный 20-секундный замер показал:
COUNT(*),MAX(id)иMAX(ts)вообще не изменились. Новые вставки в таблицуlogsзаблокированы, Codex Desktop при этом не упал.Опционально можно обнулить текущий WAL:
Откат:
Почему это работает? Trigger
BEFORE INSERT ON logsсRAISE(IGNORE)заставляет SQLite молча игнорировать новые вставки в таблицу диагностических логов. Это прекращает insert/prune churn вlogs_2.sqlite, из-за которогоMAX(id)растёт даже при стабильномCOUNT(*).Минус: локальные diagnostic logs в
logs_2.sqliteбольше не пишутся. История сессий и state Codex этим не должны затрагиваться. Это stopgap до нормального upstream fix, где логирование нужно фильтровать до formatting/queue/SQLite insert.Пока эти сказочные идиоты не запретят себе запрещать, "цирк с конями" будет продолжаться!
Если работать в эту сторону (СС пишет, Кодекс как аудитор кода), то нет. Более того, Кодекс всегда находит какие-то «косячки», с которыми СС соглашается, что это его промашки )
Но основное - это все-таки Серена. Вот это просто маст хэв! Да вам лучше спросить напрямую у СС о сравнении с Сиреной или без планировать и писать код
Согласен. Тоже опытным путем пришел к 3 решениям:
Использую мультимодельность при планировании и написании кода. СС планирует - Кодекс проверяет. СС пишет код - Кодекс оценивает результат.
Сделаны специальные скиллы по разработке и доработке. Если затрагивается более 3 файлов, то скилл код- ревью от Антропика обязателен ( это еще до внешнего аудита через Кодекс)
Для планирования и работы с кодом работать только через Serena MCP! Никаких встроенных инструментов
Предполагаю, что на старом Intel Mac с macOS Catalina выбор нормального vless клиента - это далеко не единственная проблема.
А почему не сразу не воспользоваться патчером и не накатить хотя бы Вентуру?
Вот репо с патчером https://github.com/dortania/OpenCore-Legacy-Patcher/releases
Тогда уж и мое пиво подержите, друзья!
Тоже давно читаю весь этот околовпнный хайп. И предлагаю взглянуть на вопрос с чуть другой стороны.
Да, любое приложение на Андроиде (да и на IOS тоже) может детектировать (точнее, уверенно предположить) поднятый на устройстве впн. И даже сообщить «куда следует» ваш конечный IP. А что дальше?
Впн у нас в стране не под запретом. Поэтому важно исключить не возможность детектировать есть/нет у нас впн подключение, а как и для чего мы его используем. Или, юридическим языком, обходим мы с его помощью блокировки или нет. А вот здесь для РКН все ой как не гладко
Блокировки выявленного конечного IP по факту ничего им не дают. К примеру, мой голландский IP на прямое подключение заблочен уже почти месяц как, но и по сей день прекрасно трудится на каскаде, ибо межсерверный трафик РКН может блокировать только по принципу «сломаю пол-инета». Не пустят с включенным впн в аккредитованные приложения? Да и х… с ними. Выключу кнопку впн и зайду.
Понятно, что сейчас доступ к свободному Инету в РФ стал не просто «поставлю 3 хуи и весь мир открыт», а стал дороже и требует творчества и хотя бы 3 классов школы ИТ-инженера. Но для нашего русского ума это всего лишь легкая разминка.
Как краткий вывод, считаю, что сейчас надо направлять усилия не на поиск решения найдут «гос зловреды» впн или не найдут, а на то, чтобы впн работал несмотря ни на что и не отсвечивал «куда, как и для чего» мы его используем