Windows에서 Codex가 어떤 셸 명령도 실행하지 못하고 helper_unknown_error: setup refresh had errors만 돌려준다면, 먼저 샌드박스 로그에 node_repl.exe(또는 VCRUNTIME140_1.dll)와 (os error 32)가 같은 줄에 찍혔는지 보세요. 그 줄이 있으면 프로젝트 폴더나 파일 권한의 문제가 아니라, 2026년 10월 7일 무렵 배포된 Codex 업데이트에 들어간 샌드박스 버그입니다. Codex가 스스로 실행해 둔 파일을 샌드박스 설정 도우미가 다시 열려다 Windows에 거절당하는 것이라, 앱 재시작이나 재부팅으로는 풀리지 않습니다.
해결은 PC에 있는 Codex 구성 요소를 모두 수정된 빌드로 맞추는 것입니다. 하나라도 옛 빌드가 남아 실행 중이면 오류가 계속됩니다. 2026년 10월 22일 기준 버전은 다음과 같습니다.
| 구성 요소 | 수정 전 버전 | 수정된 버전 | 버전 확인 |
|---|---|---|---|
| Codex CLI(npm, 독립 실행) | 0.161.0, 0.162.0, 0.162.1 | 0.163.0 이상(2026년 10월 15일 정식) | codex --version |
| Codex 데스크톱 앱(ChatGPT 데스크톱 앱 안의 Codex 포함) | 26.1002.x, 번들 CLI 0.162.0-alpha.2 | 26.1007.21434(build 13901) 이상, 번들 CLI 0.162.0-alpha.17.2 | 앱의 정보(About) 화면 |
| VS Code 확장 | 같은 로그가 보고됨 | 첫 수정 버전이 공개되지 않음 | 확장을 최신으로 올린 뒤 로그로 확인 |
CLI 쪽은 0.163.0 릴리스 노트에 수정이 올라 있고, OpenAI 직원도 #54325에서 0.163.0 이상으로 올리고 실행 중인 앱과 daemon까지 재시작하라고 답했습니다. 데스크톱 앱 번호는 OpenAI가 발표한 것이 아니라 여러 사용자가 #51601에서 elevated 설정을 그대로 둔 채 업데이트만으로 해결됐다고 확인한 빌드입니다. [windows] sandbox = "unelevated"로 바꾸는 방법은 해결책이 아니라 네트워크 격리를 약하게 만드는 임시 우회이고, 업데이트 후에는 되돌려야 합니다.
setup refresh had errors와 함께 나타나는 증상
증상은 Codex를 어디서 쓰느냐에 따라 문구만 다르고 원인은 같습니다. GitHub 이슈 #51601과 #52328에 올라온 보고를 모으면 다음과 같습니다.
- 모든 셸 명령이 시작되기도 전에 실패합니다.
Get-Location이나cmd /c dir도 마찬가지입니다. 문구는helper_unknown_error: setup refresh had errors이고, 앞에Failed to create unified exec process:나exec-server rejected request (-32603):가 붙기도 합니다. - Node REPL, Computer Use, 앱 내 브라우저 작업은
windows sandbox failed: helper_unknown_error: setup refresh had errors뒤에trusted Node process exited unexpectedly또는node_repl kernel exited unexpectedly로 끝납니다. - 데스크톱 앱에는 "Windows setup didn't finish"나 "Setup stopped" 같은 안내가 뜨고, Retry를 눌러도 관리자 승인(UAC) 창이 나오지 않습니다.
보고된 환경은 대부분 config.toml에 [windows] sandbox = "elevated"를 쓰는 경우입니다.
sandbox 로그에서 node_repl.exe와 os error 32 줄 찾기
이 버그인지는 로그 한 줄로 가릴 수 있습니다. 샌드박스 로그는 %USERPROFILE%\.codex\.sandbox\ 폴더에 날짜별 파일(sandbox.2026-10-22.log 형태)로 쌓입니다. 공식 문서는 같은 폴더의 sandbox.log라는 이름으로 안내하므로 두 형태를 모두 찾습니다. CODEX_HOME을 따로 지정했다면 그 폴더 아래 .sandbox를 보세요.
Select-String -Path "$env:USERPROFILE\.codex\.sandbox\sandbox*.log" -Pattern "os error 32|setup refresh" |
Select-Object -Last 20이 버그라면 아래와 같은 줄이 보입니다(사용자 이름과 해시 폴더는 PC마다 다릅니다).
runtime read/execute validation failed: validate runtime read/execute access on C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exe: open ACL target for root-only update: The process cannot access the file because it is being used by another process. (os error 32)
...
top-level error: setup refresh had errors같은 오류가 node_repl.exe 대신 ...\bin\node_modules\@oai\sky\bin\windows\swift\x64\VCRUNTIME140_1.dll에서 나기도 합니다. 한국어 Windows에서는 가운데 영어 문장이 "다른 프로세스가 파일을 사용 중이기 때문에 프로세스가 액세스 할 수 없습니다."처럼 번역되어 찍힐 수 있으니, 문장 대신 os error 32로 검색하는 편이 확실합니다.
로그 줄별로 판단하면 다음과 같습니다.
| 로그에 보이는 줄 | 의미 | 할 일 |
|---|---|---|
runtime read/execute validation failed … cua_node\<hash>\bin\node_repl.exe 또는 VCRUNTIME140_1.dll … (os error 32) | 이 버그. 실행 중인 Codex 런타임 파일을 열지 못함 | 구성 요소를 모두 수정 버전으로 업데이트 |
failed to grant non-inheriting read-attributes ACE on user profile C:\Users\<user> … (os error 32); continuing setup | 무해한 경고. 설정은 계속 진행됨 | 무시. 같은 실행이 errors=[]로 끝날 수 있음 |
setup refresh: processed N write roots …; errors=[] | 샌드박스 설정 성공 | 정상 |
CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020) | MXC 샌드박스 경로의 다른 문제 | 아래 MXC 절 참고 |
failed: 5, helper_sandbox_lock_failed, 1385, 740 | error 32가 아닌 다른 샌드박스 오류 | 아래 표 참고 |
두 번째 줄의 user profile … continuing setup은 버그가 없는 빌드에서도 찍히는 경고입니다(#54635의 성공 로그에도 함께 있습니다). 이 줄만 보고 사용자 폴더 권한을 고치려 하지 마세요.
os error 32가 뜻하는 것: 다른 프로세스가 파일을 사용 중
Windows 시스템 오류 32는 ERROR_SHARING_VIOLATION(0x20), 즉 공유 위반입니다. Microsoft 문서의 설명은 "다른 프로세스가 파일을 사용 중이어서 프로세스가 파일에 액세스할 수 없다"는 것이고(시스템 오류 코드 0–499), HRESULT로 쓰면 0x80070020입니다. 접근 거부(error 5)와는 다른 오류라서, 파일 소유자나 ACL을 바꿔도 달라지지 않습니다.
여기서 그 파일을 쓰고 있는 "다른 프로세스"는 Codex 자신입니다. elevated 샌드박스는 명령을 실행하기 전에 설정 도우미(codex-windows-sandbox-setup.exe)로 런타임 폴더의 권한을 점검합니다. 문제가 된 도우미는 이때 실행 중인 EXE와 DLL을 MAXIMUM_ALLOWED 권한으로 열려고 했고, Windows가 이를 공유 위반으로 거절했습니다. 그런데 Codex는 첫 명령을 받기 전에 이미 node_repl.exe를 띄워 두고, Computer Use 쪽 codex-computer-use-swift.exe가 VCRUNTIME140_1.dll을 불러옵니다(#52328의 프로세스 분석). 그래서 옛 도우미는 한 번도 성공할 수 없었고, 재부팅을 해도 새로 뜬 node_repl.exe 때문에 다시 실패합니다.
수정은 OpenAI의 PR #51822 "Avoid sharing violations when repairing Windows runtime ACLs"입니다. MAXIMUM_ALLOWED로 여는 대상을 폴더로 한정하고, 파일은 실제로 권한을 바꿔야 할 때만 READ_CONTROL | WRITE_DAC로 엽니다. 2026년 10월 7일(UTC)에 병합됐습니다.
문제는 10월 7일 Windows 앱이 26.1002.51308(build 13417)로, 패키지 기준 26.1002.6548.0·26.1002.7124.0·26.1002.52244로 바뀐 뒤부터 보고됐습니다. 이 빌드들의 번들 CLI가 0.162.0-alpha.2이고, 그 전 도우미(0.160.x) 로그에는 설정 성공 기록만 있습니다(#51634는 이를 "0.162.0-alpha.2 회귀"로 부릅니다).
구성 요소별 수정 버전: CLI 0.163.0과 데스크톱 앱 26.1007.21434
npm으로 설치한 Codex CLI는 0.163.0 이상
CLI는 rust-v0.163.0 릴리스(2026년 10월 15일)에 "#51822 Avoid sharing violations when repairing Windows runtime ACLs"가 들어 있고, 같은 날부터 npm @openai/codex의 latest가 0.163.0입니다. OpenAI 직원 etraut-openai는 10월 16일 #54325와 #54405에 이렇게 답했습니다.
This matches a Windows sandbox issue fixed in #51822 and included in Codex CLI 0.163.0. Versions 0.161.0 and 0.162.1 still had the faulty behavior, which explains why downgrading didn't help. Please update to 0.163.0 or later and restart Codex, including any running Codex app/daemon processes.
0.161.0과 0.162.1도 문제가 있었으므로 CLI를 낮추는 것은 해결이 되지 않습니다. 정식 0.162.0과 0.162.1의 acl.rs에는 이 수정이 없고, 데스크톱 앱용으로 따로 나간 0.162.0-alpha.17.2에는 수정이 옮겨져 있습니다. 버전 번호만 보면 0.162.1이 더 새것 같지만 0.162.1은 수정 전 빌드입니다.
npm install -g @openai/codex@latest
codex --versioncodex-cli 0.163.0 이상이 나오면 됩니다. 업데이트한 뒤에는 열려 있는 모든 터미널의 codex 세션을 끝내고 새로 시작하세요. 이미 떠 있는 프로세스는 옛 바이너리를 계속 씁니다.
데스크톱 앱은 26.1007.21434(build 13901) 이상
데스크톱 앱(ChatGPT 데스크톱 앱 안의 Codex 포함)은 26.1007.21434(build 13901, production 채널)에서 오류가 사라졌다는 확인이 #51601에 10월 9일부터 12일까지 여러 건 올라왔습니다. 한 보고에서는 Windows 패키지 번호가 26.1007.2314.0으로 표시됐습니다. 모두 elevated 설정을 그대로 두고 업데이트 설치와 앱 재시작만 했으며, 읽기 거부(deny-read) 규칙을 쓰는 Business 계정에서도 로그가 errors=[]로 끝났다는 보고가 있습니다. 이 빌드의 번들 CLI가 수정이 들어간 0.162.0-alpha.17.2라는 점도 이 결과와 맞습니다. 이후 보고에는 26.1007.9446.0, 26.1007.71326, 26.1013.x가 등장합니다.
다만 OpenAI가 "이 빌드에서 고쳤다"고 발표한 적은 없습니다. 10월 8일자 26.1007 변경 기록에는 이 수정이 없고, 10월 7일자 26.1002 항목의 "Fixed Windows sandbox refresh failures after app updates"는 이 문제가 아닙니다. 그 뒤에 나온 26.1002 패키지에서도 error 32 보고가 이어졌기 때문입니다. 비프로덕션 채널에서 언제 고쳐졌는지도 공개 자료가 없습니다.
앱의 정보(About) 화면에서 버전을 보고 26.1007.21434보다 낮으면 업데이트한 뒤, 창만 닫지 말고 시스템 트레이 아이콘에서 완전히 종료했다가 다시 여세요.
VS Code 확장
VS Code 확장에서도 같은 로그가 보고됐지만, 확장의 첫 수정 버전은 공개 자료에 나오지 않습니다. 확장을 최신으로 올리고, 같은 PC에 있는 데스크톱 앱과 CLI를 위 버전으로 맞춘 뒤 VS Code를 완전히 재시작합니다. 그다음 아래 확인 절차로 로그를 보세요.
업데이트했는데 그대로일 때: 계속 실행 중인 옛 CLI와 app-server
업데이트 후에도 같은 줄이 찍힌다면 가장 먼저 의심할 곳은 아직 옛 빌드로 돌고 있는 다른 Codex 프로세스입니다. 런타임 폴더 %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>는 데스크톱 앱과 CLI가 함께 씁니다. 그래서 데스크톱 앱을 고친 빌드로 올려도, 같은 PC에서 npm CLI 0.162.1을 쓰면 CLI 자신의 설정 도우미가 이 공용 런타임을 건드리다 똑같이 os error 32로 실패합니다(#51601 댓글, #54138, #54165).
CODEX_HOME을 따로 지정해도 이 공용 런타임은 분리되지 않습니다.- 데스크톱 앱을 완전히 끄자 옛 CLI가 동작했다는 보고도 있지만, 근본 해결은 CLI를 0.163.0 이상으로 올리는 것입니다.
- 다른 도구가
codex app-server를 비대화형으로 띄우는 경우(예: Claude Code의 codex-companion, OpenResearch)에는 그 세션이 띄운node_repl.exe가 파일을 잡고 있어서, 데스크톱 앱을 꺼도 소용이 없습니다. 이때는 모델 답변이 겉보기에 정상이라도 실제로는 명령이 하나도 실행되지 않았을 수 있습니다(#54138).
모든 구성 요소를 업데이트한 뒤에는 데스크톱 앱(트레이 포함), 모든 터미널의 codex, VS Code, codex app-server를 띄우는 도구를 전부 종료하고 아래 명령 결과가 비어 있는지 확인한 다음 다시 시작합니다. 남아 있는 프로세스는 작업 관리자에서 끝내세요.
Get-Process ChatGPT, codex, node_repl -ErrorAction SilentlyContinuenode_repl.exe만 골라서 끄는 것은 해결이 아닙니다. 새 커널이 뜨는 순간 옛 도우미는 다시 실패합니다. 여기서 모든 프로세스를 끄는 목적은 새로 설치한 빌드가 처음부터 다시 뜨게 하려는 것입니다.
업데이트했는데 그대로일 때: 옛 경로를 가리키는 CODEX_CLI_PATH
CLI 0.163.0과 데스크톱 앱 26.1002.52244를 쓰던 한 사용자는 Computer Use와 브라우저 작업만 계속 실패하는 원인을 상세한 로그와 함께 보고했습니다(#54635, 2026년 10월 16일). CODEX_CLI_PATH 값이 업데이트 후에도 옛 빌드(0.162.0-alpha.2)의 codex.exe를 가리킨 채 두 곳에 남아 있었고, 그래서 Node REPL을 띄울 때 옛 설정 도우미가 실행됐다는 것입니다. 2026년 10월 22일 기준 OpenAI 직원의 답변은 없으므로, 확정된 해결책이 아니라 점검 항목으로 보세요.
먼저 로그에서 실패한 설정 도우미가 어느 경로에서 실행됐는지 봅니다.
Select-String -Path "$env:USERPROFILE\.codex\.sandbox\sandbox*.log" -Pattern "setup refresh: spawning" |
Select-Object -Last 5실패 직전 줄이 %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex-windows-sandbox-setup.exe를 실행하고 있고, 같은 폴더의 codex.exe --version이 0.163.0보다 낮다면 이 경우입니다. 값이 남아 있는 두 곳은 다음과 같습니다.
Select-String -Path "$env:USERPROFILE\.codex\config.toml",
"$env:USERPROFILE\.codex\plugins\cache\openai-bundled\unified-computer-use\*\.mcp.json" -Pattern "CODEX_CLI_PATH"%USERPROFILE%\.codex\config.toml의[mcp_servers.node_repl.env]아래CODEX_CLI_PATH%USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\<버전>\.mcp.json의"CODEX_CLI_PATH"
보고자는 두 파일을 백업한 뒤 값을 가장 새 codex.exe로 바꾸고 Codex를 완전히 재시작해 바로 해결했습니다. 그 PC에서는 새 codex.exe가 %USERPROFILE%\.codex\packages\app-server-daemon\releases\<버전>\bin\ 아래에 있었고, 바꾸기 전에 그 파일의 --version이 0.163.0 이상인지 확인했습니다. 폴더 구성은 설치마다 다를 수 있습니다. 또 다음 업데이트가 이 값을 다시 옛 경로로 써 넣을 수 있다는 지적이 있으니, 업데이트 후 같은 증상이 돌아오면 이 두 곳부터 다시 보세요. 이 문제가 이후 업데이트에서 고쳐지는지는 아직 알려지지 않았습니다.
config.toml을 처음 열어 본다면 위치와 각 섹션의 의미는 Codex 샌드박스와 config.toml: 승인·쓰기·네트워크 경계에 정리되어 있습니다.
수정 확인: codex sandbox로 SANDBOX-OK와 errors=[] 보기
모델 호출 없이 샌드박스만 시험할 수 있습니다. 프로젝트 폴더에서 PowerShell로 실행합니다.
codex sandbox cmd /c "cd && echo SANDBOX-OK"
$LASTEXITCODE공식 문서 형식으로는 다음과 같이 씁니다(CLI 0.162.0 이상).
codex sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo SANDBOX_OK
$LASTEXITCODE성공 기준은 세 가지입니다.
- 화면에
SANDBOX-OK(또는SANDBOX_OK)가 출력되고 종료 코드가0입니다. - 오늘 날짜 sandbox 로그의 마지막 설정 기록이
setup refresh: processed N write roots …; errors=[]로 끝납니다. - 데스크톱 앱이나 VS Code에서 새 채팅을 열고
Get-Location같은 간단한 명령을 시켰을 때 실제 출력이 돌아옵니다. Computer Use나 브라우저 작업을 쓰고 있었다면 그것도 한 번 시켜 봅니다.
codex sandbox 하위 명령의 옵션은 버전에 따라 다르므로, 첫 번째 형식이 오류를 내면 두 번째 형식을 쓰세요.
효과 없는 조치: 재부팅, 재설치, 0.161.0 다운그레이드
GitHub 이슈에서 이미 시도됐지만 효과가 없었다고 보고된 조치입니다(#51601, #54325, #54635).
| 조치 | 결과 |
|---|---|
| 앱 재시작, Windows 재부팅, 새 채팅 | 새로 뜬 node_repl.exe 때문에 다시 실패 |
| 앱 재설치 | .codex 폴더의 옛 경로가 그대로 남음 |
node_repl.exe 강제 종료 | 새 커널이 뜰 때까지만 동작 |
node_repl.exe에 읽기·실행 권한(ACE) 직접 추가 | 변화 없음 |
| npm CLI를 0.161.0으로 낮추기 | 0.161.0도 같은 결함이 있음 |
데스크톱 앱을 26.930.7945.0으로 되돌렸다는 커뮤니티 답변도 있지만, 공개된 검증 자료가 없고 이미 수정된 빌드가 나와 있으므로 권하지 않습니다. 파일 소유자 변경, icacls로 권한 넓히기, Windows Defender 같은 보안 기능 끄기, 상시 전체 접근 권한(full access) 사용도 error 32의 해결책이 아닙니다. 소유자와 ACL 변경은 접근 거부(error 5)를 다룰 때의 조치이고, 공유 위반은 권한이 아니라 "파일이 열려 있다"는 문제이기 때문입니다.
당장 업데이트할 수 없을 때: unelevated 임시 우회와 대가
회사 PC라 업데이트가 늦게 들어오는 등 지금 바로 수정 버전을 쓸 수 없다면, %USERPROFILE%\.codex\config.toml의 샌드박스 구현을 unelevated로 바꿔 elevated 설정 도우미를 우회할 수 있습니다.
[windows]
sandbox = "unelevated"이것은 해결이 아니라 대가가 있는 임시 우회입니다. 공식 Windows 샌드박스 문서는 unelevated를 "elevated 설정을 쓸 수 없고 조직 정책이 허용할 때의 레거시 대체(fallback)"로 설명합니다. 현재 사용자에게서 파생된 제한 토큰으로 명령을 실행하므로, elevated보다 네트워크 격리가 약하고 읽기 금지 경로(denied read paths)를 지원하지 않습니다.
- 결과가 사람마다 다릅니다. OpenAI 커뮤니티 포럼에서는 명령이 다시 실행됐다는 사용자가 있었지만,
cannot enforce split writable root sets로 실패했다는 보고와sandbox_mode = "workspace-write"를 함께 넣어야 동작했다는 보고도 있습니다(#51601 댓글). - 회사 정책이 막을 수 있습니다. 관리자가
requirements.toml의allowed_sandbox_implementations = ["elevated"]로 unelevated 대체를 금지했다면 쓸 수 없습니다. 그럴 때는 IT 담당자에게 업데이트를 요청하세요. - 업데이트 후에는 되돌립니다. 수정 버전으로 올린 뒤
sandbox = "elevated"로 돌려놓고 확인 절차를 다시 실행합니다.
샌드박스 모드와 승인 정책의 관계는 Codex 샌드박스와 config.toml: 승인·쓰기·네트워크 경계에서 더 자세히 볼 수 있습니다.
MXC 샌드박스의 0x80070020은 별개의 미해결 문제
공식 문서는 이제 호환되는 Windows 기기에서 mxc를 권장 샌드박스로, elevated를 우선 레거시 대체로 안내합니다. MXC는 관리자 승인 설정이나 별도 Windows 계정, 방화벽 규칙 없이 동작하며, 데스크톱 앱은 개인 계정에서 기기가 지원하면 자동으로 MXC를 우선 사용합니다. CLI에서는 config.toml에 다음을 넣습니다.
[features]
prefer_mxc = trueMXC에는 Windows 11 24H2(build 26100.9278) 또는 25H2(build 26200.9278) 이상과 Microsoft가 배포 중인 MXC 기능이 필요합니다. 설정을 바꾸지 않고 명령 하나로 지원 여부를 시험할 수 있습니다(CLI 0.162.0 이상).
codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODEMXC_OK와 종료 코드 0이 나오면 그 기기에서 MXC를 쓸 수 있습니다.
다만 MXC 경로에도 공유 위반이 따로 보고돼 있습니다. Windows 11 25H2와 데스크톱 앱 26.1013.40934에서 CreateProcessSecurityEnvironment failed (HRESULT = 0x80070020)가 나는 문제로, 0x20이 같은 공유 위반이지만 elevated 도우미의 error 32와는 다른 갈래입니다. 한 사용자는 -c features.prefer_mxc=true로 MXC를 우선할 때만 재현됐고 MXC를 쓰지 않는 CLI는 정상이었다고 했으며, 다른 사용자는 ChatGPT 데스크톱 앱 안에서만 이 오류가 나고 npm CLI 0.163.0은 정상이라고 했습니다. 0.163.0의 수정으로 해결되는 문제가 아니며, 2026년 10월 22일 기준 #55230은 열려 있고 OpenAI 직원의 답변도 없습니다.
error 32가 아닌 Codex 샌드박스 오류: error 5·1385·740
Codex Windows 샌드박스 오류는 여러 종류가 있고, 관리자 샌드박스 설정 실패나 ACL 오류는 이번 error 32와 원인이 다릅니다. 로그의 오류 번호로 구분하세요.
| 오류 | 뜻 | 방향 |
|---|---|---|
error 5, helper_sandbox_lock_failed, SetNamedSecurityInfoW … failed: 5 | 접근 거부 | 실제 권한 문제이므로 파일·폴더 소유권과 ACL을 점검(#45734, #49025) |
| error 1385 | 샌드박스 사용자에게 필요한 로그온 유형이 정책상 거부됨 | IT 담당자에게 로그온 권한 확인 요청, 급하면 정책이 허용하는 범위에서 unelevated |
| error 740 | 권한 상승(elevation)이 필요한 단계에서 막힘 | 관리자 승인을 받을 수 있는 상태에서 elevated 설정 재시도 |
CreateProcessAsUserW failed | 샌드박스 사용자로 프로세스를 만들지 못함 | sandbox 로그의 앞뒤 줄로 원인 확인 |
| "Couldn't set up admin sandbox" 등 레거시 설정 실패 | UAC 거절, 로컬 사용자·방화벽 변경 금지 등 | 설정 재시도 후 관리자 승인, 회사 PC는 IT 주도 설정 |
공식 문서의 문제 해결 항목은 레거시 설정 실패와 1385를 다루지만 error 32는 다루지 않습니다. IT 담당자가 직원 PC에 elevated 샌드박스를 미리 준비하는 명령은 다음과 같습니다(관리자 권한 배포 프로세스에서 실행).
codex sandbox setup --elevated --user 'DOMAIN\alice' --codex-home 'C:\Users\alice\.codex'명령 실패가 아니라 앱 자체가 열리지 않거나 failed to start codex app-server가 뜬다면 다른 문제입니다. failed to start codex app-server 해결: Windows 앱·CLI 오류 문구별 조치를 보세요.
수정 버전에서도 계속되면 OpenAI에 보낼 정보
CLI 0.163.0 이상, 데스크톱 앱 26.1007.21434 이상으로 맞추고 모든 프로세스를 재시작했는데도 node_repl.exe의 os error 32가 계속 찍히면, GitHub 이슈나 지원 요청에 다음을 첨부합니다(#54325의 직원 안내, 공식 문서).
- 재시작 후 새로 쌓인 sandbox 로그(
%USERPROFILE%\.codex\.sandbox\아래 오늘 날짜 파일) - CLI 버전(
codex --version)과 daemon·데스크톱 앱 버전 - 쓰고 있는 샌드박스 구현(
mxc,elevated,unelevated) - Windows 빌드 번호와 Windows 10/11 여부
- 앱에 표시된 오류 문구 그대로
%USERPROFILE%\.codex\.sandbox-secrets\ 폴더의 내용은 보내지 마세요. 공식 문서가 첨부하지 말라고 명시한 폴더입니다.
Codex 오류 32 자주 묻는 질문
Codex 오류 32는 내 프로젝트 폴더 권한 문제인가요?
아닙니다. 실패하는 파일은 프로젝트가 아니라 %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\ 아래의 Codex 런타임(node_repl.exe, VCRUNTIME140_1.dll)이고, 그 파일을 쓰고 있는 것도 Codex 자신입니다. 프로젝트를 옮기거나 폴더 권한을 바꿔도 달라지지 않으며, CLI 0.163.0 이상과 데스크톱 앱 26.1007.21434 이상으로 업데이트해야 풀립니다.
Computer Use나 브라우저 작업만 실패해도 같은 오류 32인가요?
node_repl kernel exited unexpectedly나 trusted Node process exited unexpectedly가 나오고 sandbox 로그에 node_repl.exe의 os error 32가 있다면 같은 문제일 가능성이 큽니다. 이 경우 앱과 CLI를 이미 업데이트했다면 CODEX_CLI_PATH가 옛 빌드를 가리키고 있지 않은지(위 절) 먼저 확인하세요.
unelevated로 바꿔 두었는데 그대로 써도 되나요?
수정 버전으로 업데이트했다면 elevated로 되돌리는 것이 좋습니다. unelevated는 elevated보다 네트워크 격리가 약하고 읽기 금지 경로를 지원하지 않는, 공식 문서상 레거시 대체입니다. 되돌린 뒤 codex sandbox 확인 명령이 종료 코드 0으로 끝나는지 보세요.
