ZCode แพ็กทั้งเวิร์กสเปซรวม .git ส่งขึ้น Aliyun OSS เงียบ ๆ — สวิตช์ปิดใน UI ไม่มีผล และกุญแจถอดรหัสอยู่ฝั่ง Z.ai เท่านั้น

18 ก.ย. 2026 นักพัฒนาที่ใช้ชื่อ ferstar เผยแพร่บทความย้อนรอยโค้ดของ ZCode — แอปเอเจนต์เขียนโค้ดของ Z.ai (Zhipu) ที่เราเคยเขียนถึงตอนเปิดตัวเมื่อ ก.ค. 2026 — และพบว่าตัวแอป แพ็กเวิร์กสเปซทั้งก้อนรวมโฟลเดอร์ .git เข้ารหัส แล้วอัปโหลดขึ้น object storage ของ Alibaba Cloud โดยผู้ใช้ไม่รู้ตัว เรื่องขึ้นหน้าแรก Hacker News สองกระทู้ภายในวันเดียว และ เย็นวันเดียวกัน Z.ai ออกแถลงการณ์ขอโทษ พร้อมยอมรับว่าฟีเจอร์นี้ “เปิดเป็นค่าเริ่มต้น” ในช่วงต้น

จุดที่ทำให้เรื่องนี้ร้ายแรงกว่า “เอเจนต์ส่งโค้ดขึ้นคลาวด์” แบบปกติ คือ สิ่งที่ถูกส่งไม่ใช่แค่ไฟล์ที่คุณกำลังแก้ แต่เป็นประวัติทั้งหมดของ repo — และ สวิตช์ปิดที่มีอยู่ใน UI ไม่ได้ทำงาน

สิ่งที่ ferstar เจอในโค้ด

ferstar แกะ app.asar ของแอป Electron แล้วลากเส้นทางการอัปโหลดออกมาได้ทั้งท่อ:

• แอปขอ credential จาก POST https://zcode.z.ai/api/v1/snapshot/upload-credential ได้ลายเซ็นฟอร์มของ Aliyun OSS กลับมาพร้อม public key
• แพ็กเวิร์กสเปซ เข้ารหัสในเครื่อง แล้ว POST ตรงขึ้น Aliyun OSS จากนั้นยิง callback กลับไปลงทะเบียน snapshot ที่แบ็กเอนด์ของ Zhipu
• จุดที่ทริกเกอร์มีสองจุด: captureBeforePrompt (ก่อน prompt ทุกครั้ง) และตอนจบงานที่ติดแท็ก repo-wiki-update — เซสชันเดียวในการทดสอบเกิด capture ถึง 62 ครั้ง

เนื้อหาที่ถูกแพ็ก อ่านได้จาก manifest ที่เก็บไว้เป็น plaintext ในเครื่อง: เวิร์กสเปซตัวอย่างขนาด 345 MB ถูกแพ็กเป็น payload 313 MB / 42,411 ไฟล์ โดย node_modules และ dependency ถูกตัดออก แต่ .git ไม่ถูกตัด และกินสัดส่วนถึง 86.6% ของ payload — แยกเป็น .git/lfs/ 56.8%, .git/objects/ 29.6% เหลือซอร์สโค้ดกับเอกสารจริง ๆ เพียง 13.4%

นี่คือประเด็นที่ควรหยุดอ่านสักครู่ ถ้าสิ่งที่ถูกส่งคือ .git ทั้งโฟลเดอร์ แปลว่าสิ่งที่หลุดออกไปไม่ใช่สถานะปัจจุบันของโค้ด แต่คือ:

• API key และ config ที่เคย commit แล้วลบทิ้งใน commit หลัง — ลบจาก working tree ไม่ได้แปลว่าหายจาก .git/objects
• ชื่อ branch ที่ยังไม่ push ซึ่งมักบอกใบ้แผนผลิตภัณฑ์ที่ยังไม่ประกาศ
• ภายใน .git/config — remote URL, internal hostname, ชื่อเซิร์ฟเวอร์ภายในองค์กร
• .git/lfs/ — ไฟล์ไบนารีขนาดใหญ่ที่ทีมเก็บผ่าน Git LFS

มีข้อโต้แย้งบน Hacker News ว่าบทความที่หลายคนอ่าน (ฉบับเรียบเรียงบน tokenstead.ai) เขียนกำกวมจนหลายคนเข้าใจว่าเป็นแค่ “commit message” — ไม่ใช่ ต้นฉบับของ ferstar พูดถึง repository ทั้งก้อน ไม่ใช่แค่ git log และตัวเลข 313 MB ก็มาจาก manifest ไม่ใช่จากการเดา

กุญแจอยู่ที่ใคร และสวิตช์ปิดทำงานไหม

สองข้อนี้คือแกนของเรื่อง

เรื่องกุญแจ: ไฟล์ถูกเข้ารหัสด้วย AES-256-CTR แล้วห่อกุญแจสมมาตรนั้นด้วย RSA-OAEP-SHA256 — ฟังดูแน่นหนาดี แต่รายละเอียดสำคัญคือ public key ที่ใช้ห่อถูกเซิร์ฟเวอร์ส่งมาให้สด ๆ ตอนอัปโหลด ส่วน private key อยู่บนคลาวด์ฝั่งเดียว แปลว่าผู้ใช้ไม่มีทางถอดรหัส snapshot ของตัวเองได้เลย นี่คือความต่างระหว่าง “แบ็กอัปให้ผู้ใช้” กับ “เก็บข้อมูลเข้าฝั่งผู้ให้บริการ” — ถ้าเป็นแบ็กอัปจริง กุญแจควรอยู่กับเจ้าของข้อมูล

เรื่องสวิตช์: ใน UI มีตัวเลือกสองตัวที่ชื่อบ่งว่าควรปิดพฤติกรรมนี้ได้ — optimizeAgentExperienceEnabled และ repoSnapshotIndexingEnabled — แต่ ferstar สรุปว่า ทั้งคู่ไม่มีผล เพราะ sidecar ที่ทำหน้าที่ capture ถูก instantiate แบบไม่มีเงื่อนไขตอนแอปสตาร์ต และไม่มี if ตรวจค่า preference ก่อนทำงานเลย

วิธีกันที่ ferstar แนะนำจึงไม่ใช่การไปกดปิดในแอป แต่เป็นการล็อกที่ระดับไฟล์ซิสเต็ม — chflags uchg บน macOS หรือ chattr +i บน Linux

คำแถลงของ Z.ai และสิ่งที่ยังค้าง

เย็นวันที่ 18 ก.ย. 2026 ZCode ออกแถลงการณ์ (เผยแพร่ครั้งแรกเป็นภาษาจีน) ใจความว่า:

• ปัญหามาจากฟีเจอร์ “codebase indexing” ที่ออกแบบมาเพื่อสร้าง index ของ repo ในเครื่อง รองรับ checkpoint restore, rollback และ Repo Wiki
• ตอน Repo Wiki สร้างหน้า Wiki มันอาจทริกเกอร์การอัปโหลดข้อมูล repo และหลังสร้างหน้าเสร็จบนคลาวด์ “ข้อมูลที่อัปโหลดจะถูกทำลายทันทีและไม่ถูกจัดเก็บ”
• ฟีเจอร์นี้ เปิดเป็นค่าเริ่มต้นในช่วงต้นหลังเปิดตัว ทำให้ผู้ใช้บางส่วนได้รับผลกระทบ — และ “ตอนนี้แก้ไขแล้ว”
• สัญญาว่าจะ เปิดซอร์สโค้ดของ ZCode ในเร็ววัน และ เชิญผู้ประเมินอิสระภายนอก มาตรวจสอบการทำงานของระบบ พร้อมทยอยเผยแพร่ความคืบหน้า
• ชดเชยด้วยการ รีเซ็ตโควตารายสัปดาห์ให้ผู้ใช้ ZCode ทุกคนเพิ่มอีกหนึ่งครั้ง ในวันเดียวกัน

เป็นการตอบสนองที่เร็วและตรงไปตรงมากว่าค่าเฉลี่ยของอุตสาหกรรมพอสมควร แต่มีช่องว่างที่ยังไม่ถูกปิด และทีมที่ใช้งานอยู่ควรตั้งคำถามต่อ:

1. “ทำลายทันที” ไม่ตรงกับสถาปัตยกรรมกุญแจ — ถ้าข้อมูลถูกทิ้งทันทีหลังสร้าง Wiki ทำไมต้องออกแบบให้ private key อยู่ฝั่งเซิร์ฟเวอร์เท่านั้น และทำไมต้องลงทะเบียน snapshot กลับไปที่แบ็กเอนด์
2. คำอธิบาย “Repo Wiki” ไม่ครอบคลุม captureBeforePrompt — จุดทริกเกอร์ก่อน prompt ทุกครั้ง กับ 62 capture ต่อเซสชัน ไม่ใช่พฤติกรรมของฟีเจอร์ที่ทำงานตอนสร้าง Wiki
3. ยังไม่มีคำอธิบายว่าทำไมสวิตช์ปิดถึงไม่ทำงาน ซึ่งเป็นข้อกล่าวหาที่หนักที่สุดในรายงาน เพราะมันเปลี่ยนเรื่องจาก “ค่าเริ่มต้นแย่” เป็น “UI บอกอย่าง โค้ดทำอีกอย่าง”
4. นโยบายความเป็นส่วนตัวไม่เคยระบุเรื่องนี้ — ผู้ใช้บน HN ชี้ว่าไม่มีบรรทัดใดพูดถึงการแพ็กและอัปโหลดเวิร์กสเปซทั้งก้อน

คำสัญญาข้อที่มีน้ำหนักที่สุดคือ การเปิดซอร์ส ZCode เพราะเป็นข้อเดียวที่ตรวจสอบได้จากภายนอก ส่วนข้ออื่นต้องเชื่อคำพูด

สิ่งที่ทีมควรทำวันนี้

ไม่ว่าคุณจะใช้ ZCode หรือไม่ นี่คือรายการที่คุ้มกับเวลาครึ่งชั่วโมง:

• ถ้าเคยใช้ ZCode กับ repo งาน ให้ถือว่าประวัติ .git ของ repo นั้น “หลุด” ไว้ก่อน แล้วไล่ rotate ความลับทุกตัวที่เคยอยู่ในประวัติ commit ไม่ใช่แค่ที่อยู่ใน working tree ปัจจุบัน (git log -p -S'<คีย์เวิร์ด>' ช่วยไล่ได้)
• รัน coding agent ในคอนเทนเนอร์หรือ user account แยก ที่เห็นเฉพาะโฟลเดอร์ที่จำเป็น — นี่กันได้ทั้งการอัปโหลดโดยตั้งใจและโดยบั๊ก
• ตรวจ traffic จริงหนึ่งครั้งด้วย mitmproxy ก่อนอนุมัติเครื่องมือใหม่เข้าองค์กร ใช้เวลาไม่นานและตอบคำถามที่เอกสารไม่ตอบ
• อย่าเชื่อสวิตช์ในแอปเป็นการควบคุมเชิงความปลอดภัย — สวิตช์คือ preference ส่วนการควบคุมคือ network policy, sandbox และสิทธิ์ไฟล์

มุมมอง AI Curator

ตอนเราเขียนถึง ZCode เมื่อ 5 ก.ค. 2026 เราจบโพสต์ด้วยข้อสังเกตว่ามันเป็น เอเจนต์โคลสซอร์สจากผู้ให้บริการจีน ที่เอกสารยังไม่ระบุชัดเรื่อง data residency และเราแนะนำให้ทีมที่มีข้อกำหนดกำกับดูแลโฮสต์ GLM เองแทนที่จะยิงตรงเข้า API สองเดือนครึ่งต่อมา ความเสี่ยงนั้นเป็นจริง — แต่ผมอยากให้ข้อสรุปของเรื่องนี้ ไม่ใช่ “อย่าใช้เครื่องมือจีน” เพราะนั่นคือบทเรียนที่ผิด

บทเรียนที่ถูกคือ: เอเจนต์เขียนโค้ดคือซอฟต์แวร์ที่ได้สิทธิ์อ่านทุกอย่างในเครื่องคุณ และเราอนุมัติสิทธิ์ระดับนั้นด้วยการกดปุ่ม Download ไม่ต่างจากการติดตั้ง IDE plugin เมื่อสิบปีก่อน ความต่างคือเอเจนต์มีเหตุผลทางเทคนิคที่ดูสมเหตุสมผลเสมอที่จะอ่านทั้ง repo — มันต้องการ context จริง ๆ — และนั่นทำให้เส้นแบ่งระหว่าง “อ่านเพื่อทำงาน” กับ “อัปโหลดเพื่อ index” บางจนมองไม่เห็นจากฝั่งผู้ใช้ ถ้าวันนี้เป็น Z.ai พรุ่งนี้ก็เป็นใครก็ได้ที่อยากทำฟีเจอร์ “จำ repo ของคุณได้ข้ามเครื่อง” — และคนทำจะไม่รู้สึกว่ากำลังทำอะไรผิดด้วยซ้ำ

สำหรับทีมไทย ผมคิดว่าประเด็นที่จับต้องได้ที่สุดคือ .git ไม่ใช่โค้ด แต่คือบันทึกความลับสะสมของทีม หลายองค์กรในบ้านเรายังมีวัฒนธรรม “เผลอ commit .env แล้วค่อยลบ commit หลัง” ซึ่งปลอดภัยพอเมื่อ repo อยู่บน GitHub ส่วนตัว แต่พังทันทีเมื่อมีเครื่องมือบนเดสก์ท็อปแพ็ก .git ทั้งก้อนส่งออกไป ถ้าจะทำอะไรอย่างเดียวจากข่าวนี้ ผมเสนอให้ไล่สแกนประวัติ commit ขององค์กรด้วย gitleaks หรือ trufflehog แล้ว rotate สิ่งที่เจอ — เป็นงานที่ควรทำอยู่แล้วและข่าวนี้แค่ให้เหตุผลที่จะได้เวลาทำจริง

ข้อสุดท้าย: ทางเลือก “รันโมเดลเปิดน้ำหนักด้วย harness ที่เปิดซอร์ส” เพิ่งมีน้ำหนักขึ้นอีกขั้น GLM-5.3 และ GLM-5.3-Flash เปิดน้ำหนักอยู่แล้ว ถ้าทีมอยากได้คุณภาพของโมเดล Z.ai โดยไม่ต้องเชื่อไคลเอนต์ของ Z.ai เส้นทางนั้นเปิดอยู่และวันนี้ต้นทุนของการเลือกมัน ถูกลงเมื่อเทียบกับต้นทุนของการเชื่อผิด

แหล่งข่าว

• Inside ZCode: Silently Uploading Your Entire Git History to the Cloud — blog.ferstar.org (18 ก.ย. 2026)
• กระทู้ Hacker News ของรายงานต้นฉบับ (รวมคำแถลงของ Z.ai ที่ถูกแปล)
• รายงานคำแถลงขอโทษของ Zhipu/ZCode — PANews (18 ก.ย. 2026)
• โพสต์ของเราตอน ZCode เปิดตัว (5 ก.ค. 2026)