ว่าด้วยกรณีที่ gpt-5.6-sol เกือบลบโฮมไดเรกทอรีของผู้ใช้เพราะชนกับตัวแปร $HOME ของ PowerShell
(gist.github.com/xamong)ขณะใช้งาน gpt-5.6-sol ซึ่งเป็นโมเดลเรือธงรุ่นล่าสุดใน Codex ผมอยากแชร์เหตุการณ์ด้านความปลอดภัยร้ายแรง (Safety Incident) ที่เพิ่งเจอมา แม้โมเดล Sol จะทำผลงานได้อย่างน่าทึ่งเกินเชื่อในเวิร์กโฟลว์แบบเอเจนต์และเบนช์มาร์กการเรียกใช้เครื่องมือ แต่การไม่มีการแยกสภาพแวดล้อมของเชลล์อย่างง่าย ๆ ก็เกือบนำไปสู่หายนะครั้งใหญ่ได้
ลำดับเหตุการณ์:
เอเจนต์กำลังพยายามตั้งค่าไดเรกทอรี baseline ชั่วคราวสำหรับงานดีบัก เพื่อทำเช่นนั้น เอเจนต์ได้สร้างและรัน PowerShell script block ที่กำหนดค่า local variable ชื่อ $home
$home = Join-Path $env:TEMP 'temporary-build-folder'
if (Test-Path -LiteralPath $home) { Remove-Item -LiteralPath $home -Recurse -Force }
สาเหตุของบั๊ก:
ใน PowerShell นั้น $HOME เป็น built-in automatic variable ที่ชี้ไปยังโปรไฟล์ไดเรกทอรีของผู้ใช้ปัจจุบันโดยตรง (เช่น C:\Users\<username>)
ปัญหาคือ PowerShell ไม่แยกแยะตัวพิมพ์เล็ก-ใหญ่ (case-insensitive) ด้วยเหตุนี้ local variable ชื่อ $home ที่เอเจนต์ประกาศขึ้นแบบไดนามิกจึงไปชนกับสโคประดับ global ของ $HOME เมื่อสคริปต์รันมาถึงบรรทัด Remove-Item เส้นทางนี้จึงถูกประเมินเป็นโฟลเดอร์รากของผู้ใช้จริงของผม ไม่ใช่โฟลเดอร์ชั่วคราว
ผลคือ gpt-5.6-sol ได้รันคำสั่งต่อไปนี้:
Remove-Item -LiteralPath 'C:\Users\<username>' -Recurse -Force
ความเสียหาย:
โชคดีที่มี system lock สำหรับไฟล์ที่กำลังใช้งานอยู่ คำสั่งจึงหยุดกลางทางพร้อมแสดงข้อผิดพลาด WriteError: Directory is not empty ทำให้รอดพ้นจากการถูกลบทั้งโฟลเดอร์แบบหวุดหวิด อย่างไรก็ตาม เอเจนต์ตรวจพบความผิดพลาดของตัวเองในทันที จึงยกเลิกการทำงาน (abort) และทำการตรวจสอบตนเอง ผลที่พบคือมีไฟล์ตั้งค่าบางส่วนและ dotfiles บางรายการ (.ssh, .config, .npm) ถูกแก้ไขหรือหายไปแล้ว
ข้อสังเกตสำคัญ:
gpt-5.6-sol มีความสามารถสูงและทำงานได้อย่างน่าประทับใจมากสำหรับงานระยะยาว (long-horizon tasks) แต่เมื่อเราให้สิทธิ์โมเดลให้เข้าถึง host terminal ได้โดยตรง กลไกการไม่แยกแยะตัวพิมพ์เล็ก-ใหญ่และการจัดการ variable scope ของเชลล์อย่าง PowerShell จะกลายเป็นปัจจัยเสี่ยงขนาดใหญ่ (risk vector)
หากคุณกำลังวางแผนจะสร้างหรือดีพลอย CLI agent โดยใช้ GPT-5.6 ตระกูลใหม่ การทำ sandboxing ที่เข้มงวดและการทำ containerization ที่แข็งแรงไม่ใช่ทางเลือกอีกต่อไป แต่เป็นสิ่งจำเป็นอย่างยิ่ง
มีใครในที่นี้เคยเจอพฤติกรรมคล้ายกันเกี่ยวกับ variable shadowing หรือการใช้เครื่องมือแบบทำลายล้าง ขณะใช้งาน Sol หรือโมเดลอื่น ๆ รุ่นล่าสุดบ้างไหม?
ลิงก์สกรีนช็อตของเหตุการณ์ในตอนนั้น: https://gist.github.com/xamong/e98478b333bb9951b175284f744eb0ed
2 ความคิดเห็น
โชคดีที่ codex ไม่ได้ยกระดับสิทธิ์เองนะครับ
ต้องจัดการเองสิ