Codex як зовнішній радник для Claude Code: Codex MCP Server і @trishchuk/fetch MCP на практиці
Коли більшу частину роботи в проєкті виконує Claude Code, одна модель і планує, і пише код, і оцінює власні рішення. Найслабше місце такої схеми — самоперевірка: модель, яка щойно запропонувала рішення, може не помітити в ньому принципових вад. Людський рецензент допомагає, але не на кожному кроці.
Цю прогалину я закриваю двома MCP-серверами, які написав для власної роботи. Codex MCP Server дає Claude Code змогу отримати другу думку через OpenAI Codex — окремого агента на моделі іншого постачальника, який виступає зовнішнім радником. @trishchuk/fetch MCP дає агентові доступ до публічних вебсторінок, які звичайний HTTP-клієнт іноді не може отримати. Нижче — сценарії з реальних проєктів, у яких кожен із них допомагає. Назви клієнтів і деталі проєктів узагальнено.
Codex MCP Server: зовнішній радник для Claude Code
Codex MCP Server (@trishchuk/codex-mcp-tool на npm, вихідний код на GitHub) — це MCP-сервер, який надає Claude Code інструменти для виклику Codex CLI. Ролі розподілено чітко: Claude — виконавець, який пише код і ухвалює рішення в робочому процесі; Codex — радник, який читає проєкт, оцінює запропоноване й повертає зауваження. Claude вирішує, як діяти далі, а остаточний контроль лишається за мною.
Щоб радник залишався радником, я запускаю його з параметром sandboxMode: "read-only", який сервер передає в Codex CLI: Codex може читати файли й виконувати команди, але не може нічого записати в проєкт. Тож він не виправляє непомітно те, що мав би прокоментувати, — кожне зауваження видно, і його можна врахувати або відхилити. Для складних питань встановлюю reasoningEffort: "high" або "xhigh", щоб модель виконала ретельніший аналіз.
Чому інша модель, а не повторний запит до Claude? Моделі різних постачальників можуть мати різні сліпі зони. Друга модель з іншим «поглядом» частіше помічає те, що автор рішення сприймає як очевидне.
Сценарії, де друга думка змінює рішення
Перевірка алгоритму до написання коду
У великому товарному каталозі частина назв від одного постачальника містила два мовні варіанти в одному рядку. Claude запропонував алгоритм розділення: шукати точку розрізу за коефіцієнтом подібності Жаккара для множин токенів. Перш ніж писати код, я попросив Codex оцінити підхід і поставив кілька цільових запитань у порядку зростання ризику — зокрема, на яких реальних назвах евристика дасть збій (комплекти «×2», акції «1+1», легітимно повторювані номери моделей) і який запобіжник потрібен на випадок хибного розділення.
Роль радника: знайти крайові випадки, поки для їх урахування достатньо одного речення в специфікації, а не міграції даних.
Рецензування специфікацій і проєктних документів
Для мультитенантної SaaS-платформи Codex отримав специфікацію з прямим завданням: знайти рішення, які варто переглянути, а не оцінити документ загалом. Проєктний документ про підвищення надійності синхронізації подій пройшов кілька раундів рецензування, зокрема незалежну перевірку іншою моделлю. На кожному наступному раунді Codex оцінював лише внесені зміни, а не весь документ заново.
Роль радника: критичний погляд на архітектуру до того, як вона стане кодом, і перевірка кожної ітерації без повторення попередньої.
Точкова перевірка після рецензування коду
Після рецензування коміту з бізнес-правилом одне зауваження вирішили відкласти після оцінки ризику. Наступний запит до Codex був вузьким: чи є серед невирішених зауважень критичні.
Роль радника: допомогти ухвалити рішення «випускати чи ні», а не запускати повне рецензування заново.
Аналіз продуктивності за готовими вимірюваннями
Для робочого вебсайту вже були польові метрики: LCP на мобільних пристроях суттєво перевищував рекомендований поріг у 2,5 секунди. Codex отримав наявні вимірювання й завдання лише на статичний аналіз коду — без трасування під час виконання та без Chrome DevTools MCP, адже повторно вимірювати відоме не було потреби.
Роль радника: знайти причини в коді, коли симптоми вже відомі, не витрачаючи час на нові вимірювання.
Як отримати від радника критику, а не схвалення
- Просіть критику прямо. Формулювання на кшталт «зосередься на потенційно хибних рішеннях і ризиках, а не на загальній оцінці» дає значно корисніший результат, ніж «переглянь, будь ласка».
- Давайте конкретні рішення для оцінки. Кілька пронумерованих запитань у порядку зростання ризику працюють краще, ніж загальне «що думаєш?».
- Тримайте радника в режимі read-only. Рецензування відокремлене від змін: зауваження видно, а рішення ухвалюєте ви.
- Обмежуйте обсяг. Якщо дані вже є, скажіть про це й виключіть зайві кроки; на повторних раундах просіть оцінити лише нові зміни.
- Стежте за тим, що передаєте. Надсилайте раднику лише матеріали, які дозволено обробляти зовнішнім моделям, без секретів і персональних даних.
Встановлення, параметри (sandboxMode, reasoningEffort, сесії) і приклади запитів — на сторінці Codex MCP Server. Пакет опубліковано на npm, а вихідний код — на GitHub.
@trishchuk/fetch MCP: доступ агента до публічного вебу
Два інструменти працюють на різних рівнях: Codex MCP Server перевіряє рішення, а @trishchuk/fetch MCP дає агентові потрібні джерела. Друга типова проблема агентної роботи — доступ до вебсторінок. Запити від вбудованих в агентів інструментів завантаження часто отримують відмову там, де браузер відкриває сторінку без перешкод. Одна з причин — сайти класифікують HTTP-клієнтів за мережевими ознаками, зокрема за відбитком TLS (JA3/JA4) і окремо за відбитком HTTP/2, ще до того, як віддати вміст.
@trishchuk/fetch MCP надсилає запити з TLS- та HTTP/2-профілем, сумісним із браузером, і повертає агентові відповідь у зручному для моделі вигляді. В його основі — HTTP-клієнт @trishchuk/fetch (вихідний код на GitHub), нативний модуль Node.js на Rust. Його проєктні рішення, до речі, теж рецензував Codex через Codex MCP Server. Браузерний профіль не гарантує доступу: мережевий відбиток — лише один із сигналів, поряд з IP-репутацією, заголовками й поведінкою клієнта.
Читання технічної документації
В одному з практичних сценаріїв агентові потрібна була публічна документація API SaaS-сервісу, що працює через Cloudflare. Сервер отримав повну сторінку, і агент працював із документацією напряму, без ручного копіювання.
Роль інструмента: дати агентові першоджерело замість переказу чи ручної вставки тексту.
Галузеве дослідження
У дослідницькому проєкті агентові потрібно було прочитати десятки загальнодоступних сторінок галузевих платформ і постачальників, а також публічні регуляторні звіти. Послідовні запити до одного домену використовували спільний сеанс (session), що дає змогу повторно використовувати з’єднання й стан сеансу.
Роль інструмента: забезпечити стабільне читання серії публічних джерел, на яких будується дослідження.
Межі застосування
@trishchuk/fetch MCP — HTTP-клієнт, а не браузер: він не виконує JavaScript, тож не може пройти сторінку перевірки Cloudflare (Challenge Page), яка цього вимагає. Коли журнал змін на сайті одного сервісу повернув таку перевірку (у цьому випадку — HTTP 403 із заголовком cf-mitigated: challenge), спроба на цьому завершилася, і агент отримав ті самі дані з іншого публічного джерела — журналу випусків API. Крім того, загальнодоступність сторінки сама по собі не означає дозволу на автоматизоване завантаження: умови використання сайту й обмеження частоти запитів залишаються чинними.
Встановлення, профілі браузерів, сесії та обмеження розміру відповіді — на сторінці @trishchuk/fetch MCP. Сам HTTP-клієнт доступний окремо на npm і GitHub.
Яке завдання — який інструмент
| Завдання | Інструмент | Роль |
|---|---|---|
| Перевірити алгоритм або архітектуру до реалізації | Codex MCP Server | Зовнішній радник, read-only |
| Рецензувати специфікацію чи проєктний документ | Codex MCP Server | Друга думка, кілька раундів |
| Вирішити, чи критичні відкладені зауваження | Codex MCP Server | Точкова консультація |
| Знайти причини проблеми за відомими метриками | Codex MCP Server | Статичний аналіз коду |
| Прочитати документацію чи публічні сторінки | @trishchuk/fetch MCP | Доступ агента до вебу |
| Зібрати матеріали для дослідження | @trishchuk/fetch MCP | Серія запитів зі спільним сеансом |