gpt-5.6-sol이 PowerShell의 $HOME 변수 충돌로 사용자 홈 디렉터리를 날려버릴 뻔한 건에 대하여
(gist.github.com/xamong)Codex에서 최신 플래그십 모델인 gpt-5.6-sol을 사용하던 중, 방금 겪은 심각한 안전성 결함(Safety Incident)을 공유하고자 합니다. Sol 모델이 에이전트 워크플로우와 도구 실행 벤치마크에서 믿기 힘들 정도로 놀라운 성적을 보여주었음에도 불구하고, 단순한 쉘 환경 격리 부재로 인해 하마터면 대재앙으로 이어질 뻔했습니다.
발생 경위:
에이전트는 디버깅 작업을 위해 임시 기준(baseline) 디렉터리를 설정하려고 시도 중이었습니다. 이를 위해 에이전트는 $home이라는 이름의 로컬 변수를 초기화하는 PowerShell 스크립트 블록을 생성하고 실행했습니다.
$home = Join-Path $env:TEMP 'temporary-build-folder'
if (Test-Path -LiteralPath $home) { Remove-Item -LiteralPath $home -Recurse -Force }
버그 원인:
PowerShell에서 $HOME은 현재 사용자의 프로필 디렉터리(예: C:\Users<username>)를 직접 가리키는 기본 내장 자동 변수(built-in, automatic variable)입니다.
문제는 PowerShell이 대소문자를 구분하지 않는다(case-insensitive)는 점입니다. 이 때문에 에이전트가 동적으로 선언한 소문자 $home 변수가 전역 $HOME 스코프와 충돌을 일으켰습니다. 스크립트가 Remove-Item 라인에 도달했을 때, 이 경로는 임시 폴더가 아니라 저의 실제 사용자 루트 디렉터리로 평가되고 말았습니다.
결과적으로 gpt-5.6-sol은 다음 명령을 실행했습니다:
Remove-Item -LiteralPath 'C:\Users<username>' -Recurse -Force
피해 상황:
다행히도 현재 활성화되어 있는 파일들에 대한 시스템 잠금(Lock) 덕분에, 명령어가 실행되는 도중 WriteError: Directory is not empty 에러를 뱉으며 멈추었고, 전체 삭제되는 가공할 참사는 면할 수 있었습니다. 하지만 에이전트는 즉시 자신의 실수를 감지하고 작업을 중단(abort)한 뒤 자체 감사를 실시했습니다. 확인 결과 몇몇 설정 파일과 도트파일들(.ssh, .config, .npm)은 이미 수정되었거나 사라진 상태였습니다.
시사점:
gpt-5.6-sol은 긴 호흡의 작업(long-horizon tasks)을 수행하는 데 있어 놀라울 정도로 끈기 있고 유능합니다. 하지만 우리가 이러한 고급 추론 모델에게 호스트 터미널에 직접 접근할 수 있는 권한을 부여할 때, PowerShell과 같은 쉘에서의 대소문자 미구분 및 변수 스코프 메커니즘은 거대한 위험 요인(risk vector)이 됩니다.
새로운 GPT-5.6 제품군을 활용해 CLI 에이전트를 구축하거나 배포하려는 계획이 있다면, 엄격한 샌드박싱(sandboxing)과 견고한 컨테이너화는 이제 선택이 아닌 절대적인 필수 사항입니다.
혹시 여러분 중에서도 Sol이나 최근 다른 모델들을 사용하면서 이와 유사한 변수 섀도잉(variable-shadowing)이나 파괴적인 도구 사용 동작을 겪으신 분이 계시는가요?
당시 상황의 스크린샷 링크입니다: https://gist.github.com/xamong/e98478b333bb9951b175284f744eb0ed