OpenAI поступово перетворює Codex із «розумного автодоповнення» в терміналі на повноцінне середовище для програмної інженерії. На воркшопі AI Engineer розробники OpenAI Вайбгав Срівастава та Катя Гіл Гусман показали, як сьогодні виглядає Codex як застосунок: багатопроєктна робота, автоматизації для Slack і Gmail, а також нова система плагінів, що збирає навички, інтеграції та MCP‑сервери в повторно використовувані робочі процеси.
Цей матеріал зосереджується саме на продуктовому шарі Codex — застосунку, автоматизаціях і плагінах — і на тому, як із цього складається продуктивне AI‑середовище для інженерів.
Від «чату з моделлю» до робочого столу: що дає Codex App
Codex у поточній інкарнації описують як «відкритого програмного інженера» OpenAI. Це не просто модель, що дописує функцію в IDE: агент уміє запускати команди, виконувати тести, досліджувати кодові бази й загалом повторювати більшість дій, які виконує інженер у щоденній роботі. Але ключовою зміною стало те, як усе це подається розробнику.
Codex можна викликати з різних поверхонь — через застосунок, IDE‑розширення, CLI, Slack, GitHub або кастомні інтеграції з Figma, Linear, Notion та іншими сервісами. Саме Codex App став центральною точкою, де ці можливості зібрані в робоче середовище, а не в окремі «чати».
Застосунок підтримує кілька проєктів одночасно. У лівій панелі можна тримати, наприклад, окремі простори для Codex, ChatGPT, Sora чи внутрішніх сервісів компанії. Це вже наближає Codex до ролі «AI‑колеги», який живе поруч із кодовою базою, а не в абстрактному вікні браузера.
Однак справжній зсув відбувається на рівні того, як Codex працює всередині кожного проєкту.
Паралельні фічі без колізій: робочі дерева в Codex
У кожному проєкті Codex App підтримує власні work trees — робочі дерева, прив’язані до окремих задач. Це дозволяє одночасно вести кілька фіч, виправлень багів або просто гілок Q&A, не змішуючи контексти.
Фактично це нативна підтримка того, що багато команд намагаються емулювати через гілки Git, окремі сесії в IDE або множинні вікна терміналу. У Codex кожне робоче дерево — це окремий простір, де агент бачить відповідний зріз коду, історію дій та інструкції. Якщо в одному work tree Codex рефакторить модуль авторизації, а в іншому — додає новий API‑ендпоінт, їхні контексти не перетинаються.
Це важливо не лише для зручності, а й для якості роботи агента. AI‑система, яка одночасно «пам’ятає» кілька задач в одній сесії, легко починає плутати вимоги, змішувати патчі або переносити проміжні рішення з однієї гілки в іншу. Розділення на робочі дерева знімає цю проблему на рівні інтерфейсу й інфраструктури.
Для розробника це означає можливість працювати так, як працює команда: паралельно вести кілька ініціатив, повертатися до них у зручний момент, не витрачаючи час на відновлення контексту для агента. Codex, своєю чергою, може тримати кожну лінію роботи в окремому «ментальному просторі».
Від macOS до Windows: чому важливий нативний sandbox
Codex App стартував як нативний застосунок для macOS. Для екосистеми OpenAI це було логічно: значна частина інженерів і стартапів працює на Mac, а інтеграція з локальним середовищем розробки там традиційно простіша.
Однак наступним кроком стало повноцінне розширення на Windows — із нативною підтримкою та, що особливо показово, з власним Windows‑sandbox для безпечного виконання команд і інструментів. За словами команди, це перший у своєму роді sandbox такого типу для Windows серед подібних агентних «harness‑ів».
Sandbox у цьому контексті — не маркетинговий термін, а критична частина архітектури. Codex як агент уміє запускати команди, працювати з файлами, виконувати тести. На Windows це традиційно складніше зробити безпечно й ізольовано, ніж на Unix‑подібних системах. Наявність нативного sandbox означає, що Codex може діяти як «інженер за клавіатурою», але в контрольованому середовищі, де ризики для основної системи користувача мінімізовані.
Для компаній, де Windows залишається стандартом робочих станцій, це відкриває можливість розгортати Codex не як експериментальний інструмент для ентузіастів, а як частину офіційного стеку. А для OpenAI — це крок до того, щоб агентна інженерія не була прив’язана до однієї платформи.
Автоматизації як вбудований «операційний шар» для інженера
Окремий пласт функціональності Codex App — автоматизації. Ідея проста: якщо є процес, який повторюється щодня або за розкладом, його можна описати й доручити Codex виконувати його самостійно в заданий час.
Автоматизації запускаються за розкладом без участі користувача. Це можуть бути ранкові брифінги, вечірні підсумки, регулярні перевірки репозиторіїв або календаря. Усе це працює всередині самого застосунку, без необхідності окремих cron‑job’ів чи зовнішніх сервісів.
Ключовим є те, що автоматизації не обмежуються локальним середовищем. Codex уміє підключатися до зовнішніх застосунків — насамперед Slack і Gmail — і перетворювати інформаційний шум на структуровані, дієві огляди.
Щоденні дайджести Slack: як AI фільтрує шум
Slack давно став нервовою системою багатьох команд, але водночас — джерелом постійного перевантаження. Codex‑автоматизації дозволяють налаштувати щоденні дайджести Slack, які виконують кілька завдань одночасно.
По‑перше, агент збирає повідомлення за певний період і формує узагальнення. Це не просто «ось 100 нових меседжів», а стислий огляд того, що сталося в ключових каналах, які теми обговорювалися, які рішення ухвалювалися.
По‑друге, Codex виділяє важливі канали та треди. У типовій організації є десятки робочих просторів і сотні каналів, але лише частина з них критично важлива для конкретного інженера чи менеджера. Автоматизація може бути налаштована так, щоб приділяти особливу увагу певним каналам, а інші — згортати до мінімуму.
По‑третє, агент позначає елементи, які потребують відповіді або дії. Це ключовий момент: замість того, щоб просто переказати потік повідомлень, Codex намагається зрозуміти, де від користувача очікують реакції, де є згадки, відкриті питання або дедлайни. У результаті дайджест перетворюється на список пріоритетних завдань, а не на ще один канал інформації.
Такий сценарій особливо корисний для розподілених команд, де робочий день починається з накопиченого за ніч потоку повідомлень. Замість півгодини скролінгу Slack інженер отримує структурований огляд і може одразу перейти до найважливішого.
Gmail під контролем: пошук листів, що справді потребують відповіді
Схожа логіка застосовується до Gmail. Codex‑автоматизації можуть бути налаштовані на щоденне сканування вхідної пошти з кількома цілями.
Насамперед агент шукає листи, які потребують відповіді. Це означає аналіз змісту, тональності, контексту листування, щоб відрізнити, де від користувача очікують дій, а де йдеться лише про інформаційні розсилки або FYI‑повідомлення.
Далі Codex оцінює терміновість. Не всі листи, що потребують відповіді, однаково критичні. Деякі стосуються блокерів у проєкті, інші — довгострокових ініціатив. Автоматизація може розставити пріоритети, щоб користувач бачив, чим варто зайнятися негайно, а що може зачекати.
Нарешті, агент фільтрує низьковартісні або низькопріоритетні запити. Це можуть бути масові розсилки, прохання, які не входять у зону відповідальності користувача, або листи, на які відповідь не є обов’язковою. У підсумку замість переповненої скриньки користувач отримує керований список завдань, де кожен пункт має зрозумілий контекст і пріоритет.
Разом Slack‑дайджести й Gmail‑фільтрація перетворюють Codex на щось більше, ніж інструмент для написання коду. Це стає операційним шаром навколо роботи інженера, який допомагає не лише писати й запускати код, а й керувати інформаційними потоками.
Плагіни як новий рівень: навички, застосунки, MCP‑сервери й промпти в одному пакеті
Найсвіжіше доповнення до Codex App — нативна підтримка плагінів. Це спроба структурувати й повторно використовувати те, що раніше часто існувало як набір розрізнених інструкцій, скриптів і інтеграцій.
Плагін у Codex — це пакет, який може включати навички (skills), застосунки (apps), MCP‑сервери та промпти. Разом вони утворюють робочий процес, який можна підключити до проєкту, поділитися з колегами й використовувати повторно в різних контекстах.
Навички: як упакувати процес у повторно використовувану інструкцію
Навички в Codex — це багаторазові інструкційні пакети для конкретних процесів. Якщо команда регулярно виконує один і той самий тип задачі — наприклад, підготовку реліз‑нотаток, оновлення документації, перевірку стилю коду чи міграцію конфігурацій, — цей процес можна оформити як навичку.
У навичку можна закласти:
інструкції, які пояснюють, як саме має діяти агент;
скрипти, що автоматизують частину кроків;
ресурси, які потрібні для виконання задачі.
Після цього Codex знає про існування цієї навички й може викликати її за потреби, не змушуючи користувача щоразу з нуля пояснювати, «як ми тут робимо X». Більше того, сам Codex може допомогти створити таку навичку: опис процесу в природній мові перетворюється на структурований пакет.
Це важливий крок до стандартизації роботи агента в межах команди. Замість того, щоб кожен інженер мав власний набір «секретних промптів», навички стають спільним ресурсом, який можна версіонувати, перевіряти й удосконалювати.
Застосунки й MCP‑сервери: вихід за межі локального середовища
Другий компонент плагінів — застосунки. Це підключення до зовнішніх сервісів, таких як Notion, Linear, Google Drive та інші. Через застосунки Codex отримує змогу не лише читати дані, а й оновлювати їх, працюючи з ними як із частиною загального робочого процесу.
Третій елемент — MCP‑сервери. Вони відкривають зовнішні інструменти як сервіси, якими може користуватися агент. Це може бути все, що завгодно: від внутрішніх API компанії до спеціалізованих утиліт для аналізу коду чи даних. MCP‑сервери розширюють можливості Codex за межі того, що вбудовано в сам застосунок, і дозволяють інтегрувати його в складніші інженерні середовища.
Разом навички, застосунки й MCP‑сервери, об’єднані в плагін, створюють повторно використовуваний workflow. Наприклад, плагін може описувати повний цикл роботи з певним типом задачі: від збору даних із Google Drive і Linear до оновлення документації в Notion і надсилання підсумку в Slack.
Повторне використання й обмін між проєктами
Ключова перевага плагінів у Codex — можливість переносити їх між проєктами й командами. Якщо один раз налаштовано ефективний процес, його не потрібно відтворювати вручну в кожному новому репозиторії чи робочому просторі. Достатньо підключити відповідний плагін.
Це особливо важливо для організацій, які прагнуть уніфікувати практики роботи з AI‑агентами. Замість того, щоб кожна команда будувала власні «ритуали» навколо Codex, можна створити набір офіційних плагінів, які відображають внутрішні стандарти: як оформлювати код‑рев’ю, як працювати з інцидентами, як готувати релізи.
Плагіни стають своєрідною «операційною системою» поверх Codex: вони визначають, які інструменти доступні агенту, як він має їх використовувати й які процеси вважаються канонічними в межах організації.
Codex як середовище, а не просто модель
Усе описане вище — багатопроєктна структура з робочими деревами, нативний sandbox на macOS і Windows, автоматизації для Slack і Gmail, система плагінів із навичками, застосунками та MCP‑серверами — вказує на важливий зсув у тому, як OpenAI позиціонує Codex.
Це вже не «модель для коду» й не «чат‑бот для розробників». Це середовище, у якому AI‑агент живе поруч із кодовою базою, інструментами комунікації та сервісами управління проєктами. Він може одночасно:
працювати над кількома фічами або багами в окремих робочих деревах;
виконувати регулярні операційні задачі через автоматизації;
інтегруватися з зовнішніми системами через застосунки й MCP‑сервери;
діяти за стандартизованими процесами, описаними в навичках і плагінах.
Для розробників це означає, що взаємодія з AI виходить за межі «запит‑відповідь» і стає частиною щоденної рутини: від ранкового Slack‑дайджесту до вечірнього підсумку змін у репозиторії. Для команд — що з’являється можливість формалізувати й масштабувати найкращі практики роботи з агентами, а не покладатися на індивідуальний досвід окремих інженерів.
Codex уже має понад 3 мільйони щотижневих активних користувачів, і ця цифра, за даними OpenAI, більш ніж утричі зросла від початку року. Такий темп прийняття свідчить не лише про інтерес до нових моделей, а й про запит на інструменти, які вбудовують AI у реальний робочий день інженера. Codex App із його проєктами, автоматизаціями та плагінами — одна з перших спроб відповісти на цей запит системно.
Висновок: AI‑інженер, який живе у вашому робочому просторі
Еволюція Codex показує, що наступний етап розвитку інструментів для розробників — це не просто кращі моделі, а кращі середовища. Можливість тримати кілька проєктів і робочих дерев, запускати автоматизації для Slack і Gmail, будувати плагіни з навичок, застосунків і MCP‑серверів перетворює Codex на щось ближче до «цифрового колеги», ніж до чергового інструмента автодоповнення.
У такій конфігурації AI не замінює IDE чи таск‑трекер, а зв’язує їх між собою, знімаючи частину рутинних дій і допомагаючи тримати фокус на суті задачі. Для інженерів це шанс делегувати не лише написання коду, а й частину операційної роботи. Для команд — можливість стандартизувати взаємодію з AI через плагіни й навички, зробивши її передбачуваною й керованою.
Якщо перше покоління AI‑інструментів для розробників було про «допомогу в написанні коду», то Codex App із його проєктами, автоматизаціями та плагінами робить крок до моделі, де AI бере участь у всьому життєвому циклі розробки — від вхідних повідомлень у Slack до змін у репозиторії.
Джерело
Codex and Subagents — Vaibhav Srivastav & Katia Gil Guzman, OpenAI (YouTube)