Codex SkyComputerUseClient helper 누적 확인법

Codex SkyComputerUseClient helper가 누적됐는지 확인하기 전에 모든 Codex 프로세스를 강제 종료하지 마세요. helper가 없으면 이 문제로 단정하지 않습니다. 같은 Codex 부모 아래 helper 수와 메모리가 turn을 거듭할수록 늘 때만 작업을 저장한 뒤 해당 세션을 정상 종료하고 다시 확인합니다.

1분 확인 순서

터미널을 열고 먼저 버전을 확인합니다.

codex --version

이어서 helper를 부모 Codex 세션별로 집계합니다. 이 명령은 프로세스를 종료하지 않습니다.

ps -Ao pid=,ppid=,rss=,etime=,comm= |
  awk '$5 ~ /SkyComputerUseClient/ {n[$2]++; r[$2]+=$3}
       END {for (p in n) printf "parent=%s helpers=%d rss_mb=%d\n", p, n[p], int(r[p]/1024)}'

출력의 뜻은 다음과 같습니다.

• 아무 행도 없으면 현재 그 이름의 helper가 없습니다. Codex helper 누적으로 단정하지 마세요.
• 한 행이 나오면 parent는 helper를 띄운 부모 프로세스, helpers는 개수, rss_mb는 합계 상주 메모리의 대략적인 MB입니다.
• 숫자가 한 번 높다는 사실만으로 누수라고 단정할 수 없습니다. 같은 작업을 저장한 상태에서 일반 turn 전후로 다시 집계해 계속 늘고 줄지 않는지 비교해야 합니다.

parent=12345처럼 번호가 나왔다면 그 부모의 실제 명령을 읽기 전용으로 확인합니다. 12345는 자신의 출력에 표시된 번호로 바꾸세요.

ps -p 12345 -o pid=,etime=,command=

기대 결과는 PID, 실행 시간, 실제 명령 한 행입니다. 명령에 대화형 codex가 보이는지, Desktop 앱 내부의 app-server인지 나눠 볼 수 있습니다. 빈 결과면 그 사이 부모가 종료된 것이므로, 이전 번호를 강제 종료 명령에 재사용하지 마세요.

제가 2026년 9월 25일 Codex CLI 0.156.1이 실행 중인 Mac에서 확인했을 때는 helper 집계 행이 0개였습니다. 여러 Codex 프로세스가 오래 실행 중이라는 사실만으로 공개 이슈와 같은 누적 상태가 되는 것은 아니었습니다.

검색 화면에서는 프로세스 이름을 Sky Computer Use Client처럼 띄어 쓰기도 했습니다. 터미널에서 실제 프로세스를 찾을 때는 공개 이슈와 프로세스 목록에 쓰인 SkyComputerUseClient를 그대로 사용하세요. 넓은 Codex memory 검색에는 대화 기억 기능과 일반적인 앱 메모리 증가도 함께 섞이므로, 같은 문제라고 합치면 안 됩니다.

공개 사례는 무엇을 기록했나

공개 이슈 #47580 작성자는 macOS arm64와 Codex CLI 0.156.1에서 대화형 세션을 여러 날 열어 두었습니다. Computer Use를 직접 호출하지 않은 일반 turn 뒤에도 자식 SkyComputerUseClient가 남았고, 새 세션은 2개에서 시작하지만 오래된 세션은 helper 수와 RSS가 늘었다고 기록했습니다.

한 시점에는 13개 세션에 helper 154개, 합계 약 3GB RSS가 남았다고 보고했습니다. 작성자는 오래 열린 해당 세션을 재시작했을 때 helper가 해제됐다고 적었습니다. 그러나 이것은 한 공개 환경의 재현입니다. 모든 Mac, 모든 느려짐, 모든 Codex 버전에 같은 원인이 있다는 뜻은 아닙니다.

언제 해당 세션을 재시작하나

다음 조건을 함께 확인할 때만 이 후보를 우선합니다.

1. 집계 결과에 SkyComputerUseClient가 실제로 나온다.
2. 같은 부모 PID 아래 helper 수나 RSS가 일반 turn 뒤 계속 늘어난다.
3. 오래 기다려도 이전 helper가 줄지 않는다.
4. Activity Monitor의 메모리 압력과 실제 느려짐 시점이 겹친다.

먼저 진행 중인 명령이 끝났는지 확인하고 수정한 파일을 저장하세요. 그다음 문제가 연결된 Codex 세션만 정상적으로 종료하고 다시 시작합니다. 재시작 뒤 같은 집계 명령을 실행해 helper가 줄었는지 확인합니다.

전체 앱을 강제 종료하거나 다음처럼 이름만으로 광범위하게 죽이는 명령을 첫 해결책으로 사용하지 마세요.

killall ...
pkill -f ...

이 방식은 다른 작업 중인 Codex 세션까지 끊을 수 있고, 저장하지 않은 입력이나 진행 중 결과를 잃게 할 수 있습니다.

helper가 0개인데 Mac이 느리다면

이 원고의 대상 문제가 아닐 가능성이 큽니다. Activity Monitor를 열고 메모리 탭에서 메모리 압력과 상위 프로세스를 확인하세요. Codex 자체, 브라우저, 가상 머신, 로컬 모델처럼 실제 메모리를 많이 쓰는 다른 프로세스가 있을 수 있습니다.

SkyComputerUseClient가 보이더라도 부모가 대화형 CLI인지 Desktop 앱 서버인지 구분해야 합니다. 공개 이슈는 대화형 CLI 자식에서 turn 수에 따라 늘어난 사례를 다뤘습니다. 시간만 지나며 늘거나 부모가 다른 경우에는 같은 원인으로 합치지 않습니다.

검색 결과에는 Codex Desktop 지연과 macOS의 syspolicyd·trustd 과부하 사례도 함께 나왔습니다. helper 집계가 0개라면 이 원고의 재시작 절차를 반복하지 말고, Activity Monitor에서 실제 상위 프로세스와 메모리 압력을 기준으로 별도 원인을 좁히세요.

Apple의 Activity Monitor 메모리 안내를 따라 메모리 압력과 앱별 사용량을 함께 보면 helper 개수만으로 원인을 단정하는 오류를 줄일 수 있습니다. 자동화 로그에서 명령 시도 자체가 빠진 것처럼 보이면 Codex exec JSON에 실패 명령이 없을 때 확인 순서로 도구 결과·내부 exit·외부 process exit를 따로 보세요. 원격 app-server 연결 오류는 helper 누적과 섞지 말고 invalid remote address 경로 확인법으로 주소 문법부터 분리하세요.

자주 묻는 질문

helper가 하나라도 보이면 오류인가요?

아닙니다. 공개 사례에서도 새 세션은 helper 2개로 시작했습니다. 문제 후보는 존재 자체가 아니라 turn 뒤 개수와 RSS가 계속 늘고 이전 helper가 정리되지 않는 패턴입니다.

SkyComputerUseClient를 직접 강제 종료해도 되나요?

먼저 작업을 저장하고 해당 부모 Codex 세션을 정상 종료하는 편이 안전합니다. 자식만 반복 종료하면 현재 turn이나 정리 동작과 충돌할 수 있고, 원인과 재발 여부도 확인하기 어렵습니다.

현재 버전에서 수정됐나요?

2026년 9월 25일 확인한 공개 이슈는 열려 있었고 수정 릴리스 표시는 없었습니다. 다만 현재 Mac의 0.156.1 대조에서는 helper가 0개였습니다. 버전 번호만으로 내 환경의 발생 여부를 결정하지 말고 실제 프로세스 집계를 확인하세요.

정리

• Mac이 느리다는 느낌만으로 Codex helper 누적을 단정하지 않습니다.
• helper 수, 부모 PID, 합계 RSS를 읽기 전용으로 먼저 집계합니다.
• 한 번의 수치보다 turn 전후에 계속 증가하고 정리되지 않는지를 봅니다.
• 실제 누적이면 작업 저장 후 해당 Codex 세션만 정상 재시작하고 다시 집계합니다.
• helper가 0개면 다른 메모리 원인을 확인합니다.

확인 환경: macOS arm64, Codex CLI 0.156.1. 공개 이슈의 누적 수치와 현재 Mac의 helper 0개 대조를 분리했습니다.

참고: macOS 대화형 CLI helper 누적 공개 이슈, Apple Activity Monitor 메모리 사용량 보기

검증 기준

• 마지막 업데이트일: 2026-09-25
• 확인 환경: macOS arm64, Codex CLI 0.156.1. 현재 Mac에서는 helper 0개로 누적을 재현하지 못했다.
• 주요 근거: GitHub 공개 이슈 #47580, Apple Activity Monitor 메모리 안내
• 미확인: helper가 누적된 독립 로컬 재현과 수정 릴리스 여부