Команда Codex CLI /new: как начать новый чат в том же сеансе

Слеш-команда Codex CLI /new применяется для начала нового чата в том же сеансе CLI без выхода из терминала. Она позволяет перейти к отдельной задаче, не закрывая Codex, не перезапуская оболочку и не смешивая новый запрос с длинной историей предыдущего диалога. Это особенно удобно, когда в одном рабочем сеансе нужно последовательно решать несколько независимых задач: сначала разбираться с ошибкой в API, затем обсуждать тесты, а после этого — просить Codex объяснить чужой конфигурационный файл.

/new начинает новый разговор, но не новый запуск терминала: вы сохраняете текущую рабочую среду CLI, однако получаете чистый контекст для следующей задачи.

Главная ценность команды заключается в разделении контекстов. Codex не обязан учитывать все прежние сообщения, решения и ограничения из старого диалога, когда вы переходите к новой теме. При этом вам не нужно закрывать приложение, заново переходить в каталог проекта или повторно запускать CLI. Ниже разберём, как работает /new, когда он действительно полезен, какие ошибки совершают пользователи и чем эта команда отличается от /clear, /fork и /resume.

Как использовать /new

Использование команды устроено максимально просто: в интерактивном режиме Codex CLI введите /new и отправьте её так же, как обычное сообщение. После этого CLI создаст новый чат в рамках текущего сеанса. Терминал останется открыт, текущая директория и доступные инструменты не исчезнут, а прежний диалог перестанет быть рабочим контекстом нового чата.

Перед вводом /new полезно проверить, не осталось ли в старом диалоге незавершённой задачи: новый чат отделяет контекст, но не заменяет сохранение важных результатов.

В типичном сценарии последовательность выглядит так:

1. Запустите Codex CLI в нужном каталоге проекта.
2. Обсудите и выполните первую задачу.
3. Убедитесь, что важные изменения сохранены, зафиксированы или скопированы.
4. Введите /new.
5. В новом чате сформулируйте следующую задачу, добавив необходимые файлы, ограничения и ожидаемый результат.

Действие	Что происходит	Что сохраняется	Что не переносится автоматически
Ввод /new	Создаётся новый чат в текущем сеансе Codex CLI	Работающий CLI, каталог проекта, настройки сеанса и доступные инструменты	История сообщений и смысловые договорённости старого чата
Отправка нового запроса	Codex начинает обработку в новом контексте	Файлы на диске и состояние репозитория	Автоматическое понимание решений из предыдущего разговора
Выход из CLI	Интерактивный сеанс завершается	Сохранённые на диске данные и доступные механизмы восстановления	Неподтверждённые планы и несохранённые выводы

Важно различать состояние чата и состояние проекта. Команда /new меняет прежде всего разговорный контекст. Она не откатывает файлы, не отменяет изменения в Git и не удаляет созданные Codex артефакты. Если предыдущая задача изменила код, эти изменения по-прежнему находятся в рабочем дереве проекта и могут повлиять на новую работу.

Вы: Проверьте причину падения теста авторизации и предложите исправление.
Codex: Анализирует тест, код и зависимости...

Вы: /new
Вы: Теперь отдельно объясни, как устроена система логирования в этом проекте.

После запуска нового чата не стоит писать слишком короткий запрос вроде «продолжи» или «сделай это». Для нового диалога такие фразы лишены прежней опоры. Лучше заново назвать цель, указать файл или каталог и описать ожидаемый результат. Это занимает несколько секунд, но снижает риск того, что Codex начнёт угадывать контекст.

После /new желательно указать	Пример
Цель	«Найди причину медленного запуска приложения»
Область работы	«Проверь каталог src/worker и конфигурацию очереди»
Ограничения	«Не меняй публичный API и не добавляй новые зависимости»
Формат результата	«Сначала дай анализ, затем предложи патч»

Когда применять /new

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

Хорошее правило: если вы не хотите, чтобы ответ на новую задачу зависел от предыдущих сообщений, используйте отдельный чат через /new.

Чаще всего команда помогает в следующих ситуациях:

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

Ситуация	Почему подходит /new	Что написать после команды
Завершили исправление бага и перешли к документации	Задачи имеют разную цель и разные критерии качества	«Подготовь README для запуска сервиса»
Долго обсуждали один вариант архитектуры	Новый чат помогает получить более независимую оценку	«Предложи три альтернативы архитектуры без опоры на предыдущий план»
Нужно проверить другой участок проекта	Старый контекст может отвлекать и добавлять лишние предположения	«Проанализируй только модуль уведомлений»
Переключились между проектными ролями	Разговор о коде не смешивается с разговором о релизе	«Составь чек-лист подготовки версии к выпуску»

Есть и ситуации, в которых /new применять не стоит. Если вы хотите, чтобы Codex помнил договорённости, уже просмотренные файлы, принятые решения или промежуточные выводы, новый чат может оказаться слишком резким разрывом. В таком случае лучше продолжить текущий диалог или использовать команду, предназначенную для другой ветки общения.

Признак ситуации	Лучшее действие	Причина
Нужно уточнить уже предложенный патч	Продолжить текущий чат	Codex уже знает детали анализа
Нужно сохранить общий контекст, но попробовать другой путь	Использовать /fork	Новая ветка создаётся на основе существующего разговора
Нужно вернуться к старому завершённому обсуждению	Использовать /resume	Команда предназначена для восстановления прежнего чата
Нужно убрать текущую историю и начать с чистого листа	Рассмотреть /clear или /new	Выбор зависит от того, нужен ли новый чат как отдельная сущность

Не следует воспринимать /new как средство отката. Если после предыдущего запроса Codex изменил файл, новый чат не вернёт его к прежнему состоянию. Для контроля изменений используйте Git, резервные копии и просмотр diff. В противном случае можно получить неожиданную комбинацию: разговор уже новый, а код в рабочем каталоге всё ещё содержит результаты старой задачи.

Вы: Внеси изменения в обработчик платежей.
Codex: Изменения внесены в src/payments/handler.ts.

Вы: /new
Вы: Проанализируй модуль отчётов.

Важно: новый чат не отменил правки в src/payments/handler.ts. Перед следующей задачей проверь git diff.

Как подготовить новый чат к работе

Сам по себе /new создаёт чистую точку общения, но качество результата зависит от первого запроса. Новый чат не означает, что Codex автоматически поймёт ваши цели, приоритеты и границы изменений. Чем точнее стартовая формулировка, тем меньше уточнений потребуется позднее.

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

Удобно строить первый запрос по простой схеме:

1. Задача: что нужно получить или изменить.
2. Объект: какие файлы, команды, сервисы или каталоги относятся к работе.
3. Ограничения: что запрещено менять, какие версии и стандарты нужно соблюдать.
4. Проверка: какие тесты, команды или критерии покажут, что работа выполнена.

Элемент запроса	Слабая формулировка	Более полезная формулировка
Цель	«Разберись с API»	«Найди, почему POST /orders возвращает 422 при пустом промокоде»
Область	«Посмотри проект»	«Проверь src/orders, схемы валидации и тесты API»
Ограничения	«Исправь аккуратно»	«Не меняй формат ответа для существующих клиентов»
Проверка	«Убедись, что работает»	«Запусти тесты заказов и добавь тест для пустого промокода»

Если новая задача связана с теми же файлами, полезно прямо сообщить об этом. Codex увидит состояние файловой системы, но ему не всегда очевидно, какие изменения появились недавно и считать ли их частью текущей работы. Фраза «учти уже существующие локальные изменения, но не перезаписывай их без необходимости» задаёт гораздо более безопасную рамку.

Вы: /new
Вы: В проекте уже есть локальные изменения, их нельзя терять. Проанализируй каталог src/reporting и исправь только ошибку формирования CSV. Сначала покажи, какие файлы планируешь изменить, затем запусти тесты reporting.

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

Практические примеры использования /new

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

Пример 1. Переход от исправления ошибки к документации

В первом сценарии техническая задача уже завершена, а следующая относится к документации. Разделение полезно, потому что при написании README прежний разговор о причинах бага не должен занимать внимание Codex.

Вы: Исправь ошибку в обработке тайм-аута HTTP-клиента и добавь регрессионный тест.
Codex: Анализирует код, вносит изменения и запускает тесты.

Вы: /new
Вы: Подготовь раздел README «Локальный запуск». Опиши требования, установку зависимостей, переменные окружения и команду запуска. Не упоминай внутренние детали исправления тайм-аута.

Пример 2. Независимое исследование другого модуля

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

Вы: /new
Вы: Исследуй, как в проекте обрабатываются сообщения из RabbitMQ. Найди точку входа, механизм повторных попыток, обработку dead-letter очереди и существующие тесты. Пока ничего не изменяй, сначала составь карту потока данных.

Пример 3. Второе мнение по архитектуре

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

Вы: /new
Вы: Нужно спроектировать кэширование результатов поиска для сервиса на Python. Предложи минимум три варианта: in-memory, Redis и кэширование на уровне базы данных. Сравни задержку, согласованность, сложность эксплуатации и поведение при сбое. Не выбирай вариант заранее.

Пример 4. Переход от кода к подготовке релиза

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

Вы: /new
Вы: Составь чек-лист релиза версии 2.8 для этого проекта. Проверь миграции базы данных, обратную совместимость API, переменные окружения, healthcheck, логи и план отката. Если в репозитории не хватает информации, перечисли вопросы, а не придумывай ответы.

Пример 5. Учебный разбор без влияния рабочего диалога

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

Вы: /new
Вы: Объясни простыми словами файл src/cache/eviction.ts. Сначала расскажи, какую проблему решает алгоритм вытеснения, затем разберись с каждой функцией и приведи небольшой пример с пятью элементами кэша. Код не меняй.

Пример 6. Проверка локальных изменений после нового чата

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

Вы: /new
Вы: Проверь текущий git diff. Найди потенциальные регрессии, проблемы с обработкой ошибок и тесты, которых не хватает. Ничего не изменяй и не запускай команды, которые могут модифицировать файлы. В конце расставь замечания по уровню риска.

Пример 7. Смена области внутри большого монорепозитория

В монорепозитории легко потерять фокус: предыдущий разговор мог быть посвящён фронтенду, а следующий — инфраструктурному пакету. Указание конкретного пути после /new помогает ограничить область анализа.

Вы: /new
Вы: Работай только с пакетом packages/cli-config. Объясни, как наследуются настройки ESLint, где задаются значения по умолчанию и почему конфигурация тестов отличается от production. Остальные пакеты пока не анализируй.

Пример 8. Повторная формулировка задачи после неудачного диалога

Если разговор стал слишком длинным, в нём появились противоречивые требования или Codex начал опираться на устаревшие предположения, новый чат помогает начать обсуждение заново. При этом полезно кратко описать только актуальное состояние задачи.

Вы: /new
Вы: Актуальная задача: устранить дублирование запросов при открытии страницы профиля. Игнорируй прежние варианты решения и самостоятельно изучи текущий код, сетевые вызовы и тесты. Сначала объясни причину дублирования, затем предложи минимальное исправление.

Пример 9. Подготовка миграции базы данных

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

Вы: /new
Вы: Спроектируй миграцию для добавления индекса по user_id в таблицу events. Проверь схему, объём потенциально затронутых данных и используемый инструмент миграций. Укажи риски блокировки и способ безопасного отката. Файлы пока не изменяй.

Пример 10. Подготовка тестового плана

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

Вы: /new
Вы: Составь тестовый план для перехода с синхронного обработчика задач на асинхронный. Раздели проверки на модульные, интеграционные, нагрузочные и проверки отказоустойчивости. Для каждого пункта укажи ожидаемый результат и возможный риск.

Цель примера	Почему выбран отдельный чат	Ключевое ограничение
Документация	Не требуется переносить детали отладки	Описывать актуальный способ запуска
Исследование RabbitMQ	Нужно начать с независимой карты системы	Не изменять файлы на первом этапе
Архитектурное мнение	Важно не навязывать прежний вариант	Сравнить несколько альтернатив
Релизный чек-лист	Фокус переносится с кода на эксплуатацию	Не выдумывать отсутствующие сведения
Учебный разбор	Нужен чистый объяснительный контекст	Не менять исходный файл

Чем /new отличается от других команд

В Codex CLI несколько слеш-команд могут казаться похожими, потому что все они так или иначе меняют текущий разговор. Однако их назначение различается: /new создаёт новый чат, /clear очищает текущий контекст, /fork создаёт ответвление существующего диалога, а /resume возвращает пользователя к старому сеансу или разговору.

Разница сводится к вопросу: нужно ли начать с нуля, очистить текущий экран или сохранить связь с уже существующей историей.

Команда	Основное назначение	Связь с текущей историей	Когда выбирать
/new	Начать новый чат	Старый разговор не используется как текущий контекст	Новая независимая задача
/clear	Очистить текущий интерфейс или историю текущего разговора в зависимости от версии CLI	Не создаёт отдельную смысловую ветку	Нужно убрать текущий контекст и остаться в том же рабочем сеансе
/fork	Создать ответвление существующего диалога	Новая ветка наследует основу старой	Нужно попробовать альтернативное решение
/resume	Продолжить ранее сохранённый чат или сеанс	Старая история возвращается в работу	Нужно вернуться к незавершённой задаче

/new и /clear

Команды /new и /clear обе могут восприниматься как «начать чисто», но смысл у них разный. /new предназначена именно для начала нового чата. /clear обычно воспринимается как очистка текущего разговора или интерфейса; конкретное поведение может зависеть от версии Codex CLI, поэтому при обновлении инструмента стоит сверяться с актуальной документацией.

Практически это можно представить так: /clear похожа на уборку текущего рабочего стола, а /new — на открытие отдельной папки для нового дела. В обоих случаях перед глазами становится меньше старой информации, но модель управления историей и идентичность разговора могут отличаться.

Критерий	/new	/clear
Главная идея	Новый чат	Очистка текущего контекста или интерфейса
Подходит для независимой задачи	Да	Да, если не требуется отдельная ветка
Сохраняет связь с прежним разговором	Нет как с текущим контекстом	Зависит от реализации и версии
Что проверить после команды	Нужно заново описать цель	Нужно убедиться, что старый контекст действительно очищен

/new и /fork

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

/new, напротив, намеренно не опирается на ход прежнего обсуждения. Поэтому команда лучше подходит для независимой задачи, а /fork — для эксперимента внутри той же задачи. Если после нового чата вам приходится заново пересказывать десятки условий, вероятно, нужен не /new, а /fork.

Сценарий с /fork:
Вы: Мы решили использовать Redis для кэширования профилей.
Вы: /fork
Вы: Рассмотри альтернативу на базе локального кэша с TTL и сравни её с предложением из исходного диалога.

Не то же самое: /new начнёт независимый разговор, где решение про Redis придётся описать заново.

Вопрос	Выбор /new	Выбор /fork
Нужно ли сохранить предыдущие аргументы?	Нет	Да
Нужно ли сравнить альтернативы в одной предметной области?	Не лучший вариант	Да
Нужно ли полностью сменить тему?	Да	Нет, обычно ветка остаётся связанной
Риск влияния прежних предположений	Ниже	Выше, поскольку история переносится

/new и /resume

/resume решает противоположную задачу: не разрывает связь с прежним обсуждением, а помогает вернуться к ранее начатому чату. Это удобно, если работа была прервана, терминал закрыт или нужно восстановить контекст задачи, которую вы пока не завершили.

Если вы возвращаетесь к старому диалогу, используйте /resume. Если вы хотите оставить старый разговор в стороне и начать независимую работу, используйте /new. Иногда эти команды применяются последовательно: сначала пользователь возобновляет старую задачу, сохраняет результат, затем создаёт новый чат для следующей части работы.

Ситуация	Команда	Ожидаемый результат
Вчера не закончили анализ ошибки	/resume	Возврат к прежнему обсуждению
Сегодня нужно начать отдельное ревью	/new	Новый контекст без старой переписки
Нужно сравнить два решения одной проблемы	/fork	Ветка на основе уже изученной задачи
Нужно убрать текущую историю или экран	/clear	Очистка согласно поведению установленной версии CLI

Новый чат, очистка интерфейса и состояние файлов

Отдельно стоит подчеркнуть: ни одна из этих команд не должна рассматриваться как универсальная команда управления файлами. /new, /clear, /fork и /resume управляют прежде всего взаимодействием и историей чатов. Они не заменяют git checkout, git restore, создание коммита или резервное копирование.

Что нужно изменить	Подходящий инструмент	Почему
Контекст разговора	/new, /clear, /fork, /resume	Это команды управления чатами
Содержимое файла	Codex, редактор или команды проекта	Файл меняется отдельно от истории сообщений
Историю изменений кода	Git	Git фиксирует версии и показывает diff
Состояние базы данных	Миграции и инструменты БД	Чат не отменяет выполненную миграцию
Сохранение важного результата	Коммит, патч, документ или заметка	Нужна явная фиксация, а не надежда на историю диалога

Типичные ошибки при использовании /new

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

Самая частая ошибка — считать, что новый чат очищает только экран, но сохраняет все смысловые договорённости. Для надёжной работы исходите из обратного: после /new важный контекст нужно сообщить заново.

Ошибка	К чему приводит	Как исправить
«Продолжи» сразу после /new	Codex не знает, что именно продолжать	Сформулировать цель и указать нужные файлы
Ожидание отката изменений	Файлы остаются изменёнными	Проверить git diff и использовать Git для отката
Смешивание старой и новой задачи	В запросе остаются противоречивые требования	Начать новый чат и перечислить только актуальные условия
Использование /new вместо /fork	Теряется полезный анализ предыдущей ветки	Создать ответвление, если нужен общий контекст
Передача секретов в новом запросе	Чувствительные данные попадают в историю	Удалить секреты и использовать безопасные placeholders

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

Перед /new:
1. Проверить git diff.
2. Сохранить важный вывод или патч.
3. Убедиться, что следующая задача действительно независима.
4. В новом сообщении указать цель, область и ограничения.

После /new:
«Проанализируй только src/search. Не меняй публичные интерфейсы. Сначала покажи план проверки».

Рекомендации для эффективной работы

/new раскрывает свои преимущества не как изолированная команда, а как часть аккуратного рабочего процесса. Чем больше проект и длиннее задачи, тем важнее разделять исследование, реализацию, ревью и выпуск. У каждого этапа свои вопросы, и отдельные чаты помогают не превращать весь сеанс в один бесконечный разговор.

Для повседневной работы можно использовать такой порядок:

1. В одном чате исследовать проблему и уточнить требования.
2. Зафиксировать решение в коде, документе, issue или заметке.
3. Проверить изменения средствами Git и тестами.
4. Ввести /new, если следующая задача независима.
5. В новом чате дать Codex краткое, но самодостаточное описание задачи.
6. Если нужно продолжить старую тему, выбрать /resume, а если нужна альтернативная ветка — /fork.

Этап работы	Рекомендуемый чат	Что зафиксировать перед переходом
Исследование	Текущий чат	Причина проблемы, найденные файлы и гипотезы
Реализация	Текущий чат или /fork	Выбранный вариант и ограничения
Независимое ревью	/new	Путь к изменениям и критерии проверки
Возврат к незавершённой работе	/resume	Последний известный статус задачи
Новая альтернатива в той же задаче	/fork	Что именно нужно сравнить

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

Хорошее разделение сеанса:
Чат 1: «Найди причину падения тестов».
Чат 2: /new → «Реализуй исправление и добавь тест».
Чат 3: /new → «Проведи независимое ревью diff».
Чат 4: /new → «Обнови документацию по изменённому поведению».

Плохой вариант:
Один чат одновременно обсуждает базу данных, CSS, релиз, логи и тексты ошибок.

Если сомневаетесь между двумя командами, задайте себе один вопрос: нужно ли сохранить смысловую связь с текущим диалогом? Если нет — выбирайте /new. Если да, определите характер связи: продолжение старого разговора указывает на /resume, альтернативный путь в той же задаче — на /fork, а простая очистка текущего контекста или интерфейса — на /clear.

Ваше намерение	Команда	Короткая формула
Начать самостоятельную тему	/new	«Старый разговор больше не нужен»
Убрать текущую переписку или очистить интерфейс	/clear	«Хочу очистить текущее рабочее пространство»
Проверить другой вариант на базе обсуждённого	/fork	«Сохрани исходный анализ, но создай альтернативу»
Вернуться к прерванной задаче	/resume	«Продолжи старый разговор»

Итоги

Слеш-команда Codex CLI /new нужна для создания нового чата без выхода из текущего сеанса терминала. Она помогает отделить независимые задачи, уменьшить влияние устаревшей истории и поддерживать порядок в длительной работе с проектом. При этом команда не откатывает файлы, не удаляет изменения Git и не переносит автоматически договорённости из прежнего диалога.

Используйте /new для смены смыслового контекста, а не для управления версиями файлов. Историю кода храните в Git, а важные решения фиксируйте в документации, issue или заметках.

Для выбора подходящей команды достаточно запомнить четыре различия:

• /new — новый независимый чат;
• /clear — очистка текущего интерфейса или контекста в соответствии с поведением установленной версии CLI;
• /fork — ответвление существующего диалога с сохранением его основы;
• /resume — возвращение к ранее начатому разговору.

Если после команды вы заново сформулировали цель, указали область работы, обозначили ограничения и описали способ проверки результата, новый чат становится не просто «чистым экраном», а полноценным инструментом организации разработки. В этом и состоит практический смысл /new: не начинать всё заново технически, а начинать заново только там, где это действительно нужно — в контексте разговора.