Фоновые процессы Codex в Windows: что оставить, а что завершить

Сам по себе фоновый процесс Codex в Windows не означает сбой. Оставьте дерево в покое, если им владеет активная задача, терминал, запуск по расписанию Codex или сеанс Computer Use. Проверка нужна, когда окно уже закрыто или не появляется, владельца работы нет, а процессы продолжают заметно обращаться к процессору или диску либо мешают получить пригодное окно после повторного запуска.

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

Сначала определите, кому принадлежит работа

Количество строк в Диспетчере задач почти ничего не говорит само по себе. Агент может запустить PowerShell, Git, тесты, языковую среду, браузерный инструмент или процесс внутри WSL2. Структура меняется вместе с версией приложения, проектом, выбранной средой и текущей задачей. OpenAI не публикует одно «нормальное» число процессов Codex для Windows.

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

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

Разберите симптом, а не название процесса

Активная задача или терминал

Генерация патча, тесты, команда Git, ожидание подтверждения и потоковый вывод терминала создают полезную работу. Принудительное завершение может оборвать запись файла, оставить частично выполненную внешнюю операцию или лишить вас ещё не сохранённого результата. Сначала отмените задачу или команду там, где она была запущена. Затем дождитесь состояния «завершено», «отменено», «ошибка» либо другого явного финала.

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

Запуск по расписанию Codex

В официальной документации Scheduled указано, что локальные запуски выполняются в фоне. Для них компьютер должен оставаться включённым, а настольное приложение Codex — работать. Поэтому фоновое дерево в момент расписания может быть ожидаемым, даже если вы не открывали обычную задачу вручную.

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

Не называйте эту функцию Планировщиком заданий Windows. Это запуск по расписанию, которым владеет Codex; его состояние и управление находятся в интерфейсе Codex.

Остаточное дерево после выхода

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

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

Запуск без пригодного окна

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

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

Продолжающаяся активность без владельца

Слово «простой» должно означать проверенное состояние: задача не выполняется, терминальная команда не идёт, запуск Scheduled не активен, Computer Use завершён. Сравните не один кадр, а состояние до и после остановки предполагаемого владельца. Короткий всплеск процессора или диска может быть индексированием, операцией Git, записью файла или обычным завершением.

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

Дочерняя оболочка выглядит осиротевшей

PowerShell, pwsh, conhost.exe, Node, Git, Python и WSL используются не только Codex. Та же программа может обслуживать IDE, локальный сервер, отдельный терминал или другую автоматизацию. Сначала проследите родительский процесс и время запуска. Завершать все процессы Node или PowerShell по имени на рабочей машине небезопасно.

Восстанавливайте Codex по безопасной лестнице

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

1. Сохраните работу. Скопируйте неотправленный запрос, сохраните нужный вывод терминала, убедитесь, что важные изменения записаны на диск. Если агент ещё создаёт патч, решите, позволить ли ему закончить или отменить задачу из Codex.
2. Остановите владельца. Отмените активную задачу, остановите запущенную вами терминальную команду, отключите запуск Scheduled или завершите сеанс Computer Use. Так вы убираете причину существования дочернего дерева.
3. Выйдите штатно. Используйте обычный выход из приложения, пока интерфейс отвечает. Не начинайте с Диспетчера задач.
4. Дождитесь затихания. Дайте терминалам и файловым операциям закрыться. Универсального времени в секундах нет: задача шага — отличить завершающую очистку от продолжающегося состояния.
5. Проверьте результат. Убедитесь, что окно исчезло, дерево сокращается или стабилизировалось, а активность процессора и диска прекратилась.
6. Завершите дерево только по строгой границе. Это допустимо, когда полезной работы больше нет и дерево является остаточным без работы, остаётся активным без владельца либо не даёт открыть пригодное окно Codex.
7. Откройте Codex один раз. Нужен один пригодный интерфейс и одно связное состояние задач. Не переходите к циклу повторных запусков и принудительных выходов.
8. Сообщите о повторении. Если симптом вернулся, соберите доказательства до переустановки, удаления состояния или одновременной смены нескольких параметров.

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

powershell
taskkill /PID <top-level-codex-pid> /T /F

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

Наблюдайте дерево в Windows без догадок

Диспетчер задач быстрее всего отвечает на три практических вопроса: меняется ли группа Codex, какой дочерний процесс проявляет активность и прекращается ли она после остановки задачи-владельца. Представление Процессы удобно для живой нагрузки, Подробности — для PID, а Монитор ресурсов может показать обращение к файлам на диске.

Сравнивайте несколько наблюдений до и после действия. Один показатель CPU или одно значение памяти не являются вердиктом. Если вы готовите данные для отчёта, сначала снимите родительско-дочернюю структуру без командных строк:

powershell
Get-CimInstance Win32_Process |
  Where-Object { $_.Name -match 'codex|powershell|pwsh|conhost|node|git|python|wsl' } |
  Sort-Object ParentProcessId, ProcessId |
  Select-Object Name, ProcessId, ParentProcessId, CreationDate

Этот фильтр может захватить чужие инструменты разработки и пропустить помощника с другим именем. Он не определяет процессы Codex. Используйте ParentProcessId, ProcessId и CreationDate, чтобы восстановить вероятную связь и проверить её по времени вашей задачи.

Для лёгкого снимка ресурсов используйте второй запрос:

powershell
Get-Process |
  Where-Object { $_.ProcessName -match 'codex|powershell|pwsh|conhost|node|git|python|wsl' } |
  Sort-Object CPU -Descending |
  Select-Object ProcessName, Id,
    @{Name='CPUSeconds'; Expression={[math]::Round($_.CPU, 1)}},
    @{Name='MemoryMB'; Expression={[math]::Round($_.WorkingSet64 / 1MB, 1)}}

CPUSeconds — накопленное процессорное время, а не мгновенный процент CPU. Выполните снимок дважды и сопоставьте прирост с живыми столбцами процессора и диска в Диспетчере задач. Если к процессу нет доступа, запишите это; повышать привилегии только ради красивой таблицы не требуется.

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

Не смешивайте Windows, WSL2 и встроенный терминал

Текущая документация OpenAI о настольном приложении ChatGPT для Windows различает собственный агент Windows с PowerShell и песочницей Windows и агент, работающий в WSL2. Выбор оболочки встроенного терминала задаётся отдельно. Переключение среды агента на WSL требует перезапуска приложения.

Не переключайте Windows/WSL2 как первый способ восстановления. Такое изменение создаёт другой эксперимент и требует перезапуска. Сначала сохраните проблемное состояние и получите базовую линию; если симптом воспроизводится, меняйте только одну переменную.

Если дерево уже здорово, но настольное приложение всё равно заметно медленнее CLI или IDE, перейдите к отдельной проверке Codex App и CLI. Та страница отвечает за сравнение поверхностей, а здесь рассматривается жизненный цикл фонового дерева.

Проверьте Scheduled и Computer Use как возможных владельцев

Запуск по расписанию и Computer Use — это не типы поломки. Оба механизма могут законно оставить работу активной без обычной задачи на переднем плане.

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

Для Computer Use проверьте, выполняется ли управляемая работа в приложении или браузере. Завершите сеанс из его собственного интерфейса и посмотрите, прекратилась ли связанная активность. Если ваша цель — понять запуск, контроль и разрешения GUI-работы, используйте отдельное руководство по Codex Computer Use. В этой диагностике Computer Use важен только как один из возможных владельцев дерева.

Соберите полезный отчёт при повторении

Текущая инструкция OpenAI по обратной связи и журналам направляет сообщения о Codex в существующую или новую задачу GitHub и просит проверять журналы и транскрипты перед публикацией. Документированное место транскриптов — $CODEX_HOME/sessions. Универсальный путь к журналу приложения Codex в Windows не указан, поэтому не придумывайте его и не ищите случайную папку как обязательное доказательство.

До разрушительной очистки соберите:

• версию приложения Codex и местное время наблюдения;
• версию и архитектуру Windows;
• среду агента: собственный Windows/PowerShell или WSL2;
• выбранный встроенный терминал, если это связано с симптомом;
• тип проекта, локальную копию или worktree;
• состояние Tasks, Scheduled, терминала и Computer Use;
• точный симптом: остаток после выхода, запуск без окна или активность без владельца;
• родительские и дочерние PID со временем старта;
• наблюдения CPU, диска и памяти до и после штатного выхода;
• минимальные шаги воспроизведения и результат одного чистого перезапуска.

Шаблон удерживает отчёт коротким и сравнимым:

text
Версия приложения Codex:
Версия Windows:
Среда агента: Native Windows / WSL2
Выбор терминала:
Тип проекта и тип пути: [скрыть при необходимости]
Активный владелец: Task / Scheduled / Terminal / Computer Use / None
Симптом:
Минимальные шаги воспроизведения:
Ожидаемый результат:
Фактический результат:
CPU, диск и память до/после:
Убрал ли дерево штатный выход?
Помог ли один чистый перезапуск?

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

Не используйте разрушительные сокращения

• Не задавайте фиксированное число процессов. Дерево зависит от работы, инструментов, среды и сборки приложения.
• Не завершайте по имени. Node, PowerShell, Git, Python, консольный хост и WSL могут принадлежать другим задачам.
• Не удаляйте кэш, транскрипты или состояние .codex первым шагом. Так теряются доказательства и настройки, а причина остаётся неизвестной.
• Не переустанавливайте до воспроизведения. Переустановка меняет среду и может стереть полезное сравнение.
• Не меняйте одновременно Windows/WSL2, терминал, разрешения и расположение проекта. После базового снимка меняйте по одной переменной.
• Не повторяйте цикл принудительного выхода и запуска. Одной чистой попытки достаточно, чтобы понять, вернулся ли симптом.
• Не используйте background_terminal_max_timeout как лечение дерева. Параметр ограничивает окно опроса вывода фонового терминала, а не число процессов Windows и не их жизненный цикл.

Частые вопросы

Сколько процессов Codex нормально для Windows?

Универсального опубликованного числа нет. Оно меняется с задачами, терминалами, Git и языковыми инструментами, Scheduled, Computer Use, Windows/WSL2 и версией приложения. Оценивайте владельца, жизненный цикл и продолжающуюся активность, а не количество строк.

Можно ли безопасно снять задачу Codex в Диспетчере задач?

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

Почему процессы остаются после закрытия окна?

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

Что делать, если Codex есть в Диспетчере задач, но окна нет?

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

Доказывает ли высокая активность процессора или диска зависание?

Нет. Это может быть задача агента, терминальная команда, Git, индексирование, запуск по расписанию или завершение. Сигнал становится полезным, когда активность продолжается, владельца нет, а сравнение до и после связывает её с остаточным деревом.

Влияет ли WSL2 на вид дерева процессов?

Да, агент WSL2 добавляет хост-процессы WSL и Linux-инструменты, тогда как собственный агент Windows использует PowerShell и песочницу Windows. Но оболочка встроенного терминала — отдельная настройка. Не делайте вывод о среде агента только по выбору терминала.

Исправит ли background_terminal_max_timeout остаточные процессы?

Нет. Справочник конфигурации Codex описывает этот параметр как максимальное окно опроса вывода фонового терминала. Он не задаёт нормальное число процессов Windows и не является первым шагом восстановления настольного приложения.

Где искать журнал Codex в Windows?

Официальная инструкция указывает транскрипты в $CODEX_HOME/sessions, но не устанавливает один универсальный путь к журналу приложения Windows. Начните с воспроизводимых шагов, версий, среды и снимков дерева. Перед передачей транскриптов или журналов обязательно удалите чувствительные данные.

Практическое правило

Оставляйте фоновые процессы Codex, пока ими владеет задача, терминал, Scheduled или Computer Use. Когда полезной работы нет, идите по порядку: сохраните данные, остановите владельца, штатно выйдите, дождитесь затихания, проверьте дерево, завершите его только по строгой границе, откройте приложение один раз и при повторении подготовьте обезличенный отчёт.

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