Claude Code Projects: как настроить проект и облачные потоки

Claude Code Projects превращает один постоянный диалог в центр управления потоком задач разработки: координатор запускает отдельные облачные потоки для каждой задачи и следит за их выполнением. Главное преимущество — не дополнительные окна чата, а меньше времени на повторное описание репозитория, ручной запуск сессий и поиск ветки или пул-реквеста, который ждёт вашего внимания.

Обновлённый интерфейс начали развёртывать 17 сентября 2026 года, и доступ к нему пока получают не все. В этом руководстве разберём, как проверить свой аккаунт, подготовить один временный репозиторий, отправить две независимые задачи, проверить результат и точно понять, какой контекст получает каждый поток.

Claude Code Projects — координатор, а не папка

Проект Claude Code — это один постоянный диалог с Claude и запущенные из него облачные сессии-потоки. Представьте, что диалог — это начальник цеха: вы передаёте ему техническое задание, а отдельные рабочие участки берут на себя конкретные части работы. У каждого участка своё рабочее пространство, контекстное окно и ветка Git; начальник получает отчёты и поддерживает порядок в очереди.

Это не то же самое, что прежние Projects в чате Claude и Cowork. Раньше Projects лишь объединяли диалоги и справочные файлы. Новая бета-версия Claude Code Projects добавляет координатора: он распределяет работу между облачными потоками, отслеживает их состояние и передаёт контекст проекта в каждый новый поток.

Каждый поток получает репозитории и файлы проекта, инструкции, память, выбранное облачное окружение, коннекторы аккаунта, а также файлы CLAUDE.md, навыки и плагины из подключённых репозиториев. Инструменты, установленные только на вашем компьютере, в потоки не передаются.

Если подходящий тариф Claude уже оплачен, финансовая сторона выглядит привлекательно. Claude Pro стоит $20 в месяц или $17 в месяц при ежегодной оплате $200, а Max — от $100 в месяц. Отдельной платы за облачные виртуальные машины в Projects нет. Но есть нюанс: каждый поток представляет собой полноценную сессию Claude Code, поэтому параллельная работа быстрее расходует лимиты тарифа.

Для сравнения: индивидуальные подписки на ИИ-агентов для программирования, проверенные при подготовке этого материала, стоят от $10 до $200 в месяц у GitHub Copilot и Cursor. Если Claude уже используется как агент для программирования, Projects — не ещё одно рабочее место в вашем наборе. Этот продукт меняет способ координации, но не заменяет инженерные решения.

Сначала проверьте, доступна ли бета-версия в вашем аккаунте

Одного упоминания функции Projects где-либо в Claude недостаточно.

1. Войдите в аккаунт Claude Pro или Max.
2. Откройте claude.ai/code либо вкладку Code в настольном приложении.
3. Найдите пункт Projects на левой боковой панели.
4. Если его нет, ваш аккаунт ещё не попал в программу развёртывания. Запишитесь в список ожидания Anthropic, а пока пользуйтесь обычными облачными сессиями.

В первую волну преимущественно попадают аккаунты Pro и Max, которые уже работали с облачными сессиями и не используют прежнюю версию Projects в чате Claude или Cowork. Аккаунтам Team и Enterprise новая бета-версия пока недоступна. Старые Projects продолжат работать, пока Anthropic переносит пользователей на обновлённый интерфейс.

Если Claude Code ещё не установлен, не авторизован или не настроен с помощью файла CLAUDE.md на уровне репозитория, начните с общего руководства по настройке Claude Code. Projects опирается на эти практики работы с репозиториями, а не заменяет их.

Как настроить первый проект на временном репозитории

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

1. Настройте доступ к GitHub до создания проекта

Для работы с кодом репозиторий должен находиться на github.com. Подключённому аккаунту GitHub нужен доступ на запись, а приложение Claude GitHub App должно быть установлено для этого репозитория. Токена, созданного через /web-setup, может хватить обычной облачной сессии для клонирования репозитория, но потоку проекта этого недостаточно.

GitHub Enterprise Server, GitLab и Bitbucket в этой бета-версии нельзя использовать как репозитории с кодом проекта. Если репозиторий принадлежит организации, её владельцу, возможно, придётся одобрить установку GitHub App и авторизацию SSO.

2. Создайте проект с узкими границами

Откройте Projects, нажмите New project и заполните поля:

• Name: явно временное название, например Parser Project Test.
• Goal: одно предложение, например Improve parser coverage and documentation without changing behavior.
• Context: добавьте только временный репозиторий.

Обязательное поле здесь только одно — название. Узкая цель задаёт координатору понятные рамки, а единственный репозиторий избавляет от различий в настройках, которые возникают в проектах с несколькими репозиториями.

3. Добавьте одну постоянную инструкцию

Откройте Project settings > Memory > Project instructions. Задайте для всех потоков одинаковые критерии готовности и границы допустимых действий. Например:

Начинай с ветки по умолчанию. Для каждого потока используй отдельную ветку. Перед отчётом о завершении запусти соответствующие тесты. Не выполняй слияние, не меняй CI и не добавляй зависимости без согласования в потоке. Если доступа не хватает, укажи, чего именно недостаёт, и остановись.

Инструкция проекта может содержать до 16,000 символов, однако для первого теста лучше сделать её короткой. Команды сборки, относящиеся к конкретному репозиторию, по-прежнему должны находиться в его CLAUDE.md. Требования, решения и обнаруженные ограничения, общие для проекта, следует сохранять в памяти проекта.

4. Проверьте облачное окружение

Откройте Project settings > Environment. Каждый новый поток будет использовать выбранное здесь окружение. Оно определяет сетевой доступ, переменные среды, учётные данные API и инструменты, которые устанавливает сценарий настройки.

Среда Anthropic по умолчанию имеет доступ к разрешённому списку распространённых сервисов и уже содержит некоторые инструменты. Но она не получает автоматически вашу локальную базу данных, VPN, эмулятор устройства, конфигурацию оболочки или учётные данные, хранящиеся только на ноутбуке. Прежде чем поручать работу, зависящую от этих ресурсов, настройте окружение.

5. Отправьте две задачи, которые не пересекаются

Поместите обе задачи в одно сообщение, чтобы увидеть, как координатор разделит несвязанную работу. Выберите разные файлы. Например:

Начни работу без дополнительного подтверждения. Создай один поток для добавления модульных тестов на некорректные входные данные парсера. Создай второй поток для исправления устаревших примеров в руководстве по API. Не меняй рабочее поведение парсера и не объединяй ни одну из веток.

По данным Anthropic, несколько несвязанных задач из одного сообщения превращаются в отдельные потоки. Если не указано иное, каждый поток с кодом создаёт ветку от ветки репозитория по умолчанию. Разделение по файлам важно: независимые ветки всё равно могут конфликтовать, если два потока меняют один и тот же код.

6. Проверяйте сами потоки, а не только сводку координатора

Откройте карточку каждого потока и зафиксируйте результаты:

В Overview задачи распределены по состояниям Ready for review, Waiting on you, Working, Landing, Idle и Resolved. В других вкладках собраны файлы проекта, пул-реквесты и регулярные задачи. Координатор получает отчёты потоков, но не видит каждый шаг, поэтому проверять выполненную работу нужно по полной истории конкретного потока.

7. Убедитесь, что следующая задача получает сохранённый контекст

Когда оба потока завершатся, попросите координатора запомнить одно безопасное правило, например Documentation changes must preserve every runnable example. Затем создайте новый небольшой поток с задачей по документации и попросите его до начала редактирования назвать правила проекта для веток и документации.

Так проверяются два разных пути передачи контекста. Инструкции проекта должны попадать в каждый новый поток как постоянное техническое задание. Сохранённое решение из памяти проекта должно передаваться через MEMORY.md. Файл CLAUDE.md репозитория остаётся третьим, отдельным уровнем для правил, относящихся непосредственно к кодовой базе.

Какой контекст получает поток, а что остаётся локальным

Проще всего ошибиться, если считать облачный поток удалённой копией ноутбука. Это не так. Каждый поток — новая облачная сессия, контекст которой собирается из настроек проекта, репозитория, аккаунта и окружения.

У проектов с несколькими репозиториями есть важная особенность. Из всех репозиториев загружаются файлы CLAUDE.md, навыки и плагины, но не правила разрешений, хуки и настройки env. Общие правила для нескольких репозиториев храните в инструкциях проекта, а переменные среды — в облачном окружении.

Параллельные потоки не означают неограниченное число потоков

Anthropic не указывает фиксированное число потоков, которые разрешено запускать одновременно. Координатора можно попросить вести две задачи параллельно, но это пожелание, а не принудительная квота. Отдельно действует жёсткое ограничение: 200 новых потоков в день суммарно по всем проектам.

Работающие потоки расходуют лимит тарифа. Координатор тоже расходует его, когда читает отчёты и определяет следующие действия. Поток, наблюдающий за пул-реквестом, снова активируется и расходует лимит при сбое CI или появлении комментария рецензента. Если в проекте нет работающих потоков, отслеживаемых пул-реквестов и новых сообщений, он ничего не расходует.

В новых проектах для потоков по умолчанию выбрана модель Opus с высоким уровнем усилий, а для координатора — с низким. Перед запуском большой группы задач откройте Project settings > General и выберите для каждой работы самую экономичную комбинацию модели и уровня усилий, которая с ней справится. Затем задайте небольшое число параллельных потоков. Важно не то, сколько потоков способен запустить Projects, а сколько результатов вы успеете проверить, прежде чем очередь превратится в шум.

Семь сценариев, в которых Projects особенно полезен

1. Руководитель платформенной команды координирует миграцию нескольких репозиториев

Подключите серверный, веб- и мобильный репозитории, затем задайте проекту единую цель — вывести из эксплуатации устаревший эндпоинт. Отдельные потоки смогут обновить каждого потребителя в собственных ветках, а координатор — отслеживать порядок работ и блокирующие проблемы. Вместо трёх вручную синхронизируемых сессий агента получится единая очередь на проверку. Это лучший сценарий для Projects: цель живёт дольше одной сессии, а работу легко разделить по репозиториям.

2. Мейнтейнер разбирает очередь ошибок одного сервиса

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

3. Ответственный за релиз запускает независимые проверки готовности

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

4. Руководитель рефакторинга делит крупное изменение по границам модулей

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

5. Инженер агентства сопровождает приложение клиента

Создайте отдельный закрытый проект для репозитория, инструкций и окружения конкретного клиента. На протяжении всего сотрудничества добавляйте туда небольшие исправления, запросы на проверку и задачи по документации. Так сохраняется непрерывный контекст, а данные разных клиентов не смешиваются. Во время бета-тестирования Projects принадлежит одному пользователю и не поддерживает совместный доступ, поэтому это личный центр управления работой, а не портал для взаимодействия с клиентом.

6. Руководитель службы поддержки анализирует повторяющиеся сбои интеграций

Для Projects репозиторий не обязателен. Загрузите экспорт обращений в поддержку и документацию по интеграции, затем поручите потокам классифицировать сбои, проверить примеры и подготовить план исправлений. Созданные ими файлы появятся в Library. В результате у команды будет единый переиспользуемый контекст проекта и отдельная доказательная база по каждой аналитической или редакционной задаче.

7. Основатель небольшого проекта разбирает смешанный бэклог

Отправьте небольшой набор из одной задачи по тестам, одной по документации и одного аудита репозитория. Ограничьте координатора двумя потоками и потребуйте заранее предлагать любые разрушительные изменения. Вместо постоянного наблюдения за каждой сессией основатель сможет сосредоточиться на проверке готовых веток. Но этот сценарий не подходит, если всем задачам нужен один файл или сервис, доступный только с ноутбука основателя.

Три сопутствующих продукта, которые стоит создать

У бета-версии нет документированного API для Projects, поэтому в ближайшей перспективе разумнее создавать продукты рядом с этим процессом. Они могут готовить контекст, проверять состояние GitHub или помогать человеку оценивать результат.

1. Project Readiness Auditor — самая сильная возможность

Создайте GitHub-приложение с доступом только для чтения, которое проверяет готовность репозитория к работе облачных агентов для программирования. Оно могло бы анализировать инструкции репозитория, команды тестирования, защиту веток, охват GitHub App, обязательные секреты и сетевые зависимости, а затем формировать черновик инструкций проекта и чек-лист облачного окружения.

Спрос на такое решение уже заметен: запрос “ai powered coding agent” получает 8,100 поисков в месяц в США и имеет коммерческий интент. Проверенные для этого материала официальные индивидуальные тарифы агентов для программирования стоят от $10 до $200 в месяц, однако сама по себе платная лицензия не делает репозиторий безопасным для параллельной работы облачных агентов.

Минимальная версия, которую можно продавать, сканирует один репозиторий GitHub, задаёт шесть вопросов об окружении и выдаёт готовое для вставки техническое задание. Главный риск связан с платформой: Anthropic или GitHub могут быстро встроить такие проверки, поэтому продукту нужны поддержка нескольких агентов и полезная история аудитов, а не один шаблон для Claude.

2. Доска жизненного цикла ИИ-разработки

Создайте доску на основе данных GitHub, которая группирует ветки, пул-реквесты, статусы CI, комментарии рецензентов и решения людей по общей цели поставки. Она пригодится техническому руководителю, который работает с несколькими агентами для программирования и хочет проверять всё в одном нейтральном интерфейсе.

Запрос “AI software development life cycle” получает 720 поисков в месяц в США, имеет сложность ключевого слова 4 и CPC $18.13. Минимальная версия читает события GitHub и распределяет их по четырём состояниям: в работе, заблокировано, готово и выпущено. Доступ к закрытой истории проекта Claude ей не нужен.

Сложность — выделиться среди конкурентов. GitHub и поставщики агентов уже показывают большую часть этих состояний. Продукт победит, только если объединит работу разных поставщиков, сохранит доказательства согласований и объяснит причину блокировки, а не просто нарисует более красивую очередь.

3. Автоматический маршрутизатор правил ревью

Создайте GitHub-приложение, которое применяет правила ревью конкретного репозитория к пул-реквестам, созданным агентами. Оно может требовать результат теста для изменений парсера, назначать указанного рецензента для изменений биллинга и не позволять комментариям автоматического исправления запускать привилегированную автоматизацию.

Запрос “Automated code review” получает 210 поисков в месяц в США, а его CPC составляет $63.33 — сильный признак того, что за небольшой аудиторией стоит дорогой коммерческий спрос. Для MVP достаточно файла политик, проверки пул-реквеста и краткого объяснения, каких доказательств не хватает.

Основная проблема — пересечение функций. Потоки Claude уже отслеживают пул-реквесты и реагируют на сбои CI и комментарии рецензентов. Новый продукт должен управлять риском сразу для разных агентов и репозиториев, а не имитировать ещё одного бота-рецензента.

Какие задачи Claude Code Projects не решает

Projects лучше всего работает, когда задачи можно разделить, а нужный контекст — разместить в GitHub, загруженных файлах, коннекторах или облачном окружении. Это неподходящий инструмент для разового исправления, которое помещается в одну сессию, для работы, привязанной к локальному устройству или VPN, и для команды, где нескольким людям нужно управлять одним проектом.

Обычные риски поставки Projects тоже не устраняет:

• Отдельные потоки могут создавать конфликты слияния, если их ветки пересекаются.
• Запрос на определённую параллельность — инструкция координатору, а не жёсткий контроль бюджета.
• Параллельные потоки могут быстро исчерпать лимиты Pro.
• При возобновлении приостановленной песочницы может использоваться свежий клон, поэтому незакоммиченная работа рискует потеряться.
• Бета-версия рассчитана на одного пользователя: в ней нет совместного доступа к проектам и средств управления на уровне организации.
• Позднее перенести поток в другой проект нельзя.

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

Часто задаваемые вопросы

Есть ли у Claude Code доступ к Projects?

Выбранные аккаунты Claude Pro и Max могут использовать обновлённую бета-версию Projects на claude.ai/code, во вкладке Code настольного приложения и в мобильных приложениях Claude. Если Projects нет на боковой панели Code, ваш аккаунт ещё не получил доступ. Команда терминала claude project управляет несвязанным с этой функцией состоянием локального каталога.

Как пользоваться Projects в Claude Code?

Создайте проект в Claude Code, добавьте цель и только необходимые репозитории или файлы, запишите короткую постоянную инструкцию, выберите облачное окружение и отправьте координатору одну или несколько задач. Откройте каждый поток в Overview и перед слиянием проверьте его ветку, историю, результаты проверок и расход лимита.

Может ли Claude Code работать с существующим проектом?

Да. Проект можно создать на основе существующего репозитория github.com или выбрать Continue as a project в уже запущенной облачной сессии. Для репозиториев с кодом нужен доступ на запись через подключённый аккаунт GitHub, а также установленное для них приложение Claude GitHub App.

Чем Projects отличается от Claude Code?

Claude Code — ИИ-агент для программирования, работающий в локальной или облачной сессии. Обновлённый проект Claude Code — уровень координации: один диалог запускает и отслеживает несколько облачных сессий Claude Code, передаёт им общий контекст проекта и собирает их статусы. Пока миграция не завершена, прежние Projects в чате Claude и Cowork остаются рабочими пространствами для файлов и диалогов.

Если вам нужен готовый к работе с агентами процесс, учитывающий ваши репозитории, согласования и облачное окружение, изучите системы ИИ для продакшена.