У свіжому гайді на каналі Tech With Tim автор показує, як перетворити Codex CLI на повноцінного «хмарного» код‑агента, що не лише працює 24/7 на VPS, а й безпосередньо керує репозиторіями в GitHub. Ключовий елемент цієї схеми — правильне підключення до GitHub з тонким налаштуванням прав доступу та валідацією того, що агент справді може створювати репозиторії, робити pull‑request’и й запускати автоматизації.
Навіщо Codex потрібен доступ до GitHub
Після базового розгортання Codex CLI на віртуальному сервері наступним логічним кроком стає інтеграція з GitHub. Сенс не лише в тому, щоб читати код з репозиторіїв: повноцінний агент отримує змогу працювати з ними так само, як це робить розробник.
У фокусі — кілька типових задач, які стають можливими після підключення:
Codex може створювати нові репозиторії, клонувати їх на VPS та ініціалізувати структуру проєкту. Він здатен відкривати й оновлювати pull‑request’и, що відкриває дорогу до напівавтоматичного код‑рев’ю та оновлень гілок. Додатково агент може використовувати репозиторії як точку входу для будь‑яких автоматизацій: від регулярного аналізу PR’ів до генерації звітів за змінами.
Усе це зав’язано на можливості Codex викликати GitHub‑команди зсередини VPS. Тому інтеграція складається з двох великих частин: створення fine‑grained токена в GitHub з потрібними правами та налаштування GitHub CLI на сервері.
Створення fine‑grained токена GitHub для Codex
Інтеграція починається з самої панелі GitHub. Потрібен звичайний обліковий запис, який можна створити безкоштовно, після чого відкриваються «гранульовані» персональні токени з чітким контролем доступу до репозиторіїв.
У налаштуваннях профілю GitHub треба перейти в розділ Settings, а далі внизу в Developer settings. Саме там створюється API‑ключ, який потім використовуватиметься на VPS для підключення до акаунта GitHub.
Є два підходи до того, чий це має бути акаунт. Можна виділити для Codex окремий GitHub‑акаунт, фактично створивши окремого «користувача‑агента». Але в розборі робиться інший вибір: інтеграція йде з основним особистим акаунтом, а безпека забезпечується за рахунок максимально чіткого обмеження прав токена.
У розділі Personal access tokens обирається вкладка Fine‑grained tokens і натискається Create new token. Далі формується токен під VPS‑сценарій:
токену дається зрозуміла назва на кшталт «Codex VPS», щоб його було легко ідентифікувати в майбутньому;
для терміну дії встановлюється «no expiration», щоб токен не доводилося часто перевипускати. Це підходить для довготривалої інтеграції з VPS, яка має працювати без постійного ручного втручання;
у полі репозиторіїв обирається «all repositories», що надає агенту доступ до всіх репозиторіїв акаунта. Якщо проєктів багато, це означає, що один токен зможе працювати з усім портфелем, але водночас зростає ціна помилки у налаштуваннях прав.
Після цього починається найважливіша частина — вибір дозволів.
Які права дати агенту і де не перестаратися
Fine‑grained токени GitHub дозволяють дуже точно вказати, що саме можна, а що не можна робити з репозиторіями. Для сценарію з Codex виділяється кілька ключових permission‑груп:
Адміністрування репозиторіїв. Якщо агент має створювати та видаляти репозиторії, потрібно ввімкнути категорію administration. Саме вона дає змогу створювати нові проєкти та керувати їх життєвим циклом. Це одна з найчутливіших правок, оскільки відкриває можливість видалення репозиторіїв, тож до неї радять ставитися максимально обережно.
Контент репозиторіїв. Щоб агент міг редагувати файли, робити коміти й працювати з гілками, у налаштуваннях дозволів додається категорія contents. Вона відповідає за читання та запис умісту: створення файлів, зміну коду, роботу з історією.
Pull‑request’и. Для роботи з PR’ами вмикається категорія pull requests. Вона дозволяє отримувати інформацію про запити на злиття, коментарі, асайні, статуси і, за потреби, створювати та оновлювати самі PR’и.
Окремий акцент робиться на режимах читання й запису. Для більшості сценаріїв без участі людини доведеться надавати read and write, інакше агент не зможе створювати нові репозиторії, гілки чи pull‑request’и. Водночас у демонстрації спершу вибирається більш консервативний варіант: деякі дозволи лишаються в режимі read only, щоб зменшити ризик небажаних дій на кшталт видалення репозиторіїв.
Логіка така: на старті можна дати агенту мінімальний набір прав і перевірити, як він поводиться у кількох тестових сценаріях. Якщо все працює коректно, дозволи поступово розширюються, аж до повного read and write там, де цього справді потребують робочі процеси.
Після налаштування дозволів токен генерується, і його разове значення копіюється для використання у VPS. Важливий нюанс: цей токен не можна показувати нікому й ніде не світити, оскільки він фактично дає прямий технічний доступ до репозиторіїв у зазначеному обсязі.
GitHub CLI на VPS: як навчити Codex працювати з репозиторіями
Створити токен — лише половина справи. Щоб Codex CLI міг використовувати його, на віртуальному сервері встановлюється офіційний інструмент GitHub — gh.
У середовищі VPS, де вже розгорнуто Codex CLI, у терміналі виконується команда встановлення:
apt install gh -y
Це ставить GitHub CLI й одразу приймає всі необхідні підтвердження завдяки флагу -y. Після інсталяції можна просто ввести в терміналі gh, щоб переконатися, що інструмент доступний.
Далі йде авторизація GitHub CLI:
викликається команда gh auth login;
у діалозі обирається платформа github.com;
як протокол підключення використовується https;
для способу авторизації обираються GitHub credentials з токеном.
На завершальному етапі CLI просить вставити токен, створений раніше у Developer settings. Після вставки й підтвердження GitHub CLI повідомляє, що автентифікація успішна, і показує, під яким акаунтом виконано вхід. У прикладі це акаунт Tech With Tim.
На цьому моменті вся зв’язка сходиться: VPS має доступ до GitHub через gh, а Codex CLI, який працює в тому ж середовищі, може викликати ці команди для виконання будь‑яких GitHub‑операцій у межах прав токена.
Перевірка доступу: як упевнитися, що Codex бачить ваші репозиторії
Щоб не працювати «всліпу», після налаштування радять зробити простий тест: переконатися, що Codex справді може користуватися GitHub CLI й бачить потрібні репозиторії.
У сесії Codex CLI на VPS можна сформулювати запит до агента в явному вигляді: пояснити, що в нього є доступ до команди gh і що потрібен список репозиторіїв для валідації підключення. Також згадується ім’я користувача — у демонстрації це Tech With Tim — аби агент знав, до якого акаунта звертатися.
Після запуску такого запиту Codex виконує GitHub‑команди через gh і повертає перелік репозиторіїв, до яких має доступ. У результаті формується список і приватних, і публічних проєктів — показник того, що токен працює, CLI налаштований правильно, а агент може працювати з усім, що йому дозволено.
Цей крок важливий не лише як технічна перевірка. Він дає змогу на практиці побачити, наскільки широким вийшов доступ: якщо виводиться надто багато «зайвих» репозиторіїв, можливо, варто переглянути обсяг прав токена або створити окремий акаунт/токен для експериментів.
Висновки: GitHub як природне середовище для AI‑агента
Після того як Codex CLI працює на VPS і має налаштований доступ до GitHub через fine‑grained токен і gh‑CLI, агент перестає бути просто «розумною підказкою коду». Він отримує повноцінний операційний контекст: може створювати й змінювати репозиторії, працювати з pull‑request’ами та бути вмонтованим у рутинні процеси розробки і супроводу коду.
Ключовими елементами цієї інтеграції стають:
створення окремого fine‑grained токена в GitHub із чітким набором дозволів;
усвідомлений вибір рівня доступу — від read only для перших тестів до read and write для продакшн‑сценаріїв, де агент має створювати репозиторії та гілки;
встановлення та авторизація GitHub CLI (gh) на VPS, щоб Codex міг використовувати GitHub‑команди всередині того ж середовища;
явна перевірка доступу через запит до Codex з використанням gh і виведення списку доступних репозиторіїв.
У такій конфігурації GitHub перестає бути просто віддаленим сховищем, а стає для Codex робочим полем, де агент може виконувати не лише разові дії, а й виступати ядром для складніших автоматизацій навколо реального репозиторію з кодом.
Джерело
YouTube: I Gave Codex a 24/7 Server. Now It Codes While I Sleep.