Как запускать кодинг-агентов на Claude Code более 24 часов: 4 рабочих подхода

Стандартный цикл работы с кодинг-агентом выглядит так: вы даёте задачу, агент генерирует код за 10-15 минут, вы тратите час на ревью и правки, затем снова запускаете агента. За сутки активная работа занимает от силы час-полтора. Остальные 22 с лишним часа агент простаивает в ожидании человека. Узкое место - не генерация кода, а проверка и принятие решений разработчиком.

Четыре подхода решают эту проблему и позволяют агенту работать непрерывно более 24 часов: выдача расширенных прав с sandbox-изоляцией, автоматическая верификация результатов, agentic code review силами второго агента и удалённый запуск на постоянно включённой машине. Каждый метод можно внедрить независимо, а при комбинировании они дают кратный прирост продуктивности. Разберём настройку и практические сценарии для Claude Code и Codex.

Почему стандартных сессий не хватает: проблема человеческого ревью

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

Цифры подтверждают дисбаланс. Если агент пишет feature за 10 минут, а ревью занимает час, то за 24 часа активной работы агент используется лишь 8% времени. Остальные 92% - простой. При hourly-оплате облачных ресурсов это ещё и прямые финансовые потери. Переход к модели, где агент работает непрерывно, а человек подключается только для стратегических решений, меняет экономику разработки. Подробнее о когнитивных ловушках такого дисбаланса - в разборе рисков внедрения code-агентов.

Задача инженера смещается с написания кода на оркестровку агентов. Вы проектируете конвейер, по которому задача проходит от постановки до мёрджа в main без вашего участия. Четыре подхода ниже - это элементы такого конвейера.

Подход 1: Выдача агенту всех разрешений с sandbox-защитой

Установка пакетов, изменение конфигурационных файлов, запуск сервисов - многие задачи требуют привилегий выше пользовательских. Давать агенту root на основной машине неприемлемо по соображениям безопасности. Решение - изолированное окружение, где агент получает полные права внутри контейнера, но не может повлиять на хост-систему.

Docker-контейнер с ограниченным доступом к файловой системе и сети - минимально достаточный уровень изоляции для большинства сценариев. Для задач с повышенными требованиями к безопасности используют микровиртуальные машины Firecracker или gVisor. Песочница должна быть воспроизводимой: образ контейнера версионируется вместе с кодом проекта, что гарантирует идентичность окружения у всех членов команды.

Настройка Docker-контейнера для Claude Code: пошаговый пример

Создайте Dockerfile с базовым образом Ubuntu 22.04 и установите необходимые инструменты:

FROM ubuntu:22.04

RUN apt-get update && apt-get install -y \
    curl git build-essential python3 python3-pip nodejs npm \
    && rm -rf /var/lib/apt/lists/*

RUN useradd -m -s /bin/bash agent
USER agent
WORKDIR /home/agent/workspace

RUN curl -fsSL https://claude.ai/install.sh | bash

CMD ["tail", "-f", "/dev/null"]

Сборка и запуск с монтированием только рабочей директории проекта:

docker build -t claude-code-sandbox .
docker run -d --name claude-agent \
  --memory="4g" --cpus="2" \
  --network=none \
  -v $(pwd)/project:/home/agent/workspace \
  claude-code-sandbox

Флаг --network=none отключает сетевой доступ - агент не сможет отправить данные вовне. Если сеть нужна для установки зависимостей, используйте --network=bridge с файрволом на уровне iptables. Подключение к агенту - через docker exec или API-эндпоинт, проброшенный на localhost. Для production-сценариев обвязка агента заслуживает отдельного внимания - архитектурный разбор пяти harness показывает, что смена обвязки влияет на результат в 7.8 раза сильнее, чем смена модели.

Обход блокировок Codex при работе с низкоуровневым доступом

Codex применяет жёсткие политики безопасности, блокируя запись в /etc, использование sudo и операции, требующие root, даже внутри изолированного контейнера. Пользователи сообщают о блокировках легитимных задач на собственных устройствах, не связанных с кибербезопасностью. Три обходных пути:

• User namespaces: запуск контейнера с флагом --userns-remap, где root внутри контейнера мапится на непривилегированного пользователя хоста. Codex видит uid 0 внутри, но реальных прав на хосте нет.
• Запуск от пользователя с uid 0 внутри контейнера: в Dockerfile указать USER root и настроить --cap-drop=ALL --cap-add=SYS_ADMIN для минимально необходимых возможностей.
• Смена инструмента для низкоуровневых задач: Claude Code менее агрессивен в блокировках, чем Codex. Для задач, требующих плотной работы с системой, переключение на Claude Code в sandbox-окружении снимает проблему.

Риск остаётся: агент с root внутри контейнера может попытаться эксплуатировать уязвимости ядра для выхода из изоляции. Регулярное обновление Docker и ядра хоста - обязательное условие.

Подход 2: Автоматическая верификация работы агента

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

Методы верификации делятся на две категории: детерминированные (unit-тесты, линтеры, проверка типов) и эвристические (сравнение скриншотов, perceptual diff, семантическая проверка вывода). Первые дают однозначный бинарный результат, вторые требуют настройки порогов чувствительности.

Интеграция автотестов в цикл работы Claude Code

Claude Code поддерживает кастомные хуки, срабатывающие после генерации кода. Настройте запуск pytest через .claude/hooks/post_generate.sh:

#!/bin/bash
pytest tests/ -q --tb=short > /tmp/test_result.txt 2>&1
EXIT_CODE=$?
if [ $EXIT_CODE -ne 0 ]; then
  echo "TESTS_FAILED"
  cat /tmp/test_result.txt
else
  echo "TESTS_PASSED"
fi

Результат передаётся обратно в промпт агента. При падении тестов агент видит полный вывод pytest и может целенаправленно исправить ошибки. Важно ограничить число циклов «генерация-тест-исправление» тремя итерациями - если за три попытки тесты не прошли, задача эскалируется разработчику. Бесконечный цикл самопочинки без контроля приводит к деградации качества.

Визуальная верификация: сравнение скриншотов для UI-задач

Для фронтенд-изменений unit-тестов недостаточно - вёрстка может сломаться визуально при корректном DOM. Инструменты визуальной регрессии решают эту проблему. Подход: агент делает скриншот изменённой страницы через headless-браузер и сравнивает с эталонным изображением.

Пример скрипта на Puppeteer с использованием resemble.js для попиксельного сравнения:

const puppeteer = require('puppeteer');
const resemble = require('resemblejs');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('http://localhost:3000');
  await page.screenshot({ path: 'current.png', fullPage: true });
  await browser.close();

  resemble('current.png')
    .compareTo('baseline.png')
    .ignoreColors()
    .onComplete(data => {
      console.log(JSON.stringify({ 
        match: data.misMatchPercentage < 1.0,
        diffPercent: data.misMatchPercentage 
      }));
    });
})();

Порог в 1% допустимых отличий отсекает шум антиалиасинга, но ловит реальные изменения вёрстки. Эталонные скриншоты обновляются при сознательном изменении дизайна и хранятся в репозитории. Для более сложных сценариев - например, когда агент работает не только с кодом, но и с документацией, скриншотами и логами - полезны инструменты вроде Koda Desktop, которые расширяют возможности агента за пределы IDE.

Подход 3: Agentic code review - когда агенты проверяют друг друга

Один агент генерирует код, второй - ревьюит. Схема устраняет субъективность человеческого ревью и работает 24/7 без усталости. Агент-ревьюер получает дифф изменений и проверяет его по заданным критериям: корректность типов, покрытие тестами, отсутствие секретов, соответствие архитектурным паттернам, потенциальные уязвимости.

Затраты на инференс удваиваются, но для проектов, где цена бага высока, это оправдано. Комбинирование разных моделей для генерации и ревью даёт дополнительный уровень независимости оценки. Claude Code как генератор и Codex как ревьюер - или наоборот - снижает риск систематических ошибок, свойственных одной модели.

Реализация agentic code review с Claude Code и Codex в связке

Оркестратор на Python управляет двумя сессиями. Claude Code генерирует код в изолированной workspace-директории, затем оркестратор передаёт дифф в сессию Codex с промптом ревьюера:

import subprocess, json

def generate_code(task_prompt):
    result = subprocess.run(
        ['claude', 'generate', '--prompt', task_prompt, '--workspace', '/tmp/agent_workspace'],
        capture_output=True, text=True
    )
    return result.stdout

def review_code(diff):
    review_prompt = f"""Review this diff for bugs, security issues, 
and style violations. Output JSON with fields: 
approved (bool), issues (list of strings).

Diff:
{diff}"""
    result = subprocess.run(
        ['codex', 'review', '--prompt', review_prompt],
        capture_output=True, text=True
    )
    return json.loads(result.stdout)

# Main loop
task = "Implement user authentication with JWT"
code = generate_code(task)
diff = get_git_diff('/tmp/agent_workspace')
review = review_code(diff)

if not review['approved']:
    fix_prompt = f"Fix these issues: {review['issues']}"
    code = generate_code(fix_prompt)

Передача кода между агентами идёт через файловую систему - оба работают в одной смонтированной директории. Для изоляции каждая сессия запускается в отдельном контейнере, а workspace расшаривается через Docker volume.

Настройка критериев приёмки для агента-ревьюера

Чёткий checklist в формате YAML, передаваемый в промпт ревьюера, делает проверку предсказуемой и воспроизводимой:

review_rules:
  types:
    - no "any" type unless explicitly justified
    - all function signatures have return types
  security:
    - no hardcoded secrets, API keys, or tokens
    - all user input is sanitized
  testing:
    - new functions have corresponding unit tests
    - coverage does not decrease
  architecture:
    - no circular dependencies between modules
    - new code follows existing layer boundaries
  style:
    - naming follows project conventions
    - no commented-out code blocks

Агент-ревьюер возвращает структурированный JSON с вердиктом и списком замечаний. При approved=false генератор получает конкретные указания на исправление, а не размытое «переделай». Это сокращает число итераций и повышает итоговое качество.

Подход 4: Удалённый запуск на постоянно включённой машине

Локальный ноутбук уходит в сон, теряет соединение, перезагружается. Для непрерывной 24/7-работы агент должен жить на сервере. Три варианта размещения: облачный инстанс (AWS EC2, Hetzner Cloud), дешёвый VPS за 5-7 долларов в месяц, домашний сервер или одноплатник. Каждый вариант даёт агента, доступного по SSH в любой момент.

tmux или screen сохраняют сессию при обрыве SSH-соединения. Агент продолжает работу, даже если вы отключились. Настройка мониторинга через healthcheck-эндпоинт или лог-файл позволяет вовремя заметить зависание или падение агента и автоматически перезапустить его.

Облачный воркер для Claude Code: от $5 в месяц

Сравнение минимальных конфигураций, достаточных для работы кодинг-агента:

Hetzner CX22 покрывает потребности большинства задач. Для ресурсоёмких операций (полная сборка крупного проекта, прогон интеграционных тестов) берите CX32 с 8 GB RAM. Spot-инстансы Google Cloud снижают стоимость до $3-4 в месяц, но могут быть отозваны в любой момент - подходит для некритичных фоновых задач.

Базовая настройка инстанса:

ssh root@your-server-ip
apt update && apt install -y curl git tmux build-essential
curl -fsSL https://claude.ai/install.sh | bash
tmux new -s claude-agent
claude start --workspace /opt/project

После отсоединения от tmux (Ctrl+B, D) агент продолжает работу. Повторное подключение: tmux attach -t claude-agent. Для автоматического перезапуска при падении добавьте в crontab проверку каждые 5 минут.

Мобильный хостинг: Claude Code на Android через Termux

Проект LocalAI-Mobile демонстрирует возможность запуска Claude Code-подобного агента на Android-смартфоне. Termux предоставляет Linux-окружение с доступом к пакетному менеджеру, а root-права на устройстве открывают полный контроль над системой.

Плюсы: мобильность, сверхнизкое энергопотребление (3-5 Вт против 50-150 Вт у сервера x86), встроенный аккумулятор как UPS. Минусы: производительность ограничена ARM-процессором, нагрев при длительной нагрузке, износ флеш-памяти при интенсивной записи. Для лёгких задач - генерация скриптов, ревью небольших диффов, работа с конфигурациями - производительности флагманского смартфона достаточно. Полноценная сборка крупного проекта на Android займёт кратно больше времени, чем на сервере.

Установка Termux и базовых зависимостей:

pkg update && pkg upgrade
pkg install git curl python nodejs tmux
termux-setup-storage  # дать доступ к файловой системе

Локальное шифрование AES-256, заявленное в LocalAI-Mobile, защищает данные проекта на устройстве. Для продакшен-задач такой подход остаётся экспериментальным, но как персональный 24/7-ассистент для мелких задач - вполне рабочий вариант.

Сравнение подходов: когда что выбирать

Комбинирование подходов даёт максимальный эффект. Типичная production-связка: агент запущен в Docker-контейнере на Hetzner VPS, после каждой итерации прогоняются автотесты, раз в час второй агент выполняет ревью накопившихся изменений. Человек подключается только при эскалации - когда три цикла исправлений не решили проблему.

Выбор стартового подхода зависит от текущей боли. Если агент часто ломает окружение - начните с sandbox. Если тонет в багах после генерации - встройте автотесты. Если код проходит тесты, но архитектурно деградирует - добавьте agentic review. Если агент простаивает, пока вы спите - перенесите его на сервер. Сдвиг роли разработчика от написания кода к оркестровке агентов - долгосрочный тренд, подробно разобранный в материале о личных ИИ-агентах как новом классе инструментов.

Типичные проблемы и их решение

Длительная работа агентов вскрывает баги, незаметные при коротких сессиях. Три частые проблемы и конкретные способы их решения.

Искажение текста в Claude Code на macOS: причины и обходные пути

Пользователи macOS на ARM-процессорах (Apple Silicon) сообщают о случайных искажениях текста в терминале: смещение курсора, появление мусорных символов, нарушение форматирования вывода. Issue #11497 в репозитории Eugeny/tabby подтверждает проблему на macOS arm64 25.6.0. Корень проблемы - в особенностях рендеринга терминала при интенсивном потоке вывода от агента.

Три обходных пути:

• Смена эмулятора терминала: iTerm2 с отключённым GPU-рендерингом (Preferences → General → GPU Rendering → Disable) показывает меньше артефактов, чем встроенный Terminal.app.
• tmux как прослойка: запуск Claude Code внутри tmux-сессии даже на локальной машине изолирует рендеринг от терминала-хоста и устраняет большинство искажений.
• Полный переход на Linux-сервер для длительных задач: проблема специфична для macOS. На Ubuntu 22.04/24.04 искажений не наблюдается. Для сессий дольше 8 часов это самый надёжный вариант.

Как предотвратить деградацию качества кода с течением времени

Контекстное окно агента ограничено. После 4-6 часов интенсивной работы история диалога раздувается, и агент начинает терять нить задачи: забывает начальные требования, игнорирует краевые случаи, повторяет уже исправленные ошибки. Это не баг, а фундаментальное ограничение архитектуры transformer-моделей.

Стратегии борьбы с деградацией:

• Разбиение большой задачи на атомарные подзадачи. Вместо «напиши весь модуль аутентификации» - «добавь модель User», «реализуй хеширование паролей», «напиши middleware проверки JWT». Каждая подзадача - новая сессия с чистым контекстом.
• Внешняя память через векторную базу данных. Ключевые решения, архитектурные соглашения и результаты предыдущих итераций сохраняются в ChromaDB или Qdrant. При старте новой сессии агент получает релевантный контекст из базы, а не полагается на историю диалога.
• Принудительный перезапуск сессии по расписанию. Каждые 3-4 часа cron завершает текущую сессию, фиксирует достигнутый результат в git и запускает новую с кратким summary того, что сделано и что предстоит.

Мониторинг логов - обязательный элемент. Настройте алерты на аномальный рост количества итераций на одну задачу, падение процента проходящих тестов и увеличение времени ответа агента. Эти метрики - ранние индикаторы деградации, позволяющие перезапустить агента до того, как он нагенерирует мусор.

Заключение: ваш первый 24-часовой кодинг-агент

Четыре подхода - sandbox-изоляция, автоматическая верификация, agentic code review и удалённый запуск - закрывают ключевые ограничения, не дающие агенту работать непрерывно. Каждый подход решает конкретную проблему: безопасность, качество, автономность и доступность.

Стартовый сценарий для первых 24 часов непрерывной работы: арендуйте Hetzner CX22 за $5 в месяц, установите Claude Code CLI в Docker-контейнере с ограниченной сетью, подключите pytest в качестве post-generation хука, настройте cron на ежедневный перезапуск сессии в 4 утра с коммитом результатов. Это базовая конфигурация, которую можно развернуть за вечер и которая даст агенту работать, пока вы спите.

Следующий шаг эволюции - агенты, выходящие за рамки IDE и работающие асинхронно с разными типами контента. Google Antigravity 2.0 и подобные инструменты показывают направление движения: автономные агенты без привязки к среде разработки, с планировщиком задач и JSON-хуками для интеграции в любые пайплайны. Переход к непрерывной работе агентов - эволюционный шаг, который кратно повышает продуктивность команды и меняет роль разработчика с исполнителя на архитектора автоматизированных конвейеров.

Подписаться на канал