Windows의 Codex 백그라운드 프로세스: 종료해도 되는 상태 판별법

Codex 창을 닫았는데 프로세스가 남아 있거나, 다시 실행해도 창이 나타나지 않거나, 작업이 없는데 CPU·디스크 사용이 계속된다면 프로세스 수부터 세지 마세요. 먼저 활성 작업·터미널·Codex Scheduled 실행·Computer Use 세션 중 누가 해당 작업을 소유하고 있는지 확인해야 합니다. 소유자가 확인된 작업은 그 화면에서 정상적으로 중지하거나 완료될 때까지 두는 것이 우선입니다.

소유자가 없다면 프롬프트, 패치, 터미널 출력을 보존한 뒤 Codex를 정상 종료하고 활동이 가라앉을 때까지 기다립니다. 창 상태, 남은 부모·자식 관계, CPU·디스크 변화까지 다시 확인한 후에만 잔류 트리인지 판단하세요. 강제 종료는 소유 작업이 전혀 없고, 트리가 유휴 상태로 남거나, 소유자 없이 계속 활동하거나, Codex를 정상적으로 다시 열지 못하게 막을 때만 고려합니다.

그 다음 Codex를 한 번만 다시 엽니다. 같은 현상이 돌아오면 강제 종료를 반복하지 말고 앱과 Windows 버전, native Windows 또는 WSL2 환경, 재현 단계, 작업 소유 상태, 전후 자원 패턴을 민감 정보를 가린 채 기록해 신고하세요.

먼저, 지금 보이는 프로세스를 종료해도 되는지 판단하세요

Codex가 여러 프로세스를 사용한다고 해서 곧바로 비정상은 아닙니다. 에이전트는 PowerShell이나 다른 셸, 터미널 명령, Git 작업, Node·Python 같은 언어 런타임, 브라우저 작업, WSL 프로세스를 시작할 수 있습니다. 따라서 “Codex 프로세스는 몇 개가 정상인가?”보다 “이 트리를 소유한 작업이 무엇이며, 그 작업이 아직 진행 중인가?”를 먼저 물어야 합니다.

아래 표는 행 하나를 고르는 목록이 아니라, 위에서 아래로 이어지는 확인 흐름입니다. 먼저 눈에 보이는 작업 소유자를 찾고, 없을 때만 종료 후 잔류 상태와 자원 활동을 확인하세요.

OpenAI는 Windows에서 정상으로 간주할 Codex 프로세스의 보편적인 개수를 공개하지 않습니다. 프로세스 이름과 도우미 구조도 앱 버전, 사용 도구, 프로젝트 유형, native Windows와 WSL2 환경에 따라 달라질 수 있습니다. 위 표와 이미지는 실행 파일 목록이나 성능 임계값이 아니라 다음 행동을 고르는 판단 도구입니다.

프로세스 이름이 아니라 여섯 가지 증상으로 경로를 고르세요

1. 활성 작업 또는 터미널이 보이는 경우

코드 생성, 테스트 실행, 승인 대기, 터미널 출력 스트리밍이 계속된다면 도우미 프로세스에는 분명한 소유자가 있습니다. 이때 트리를 끝내면 작성 중인 패치가 사라지거나 명령이 중간에서 끊기고, 외부 작업이 일부만 적용될 수 있습니다.

먼저 Codex의 작업 화면에서 취소하거나, 해당 터미널에서 자신이 시작한 명령을 중지하세요. 그런 다음 상태가 완료, 실패, 취소, 중지 중 하나로 실제 전환되었는지 확인합니다. UI의 진행 표시만 멈췄다는 이유로 부모 트리를 강제 종료하지 마세요.

2. Codex Scheduled 실행이 소유자인 경우

OpenAI의 Scheduled tasks 공식 문서에 따르면 로컬 프로젝트 실행은 백그라운드에서 수행되며, 컴퓨터가 켜져 있고 데스크톱 앱이 실행 중이어야 합니다. 화면에 현재 작업이 보이지 않아도 Scheduled 실행 때문에 Codex 트리가 의도적으로 살아 있을 수 있다는 뜻입니다.

Scheduled에서 이름, 마지막 실행, 다음 실행, 현재 상태를 확인하세요. 로컬 checkout 또는 worktree를 사용하는지도 함께 기록하면 소유권을 판단하기 쉽습니다. 원하지 않는 실행이라면 Codex의 Scheduled 화면에서 중지하거나 비활성화해야 합니다. Windows 프로세스를 강제로 끝내도 그 프로세스를 다시 시작한 스케줄 설정은 바뀌지 않습니다.

3. 정상 종료 뒤에도 트리가 남는 경우

창을 닫은 것과 애플리케이션 수명 주기가 완전히 끝난 것은 같은 일이 아닐 수 있습니다. Codex를 의도적으로 정상 종료했고 활성 작업·터미널·Scheduled 실행이 없는데도 트리가 남아 있다면 잔류 상태를 의심할 수 있습니다. 다만 파일 쓰기, 터미널 종료, 정리 작업이 끝나는 동안 잠시 활동할 수 있으므로 즉시 누수로 단정하지 마세요.

판단 경계는 개수나 특정 이름이 아니라 행동입니다. 정상 종료 뒤에도 소유자를 찾을 수 없는 트리가 계속 남거나, 소유자 없이 계속 활동하거나, 사용할 수 있는 Codex 창을 다시 여는 것을 방해할 때 복구 대상으로 봅니다. 작업 관리자에서 한 번 새로 고친 결과나 잠시 나타난 프로세스만으로는 잔류 결함을 증명할 수 없습니다.

4. 프로세스만 있고 창이 나타나지 않는 경우

Codex 아이콘을 반복해서 클릭하면 시작 시각이 다른 트리가 추가되어 원래 문제를 읽기 더 어려워질 수 있습니다. 먼저 기존 Codex 트리가 있는지, 언제 시작됐는지 확인하세요. 접근 가능한 프롬프트와 출력은 보존하고, 아래의 정상 복구를 한 번만 수행한 뒤 한 번만 다시 실행합니다.

그래도 사용할 수 있는 창이 나타나지 않으면 앱과 Windows 버전, 실행한 순서, 기존 트리의 시작 시각, native Windows 또는 WSL2 환경을 기록하세요. 재설치나 여러 설정 변경을 먼저 하면 어느 변화가 영향을 주었는지 판단할 기준이 사라집니다.

5. 작업이 없는데 CPU 또는 디스크 활동이 계속되는 경우

여기서 “작업이 없다”는 말은 Task, 터미널 명령, Scheduled 실행, Computer Use 세션이 실제로 비활성임을 확인했다는 뜻입니다. 작업 관리자 화면 한 번만 보고 결론을 내리지 말고, 정상 종료 전후에 CPU·디스크·메모리 변화와 부모·자식 관계를 비교하세요.

짧은 인덱싱, 파일 쓰기, Git 작업, 터미널 정리 때문에 순간적으로 활동이 보일 수 있습니다. 반대로 소유 작업이 전혀 없고 활동이 계속되며 정상 종료나 재실행으로도 같은 트리에 묶인다면 보고할 가치가 있는 재현 신호가 됩니다. 어떤 GitHub 이슈의 CPU 수치, PID, 프로세스 개수, 앱 버전은 그 환경의 사례일 뿐 사용자 PC의 보편적인 정상·비정상 임계값이 아닙니다.

6. 셸 또는 개발 도구 자식이 고아처럼 보이는 경우

PowerShell, pwsh, conhost.exe, Node, Git, Python, WSL은 Codex 전용 프로세스가 아닙니다. IDE, 다른 터미널, 개발 서버, 개인 자동화가 같은 도구를 사용할 수 있습니다. 프로세스 이름만 보고 전체를 끝내면 Codex와 무관한 작업까지 중단됩니다.

작업 관리자 Details 또는 PowerShell에서 부모 PID와 생성 시각을 따라가세요. 소유권이 확인된 최상위 Codex 가지를 기준으로 판단하고, 공유 셸 이름을 영구적인 종료 목록으로 만들지 마세요.

작업을 먼저 지키는 8단계 안전 종료 순서

아래 단계는 순서를 바꾸지 않는 것이 중요합니다. 문제가 해결된 지점에서 멈추세요.

1. 작업을 보존합니다. 보내지 않은 프롬프트를 복사하고, 필요한 터미널 출력을 저장하며, 중요한 패치와 파일이 디스크에 있는지 확인합니다. 진행 중인 변경은 완료를 기다릴지 Codex 화면에서 취소할지 먼저 결정합니다.
2. 작업 소유자를 중지합니다. 활성 Task를 취소하고, 자신이 시작한 터미널 명령을 중지하며, Scheduled 실행을 비활성화하거나, 활성 Computer Use 세션을 그 소유 화면에서 끝냅니다.
3. Codex를 정상 종료합니다. UI가 반응한다면 앱의 정상 종료 경로를 사용합니다. 아직 화면에서 중지할 수 있는데 작업 관리자로 곧바로 넘어가지 마세요.
4. 활동이 가라앉을 때까지 기다립니다. 터미널 자식과 파일 작업이 정리될 시간을 줍니다. 모든 환경에 적용되는 고정 대기 시간은 없습니다. 목표는 정상적인 정리와 끝없이 남는 상태를 구분하는 것입니다.
5. 창·트리·자원 활동을 다시 확인합니다. 창이 사라졌는지, 트리가 축소되거나 멈췄는지, CPU·디스크 활동이 내려갔는지 전후 상태를 비교합니다.
6. 조건을 충족한 잔류 트리만 종료합니다. 소유 작업이 하나도 없고, 트리가 유휴 상태로 남거나, 소유자 없이 계속 활동하거나, Codex를 사용할 수 있게 다시 여는 것을 막는 경우에만 진행합니다.
7. Codex를 한 번만 다시 엽니다. 하나의 정상 창과 일관된 작업 상태가 돌아오는지 확인합니다. 실행과 강제 종료를 반복하는 루프를 만들지 마세요.
8. 재발하면 보고용 증거를 남깁니다. 같은 상태가 돌아오면 재설치, 상태 삭제, 여러 설정 변경보다 먼저 아래의 재현 자료를 수집합니다.

작업 관리자에서는 검증된 최상위 Codex 그룹을 찾아 소유 작업이 모두 끝났음을 확인한 뒤, 6단계에서만 작업 끝내기를 사용하는 것이 안전합니다. UI로 검증된 잔류 트리를 끝낼 수 없을 때 관리자는 Windows의 트리 종료 옵션을 사용할 수 있습니다.

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

/T는 자식 프로세스를 포함하고 /F는 강제 종료합니다. 그래서 복구에는 유용하지만 진행 중인 작업에는 파괴적입니다. 추측한 PID를 붙여 넣거나, 공유 셸을 이름으로 지정하거나, 작업을 저장하고 트리를 추적하기 전에 실행해서는 안 됩니다.

작업 관리자와 PowerShell로 추측 없이 확인하세요

작업 관리자에서는 먼저 세 가지를 확인합니다.

1. Codex 그룹의 프로세스 수와 자원 활동이 계속 변하는가?
2. 어느 자식이 CPU, 디스크, 메모리를 사용하고 있는가?
3. 해당 작업·터미널·Scheduled 실행을 정상 중지했을 때 그 활동도 멈추는가?

실시간 변화는 프로세스 보기에서 확인하고, PID가 필요하면 세부 정보 보기를 사용하세요. 디스크 파일 활동을 더 확인해야 할 때는 Resource Monitor가 도움이 됩니다. 한 번의 CPU 수치나 메모리 합계를 판정으로 쓰지 말고, 짧은 전후 시퀀스를 기록하는 것이 핵심입니다.

처음부터 명령줄 전체를 수집하지 않고 부모·자식 관계를 보는 PowerShell 스냅샷은 다음과 같습니다.

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 프로세스의 공식 정의가 아닙니다. 관련 없는 개발 도구가 포함될 수 있고, 이름이 다른 도우미는 빠질 수 있습니다. 부모 PID와 생성 시각을 함께 사용해 어떤 작업에서 시작되었는지 재구성하세요.

가벼운 자원 스냅샷은 다음처럼 만들 수 있습니다.

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 사용률이 아니라 프로세스가 사용한 누적 CPU 시간입니다. 같은 스냅샷을 두 번 실행하고 작업 관리자의 실시간 CPU·디스크 열과 함께 비교하세요. 접근이 거부되면 더 보기 좋은 표를 만들기 위해 권한부터 높이지 말고, 접근 거부 사실 자체를 기록하면 됩니다.

공개 보고서에는 CommandLine 필드를 기본으로 포함하지 마세요. 명령줄에는 저장소 경로, 브랜치 이름, 프롬프트, 파일 이름, 토큰과 같은 민감 정보가 들어갈 수 있습니다.

native Windows, WSL2, 통합 터미널은 서로 다른 선택입니다

OpenAI의 현재 ChatGPT 데스크톱 앱용 Windows 문서는 PowerShell과 Windows sandbox를 사용하는 native Windows 에이전트와 WSL2에서 실행되는 에이전트를 구분합니다. 통합 터미널 선택은 에이전트 환경과 별도로 취급하며, 에이전트 환경을 WSL로 전환하면 앱을 다시 시작해야 합니다.

첫 복구 단계로 Windows/WSL 모드를 바꾸지 마세요. 모드 전환은 문제를 관찰하는 조건을 바꾸고 앱 재시작도 필요로 합니다. 먼저 실패 상태를 기록하고, 문제가 재현될 때 한 번에 변수 하나만 바꾸는 편이 원인을 찾기 쉽습니다.

프로세스 트리가 정상인데도 데스크톱 앱만 CLI나 IDE보다 느린 것이 핵심 문제라면, 별도의 Codex 앱과 CLI 속도 비교 가이드를 사용하세요. 그 가이드는 표면 간 성능 비교를 다루고, 여기의 진단 범위는 백그라운드 프로세스의 수명 주기와 안전한 복구로 제한됩니다.

Codex Scheduled 실행을 Windows 작업 스케줄러로 오해하지 마세요

여기서 Scheduled는 Codex 앱 안에서 관리하는 Scheduled 실행을 뜻합니다. Windows Task Scheduler와 같은 항목으로 이름을 바꿔 이해하면 소유 화면과 중지 방법을 잘못 찾을 수 있습니다.

백그라운드 트리가 Scheduled 실행에 속하는지 확인하려면 Codex의 Scheduled 화면에서 실행 상태, 마지막·다음 실행, 로컬 프로젝트 또는 worktree 사용 여부를 확인합니다. 작업이 진행 중이면 완료를 기다리거나 그 화면에서 중지하세요. 프로세스 트리만 끝내는 것은 일시적으로 실행을 끊을 뿐, 다음 실행을 예약한 설정을 해제하지 않습니다.

반대로 Scheduled 화면에 관련 실행이 없고 Task와 터미널도 비활성이라면, 정상 종료 후 트리의 수명과 자원 활동을 다시 보는 잔류 프로세스 경로로 이동합니다. “백그라운드에 있다”는 공통점만으로 Scheduled 작업과 수명 주기 장애를 같은 문제로 묶지 마세요.

Computer Use 세션도 정당한 작업 소유자일 수 있습니다

Computer Use가 앱과 브라우저를 조작 중이라면 눈앞의 Codex 창이 조용해 보여도 관련 작업이 계속될 수 있습니다. 프로세스 트리를 끝내기 전에 활성 세션 여부를 확인하고, 가능하면 Computer Use를 시작한 소유 화면에서 먼저 세션을 종료하세요. 그 뒤 관련 자원 활동이 함께 멈추는지 확인합니다.

Computer Use에는 별도의 권한, 제어, 안전 경계가 있습니다. 백그라운드 GUI 작업을 어떻게 시작하고 감독하는지가 질문이라면 Codex Computer Use 가이드가 더 맞는 경로입니다. 프로세스 수명 주기를 진단할 때 Computer Use는 잔류 트리로 판정하기 전에 배제해야 하는 작업 소유자 중 하나일 뿐입니다.

같은 상태가 돌아오면 재현 가능한 보고서를 만드세요

OpenAI의 현재 피드백 및 로그 안내는 Codex 문제를 기존 GitHub 이슈 또는 새 이슈로 보고하고, 공유할 로그와 transcript에 민감 정보가 없는지 검토하라고 안내합니다. 보고 맥락에 사용할 세션 transcript 위치는 $CODEX_HOME/sessions로 문서화되어 있지만, 모든 설치에 적용되는 하나의 Windows 앱 로그 경로는 제공하지 않습니다. 임의의 로그 경로를 만들어 안내하지 마세요.

파괴적인 정리 전에 다음 항목을 수집합니다.

• Codex 앱 버전과 현지 캡처 시각
• Windows 버전과 아키텍처
• native Windows/PowerShell 또는 WSL2 에이전트 환경
• 관련이 있다면 통합 터미널 선택
• 프로젝트 유형과 로컬 checkout 또는 worktree 사용 여부
• Tasks, Scheduled, 터미널, Computer Use 중 활성 작업이 표시됐는지
• 종료 후 잔류, 무창 실행, 무주 상태의 지속 활동 중 어떤 증상인지
• 부모·자식 PID와 시작 시각
• 정상 종료 전후의 CPU, 디스크, 메모리 관찰 결과
• 최소 재현 단계와 한 번의 정상 재실행으로 회복됐는지

보고서는 다음처럼 짧고 비교 가능하게 정리할 수 있습니다.

text
Codex 앱 버전:
Windows 버전:
에이전트 환경: native Windows / WSL2
통합 터미널 선택:
프로젝트 유형과 경로 유형: [필요하면 삭제]
활성 소유 작업: Task / Scheduled / Terminal / Computer Use / 없음
보이는 증상:
최소 재현 단계:
예상 결과:
실제 결과:
정상 종료 전후 CPU, 디스크, 메모리:
정상 종료로 트리가 사라졌는가:
한 번의 정상 재실행으로 회복됐는가:

공개 이슈를 올리기 전에는 프롬프트, transcript 내용, API 토큰, 고객 데이터, 비공개 저장소 이름, 사용자 이름, 전체 로컬 경로, 민감한 명령줄 인수를 삭제하세요. 세션 디렉터리 전체를 그대로 공개 이슈에 첨부하는 방식은 피해야 합니다.

원인을 가리는 파괴적인 지름길은 피하세요

• 고정 프로세스 개수를 정상 기준으로 삼지 마세요. 트리는 작업, 도구, 환경, 앱 빌드에 따라 달라집니다.
• 프로세스 이름만으로 일괄 종료하지 마세요. Node, PowerShell, Git, Python, console host, WSL은 다른 개발 작업도 공유합니다.
• 캐시, 세션 transcript, .codex 상태를 첫 단계에서 삭제하지 마세요. 증거와 구성을 잃고도 수명 주기 복구가 효과가 있었는지 알 수 없게 됩니다.
• 재현 자료를 수집하기 전에 재설치하지 마세요. 환경이 바뀌어 전후 비교가 어려워집니다.
• Windows/WSL 모드, 터미널, 권한, 프로젝트 위치를 동시에 바꾸지 마세요. 먼저 기준 상태를 기록한 뒤 한 번에 변수 하나만 바꿉니다.
• 강제 종료와 재실행을 반복하지 마세요. 정상 복구 시도 한 번이면 문제가 재발하는지 판단할 수 있습니다.
• background_terminal_max_timeout을 프로세스 수 제어로 사용하지 마세요. 이 설정은 백그라운드 터미널 출력의 최대 폴링 창이지, 잔류 데스크톱 트리의 첫 해결책이 아닙니다.

자주 묻는 질문

Windows에서 Codex 프로세스는 몇 개가 정상인가요?

공식적으로 공개된 보편 개수는 없습니다. 활성 Task, 터미널, Git·언어 도구, Scheduled 실행, Computer Use, native Windows와 WSL2 환경, 앱 빌드에 따라 트리가 달라집니다. 개수보다 작업 소유자, 종료 전후의 활동, 정상 종료 뒤의 수명 주기를 보세요.

작업 관리자에서 Codex를 종료해도 안전한가요?

작업과 출력을 먼저 보존하고, 소유 Task·터미널·Scheduled·Computer Use를 중지하고, 정상 종료를 시도한 뒤 활동을 다시 확인해야 합니다. 그 후에도 소유 작업 없이 유휴 잔류, 무주 지속 활동, 정상 재실행 방해 중 하나가 남을 때만 검증된 최상위 Codex 트리를 종료하는 것이 합리적입니다.

Codex 창을 닫았는데 왜 계속 실행되나요?

활성 Task, 터미널, Scheduled 실행, Computer Use가 백그라운드 작업을 소유할 수 있고, 파일 쓰기나 터미널 정리가 마무리 중일 수도 있습니다. 아무 소유자도 없고 의도적인 정상 종료 뒤에도 트리가 남으면 잔류 수명 주기 증상으로 보고 8단계 복구 순서를 따르세요.

작업 관리자에는 Codex가 있는데 창이 열리지 않으면 어떻게 하나요?

아이콘을 반복해서 누르지 마세요. 기존 트리와 시작 시각을 확인하고, 접근 가능한 작업을 보존한 뒤 정상 복구를 한 번 수행하고 한 번만 다시 엽니다. 다시 사용할 수 있는 창이 나타나지 않으면 버전, 환경, 소유 상태, 부모·자식 관계, 정확한 실행 순서를 기록합니다.

CPU나 디스크 사용량이 높으면 Codex가 멈춘 것인가요?

그 자체로는 증명되지 않습니다. 에이전트 Task, 터미널 명령, Git 작업, 인덱싱, Scheduled 실행, 정리 과정이 잠시 자원을 사용할 수 있습니다. 소유 작업이 없어야 하고, 활동이 계속되며, 정상 종료 전후 비교가 같은 잔류 Codex 트리에 연결될 때 조사 가능한 신호가 됩니다. 고정 퍼센트 임계값은 두지 마세요.

background_terminal_max_timeout은 프로세스 개수 설정인가요?

아닙니다. 현재 Codex 설정 참조는 이 항목을 백그라운드 터미널 출력을 기다리는 최대 폴링 창으로 설명합니다. Windows 프로세스 개수를 정하거나 잔류 데스크톱 트리를 처음부터 고치는 설정이 아닙니다.

PowerShell, Node, Git, WSL 자식을 전부 종료해야 하나요?

아닙니다. 이 프로세스들은 다른 IDE, 터미널, 개발 서버에서도 사용됩니다. 부모·자식 관계, 시작 시각, 실제 작업 소유자를 확인한 뒤 보존 우선 절차를 모두 거친 검증된 Codex 가지에만 조치하세요.

기억할 한 문장

Task, 터미널, Codex Scheduled 실행, Computer Use가 소유한 프로세스는 그대로 두세요. 아무 작업도 남지 않았다면 보존 -> 소유자 중지 -> 정상 종료 -> 활동 안정 대기 -> 재확인 -> 조건을 충족한 잔류 트리만 종료 -> 한 번 재실행 -> 재발 보고 순서로 복구합니다.

이 순서는 프로세스 목록을 성급한 진단으로 바꾸지 않으면서 당장의 Windows 문제를 해결하고, 같은 문제가 반복될 때 원인을 좁힐 증거까지 지켜 줍니다.