ปัญหาที่ Claude Code รัน `git reset --hard origin/main` ในรีโพซิทอรีของโปรเจ็กต์ทุก ๆ 10 นาที

 (github.com/anthropics)
3 คะแนน โดย GN⁺ 2026-03-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีรายงานว่าในสภาพแวดล้อม macOS การเปลี่ยนแปลงในโปรเจ็กต์ถูก ลบโดยอัตโนมัติทุก ๆ 10 นาที
  • จากการตรวจสอบ พบว่าสาเหตุไม่ได้มาจาก Claude Code แต่เป็น เครื่องมืออัตโนมัติแบบโลคัลอีกตัวที่ผู้ใช้สร้างขึ้นเอง ซึ่งรัน git reset --hard origin/main เป็นระยะผ่าน GitPython
  • เนื่องจากใช้ ไดเรกทอรีทำงาน เดียวกัน จึงทำให้ดูเหมือนว่า Claude Code เป็นต้นเหตุ แต่จริง ๆ แล้วเป็นสคริปต์ภายนอกที่ทำการรีเซ็ต
  • ทีม Claude Code ชี้แจงอย่างชัดเจนว่าไม่มีลอจิกสำหรับรันคำสั่งดังกล่าวในโค้ดภายใน และอธิบายว่าพฤติกรรมคล้ายกันจะเกิดขึ้นได้ก็ต่อเมื่อใช้ตัวเลือก --dangerously-skip-permissions เท่านั้น
  • สุดท้ายจึงสรุปว่าอีชูนี้ ไม่ใช่บั๊กของ Claude Code แต่เป็นปัญหาจากเครื่องมือของผู้ใช้เอง และมีการแก้ชื่อเรื่องก่อนปิดอีชู

อาการของปัญหาและสภาพแวดล้อม

  • พบว่า Claude Code ทำ git fetch origin และ git reset --hard origin/main ทุก ๆ 10 นาที ในรีโพซิทอรีโปรเจ็กต์ของผู้ใช้
  • พฤติกรรมนี้จะ ลบการเปลี่ยนแปลงทั้งหมดของไฟล์ที่ถูกติดตามแต่ยังไม่ได้ commit ขณะที่ไฟล์ที่ยังไม่ถูกติดตามจะยังคงอยู่
  • ในสภาพแวดล้อม Git worktree จะไม่เกิดการรีเซ็ตลักษณะนี้
  • ข้อมูลสภาพแวดล้อม
    • เวอร์ชัน Claude Code: 2.1.87 (Homebrew cask, Bun binary)
    • OS: macOS 15.4 (Darwin 25.3.0, arm64)
    • Shell: zsh

กระบวนการตรวจสอบ

  • ใน Git reflog มีบันทึก reset: moving to origin/main มากกว่า 95 ครั้ง โดยเกิดขึ้นทุก ๆ 10 นาที
    • แม้ offset ของแต่ละเซสชันจะต่างกัน แต่ภายในแต่ละเซสชันจะเกิดซ้ำทุก 600 วินาทีอย่างแม่นยำ
  • ใน การทดสอบจำลองแบบเรียลไทม์ ไฟล์ที่ถูกติดตาม (api.ts) จะถูกคืนกลับสภาพเดิมเมื่อถึงจังหวะรีเซ็ต ส่วนไฟล์ที่ไม่ถูกติดตาม (.canary-test.txt) ยังคงอยู่
  • จากการเฝ้าดูไดเรกทอรี .git/ ด้วย fswatch พบแพตเทิร์นที่ไฟล์ .git/refs และ .git/logs/HEAD ถูกแก้ไขในช่วงเวลาที่เกิดการรีเซ็ต
  • ผลจาก lsof พบว่ามีเพียง Claude Code CLI เท่านั้นที่ใช้ CWD ของรีโพซิทอรีดังกล่าว
  • ไม่พบ process ของ git ภายนอก จึงคาดว่าอาจถูกทำงานภายในผ่าน libgit2 หรือวิธีที่คล้ายกัน
  • ในสภาพแวดล้อม worktree ไม่พบบันทึกการรีเซ็ตใน reflog เลย

สาเหตุที่ถูกตัดทิ้ง

  • ยืนยันแล้วว่า ไม่เกี่ยวข้อง กับ Git hooks, Claude Code user hooks, การอัปเดตปลั๊กอิน, การซิงก์คลาวด์ของ macOS, Cron/LaunchAgents, IDE, Time Machine, เครื่องมือเฝ้าดูไฟล์ ฯลฯ
  • แต่ละรายการถูกตัดทิ้งจากการตรวจสอบไฟล์คอนฟิกและ process จริง

การวิเคราะห์ไบนารี (บางส่วน)

  • ในไบนารีของ Claude Code มีบางฟังก์ชันที่รวมโค้ดสำหรับรันคำสั่ง ["fetch","origin"]
  • แม้จะมีฟังก์ชัน wrapper ของ git pull และลอจิกจัดการสถานะ fileHistory แต่ไม่พบ ตัวจับเวลาแบบทุก 10 นาที

ผลกระทบ

  • การเปลี่ยนแปลงที่ยังไม่ได้ commit ถูก ลบอัตโนมัติทุก 10 นาที ทำให้ระหว่างเซสชัน 2 ชั่วโมง การแก้ไขหายไปมากกว่า 3 ครั้ง
  • เมื่อ commit การเปลี่ยนแปลงทั้งหมดแล้ว การรีเซ็ตจะไม่มีผล จึงทำให้ปัญหานี้ดูเหมือนเกิดขึ้นเป็นพัก ๆ

คำตอบจากทีม Claude Code

  • Jarred-Sumner ระบุอย่างชัดเจนว่า “ใน Claude Code เองไม่มีโค้ดที่รัน git reset --hard origin/main”
  • เขาอธิบายว่าเมื่อใช้ตัวเลือก --dangerously-skip-permissions Claude จะสามารถ รันคำสั่งเชลล์ได้โดยไม่ต้องถามยืนยัน และหากใช้คำสั่ง /loop 10m <prompt> เพื่อให้ร้องขอ “ซิงก์กับรีโมต” เป็นระยะ ก็อาจรัน git fetch && git reset --hard origin/main ได้
  • วิธีตรวจสอบที่แนะนำคือ
    1. grep -r "reset --hard" ~/.claude/projects/ เพื่อค้นหาใน session log
    2. รัน claude --debug-file /tmp/debug.txt --dangerously-skip-permissions แล้วรอ 10 นาที จากนั้นค้นหา grep -i bash /tmp/debug.txt | grep reset
  • ฟีเจอร์ fileHistory ของ Claude Code ไม่เกี่ยวข้องกับ git และภายในก็ไม่ได้เรียก git reset

ข้อสรุปสุดท้าย

  • ในอัปเดตวันที่ 30 มีนาคม 2026 ยืนยันว่า ต้นตอที่แท้จริงของปัญหาไม่ใช่ Claude Code แต่เป็นเครื่องมือโลคัลอีกตัวของผู้ใช้
  • เครื่องมือนั้นใช้ GitPython เพื่อทำ hard reset ทุก 10 นาที และกำลังเฝ้าดูไดเรกทอรีเดียวกับ Claude Code
  • อีชูนี้ถูกปิดด้วยสถานะ “not planned” และชื่อเรื่องถูกแก้จาก “Claude Code ทำการรีเซ็ต” เป็น “เครื่องมืออัตโนมัติของฉันทำการรีเซ็ต”

วิธีแก้ชั่วคราว

  • เมื่อใช้ git worktree จะไม่ได้รับผลกระทบจากการรีเซ็ต
  • สามารถป้องกันการเปลี่ยนแปลงสูญหายได้ด้วยการ commit บ่อย ๆ

อีชูที่เกี่ยวข้อง

  • #8072 — ปัญหาที่การแก้โค้ดถูกย้อนกลับซ้ำ ๆ
  • #7232 — เกิดการสูญหายของข้อมูลจากการรัน git reset --hard โดยไม่มีการอนุมัติ
  • #32793 — ปัญหาที่คำสั่ง claude install เปลี่ยน git remote URL ผิด (คล้ายกันแต่เป็นอีกกรณีหนึ่ง)

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-31
ความคิดเห็นจาก Hacker News

  • นี่คือ อัปเดต ที่ผู้เขียนโพสต์เอง
    ตามลิงก์ issue ต้นตอของปัญหาไม่ใช่ Claude Code แต่เป็นบั๊กในเครื่องมือที่ผู้เขียนทำไว้สำหรับทดสอบบนเครื่องโลคัล
    เครื่องมือนั้นพยายามซิงก์ working directory บนเครื่องกับรีโมต และทำ hard reset ทุก ๆ รอบ จนลบการเปลี่ยนแปลงที่ยังไม่ได้ commit ทั้งหมด

    • ทั้งที่ผู้เขียนบอกว่าสืบสวนไปตั้งเยอะ แต่กลับไม่คิดจะปิด Claude แค่ 10 นาที ก็ตลกดี
      ถ้าเปลี่ยนชื่อเรื่องเป็นประมาณว่า “นักพัฒนาสร้างสคริปต์ที่รีเซ็ต git repo ทุก 10 นาทีแล้วดันลืม ก่อนจะโทษ Claude Code” ฉันจะยกเลิก flag ให้

  • ปัญหาที่แท้จริงคือ ขีดคู่ ในชื่อเรื่องถูก HN แปลงเป็น en dash อัตโนมัติ

    • ใน LaTeX ขีดคู่ใช้แทน en dash และขีดสามใช้แทน em dash
    • เดิมทีฉันก็คิดว่าควรคงขีดคู่ไว้ตามเดิม แต่ถ้ามองตามธรรมเนียมของ LaTeX กับ Typst แล้ว en dash ก็ดูเหมาะกว่า
    • ทิปจากผู้เชี่ยวชาญ: การคัดลอกชื่อเรื่องจาก HN ไปวางใน command line ตรง ๆ เป็นเรื่องอันตราย
    • เดิมทีมันควรเขียนด้วยขีดสองตัวแบบ “--hard”
    • มีกฎอยู่ว่าสองขีดคือ en dash สามขีดคือ em dash

  • ฉันก็ลองสืบเรื่องนี้เองเหมือนกัน และ ในตัว Claude Code ไม่มีโค้ดที่รัน git reset --hard origin/main
    เป็นไปได้มากกว่าว่านักพัฒนาจะรันคำสั่งอย่าง /loop 10m หรือสร้าง cron job ที่คอยรีเซ็ต git ทุก 10 นาที

    • อาจจะเข้าใจผิดว่าเป็นฟีเจอร์ไม่มีพิษภัยแนว ๆ “ซิงก์กับเซิร์ฟเวอร์เป็นระยะ” ก็ได้

  • ที่บอกว่ามอนิเตอร์โปรเซสทุก 0.1 วินาทีแล้วไม่เห็นโปรเซส git นั้นฟังดูไม่น่าเชื่อ
    คำสั่ง git เร็วเกินกว่าจะจับได้ด้วยช่วงเวลาแค่นั้น
    ทางที่ดีกว่าคือห่อ git ใน $PATH แล้ว บันทึก log ทุกครั้งที่มีการรัน

    • มันดูเหมือน Claude Code กำลังไล่งับหางตัวเอง พอดีบักไม่สำเร็จก็เลยพยายามสร้างบักรีพอร์ตเอง
      ถึงขั้นอาจส่งแบบ “agentic” โดยไม่มีอินพุตจากผู้ใช้เลยก็ได้ (เดาล้วน ๆ)
      ลิงก์ issue
    • กรณีแบบนี้ eBPF มีประโยชน์มาก เช่นใช้สคริปต์ execsnoop ของ bpftrace เพื่อติดตามทุกโปรเซสที่ถูกรันในระบบได้

  • โพสต์นี้อาจทำให้คน เข้าใจผิด ว่าปัญหาของบุคคลหนึ่งเป็นปัญหาของทั้งระบบ
    ดูเหมือนน่าจะมี ความเสียหายของคอนเท็กซ์ อยู่บ้าง

    • ฉันเองก็เคยเจออะไรคล้าย ๆ กันหลายครั้ง ครั้งหนึ่งถึงกับมี force push ไปบน GitHub เลย
      Claude เคยพังงานด้วยลำดับ stash → แทนที่ด้วย sed → ชน conflict → reset --hard
      เลยเขียนคำเตือนไว้บนสุดของ CLAUDE.md ว่า
      “ห้ามแทนที่จำนวนมากด้วย sed, ห้าม git push --force, git reset --hard และ คำสั่ง git แบบทำลายล้างทุกชนิด”
      หลังจากนั้นก็ดีขึ้นมาก
    • คุณอาจพูดถูกก็ได้ แต่ถ้าคอนเท็กซ์เสียหายแค่ 0.1% งานหนึ่งจาก 1000 งานก็อาจทำข้อมูลหายได้
    • ที่จริงปัญหาแบบนี้ป้องกันได้หมดด้วย มาตรการป้องกันทางเทคนิค
      ถ้าใส่ hook เพื่อบล็อกคำสั่ง git บางตัว ก็จะปลอดภัยได้โดยไม่ต้องขึ้นอยู่กับความไม่แน่นอนของการคาดเดาของโมเดล
      เรื่องแบบนี้ทำให้รู้สึกว่าหลายคนลืมหลักพื้นฐานของวิศวกรรมสมัยก่อน — กระบวนการที่กำหนดแน่นอนและทำซ้ำได้ — ไปแล้ว
    • สุดท้ายแล้ว LLM ก็ทำเรื่อง โง่ ๆ เป็นบางครั้ง แค่นั้นเอง

  • ฉันก็เคยเจอปัญหาคล้ายกัน
    ปกติฉันรัน claude-code ใน sandbox (bwrap, srt) แต่ถ้ารันข้างนอก มันจะเรียก gh ทุกครั้งที่ลบ /command หรือปิดเมนู
    เพราะฉันใช้ KeepassXC เป็นตัวจัดการความลับ จึงมีป๊อปอัปขออนุมัติเด้งขึ้นมาทุกครั้ง เลยสังเกตเห็นได้ทันที
    พอถาม Claude ก็ได้คำตอบว่าสาเหตุมาจาก ฟีเจอร์ git context
    KeepassXC ไม่รองรับการอนุญาตแบบใช้ได้ทั้ง session สุดท้ายเลยต้องยืนยันตัวตนทุกครั้ง

  • ถ้ามีการตั้งค่าสิทธิ์ ก็น่าจะกันเรื่องแบบนี้ได้ไม่ใช่หรือ
    แต่ผู้ใช้รันด้วยออปชัน --dangerously-skip-permissions เอง ก็ต้องยอมรับพฤติกรรมที่คาดเดาไม่ได้

    • ถึงอย่างนั้น ถ้าใช้ pretooluse hook ก็ยังป้องกันได้แม้เปิดออปชันนี้
    • ดูจากเอกสาร permissions ของ Anthropic แล้ว ยังไม่ชัดเจนว่าการบังคับใช้สิทธิ์ทำงานอย่างไรจริง ๆ
      จะตีความว่ามันถูกเลี่ยงได้ด้วย prompt injection ก็ยังได้
    • การรันบน repo จริงแบบไม่มีสิทธิ์ป้องกัน ถือเป็นการเชื้อเชิญให้เกิด อุบัติเหตุลบข้อมูล
      กฎที่กัน hard reset ไม่ได้ก็เป็นแค่ของโชว์
    • กฎและสิทธิ์ในตอนนี้ไม่ใช่ program flag แต่เป็นแค่ ข้อความ ที่ agent “เชื่อว่าต้องทำตาม” เท่านั้น

  • ผู้เขียนออกมาบอกเองว่าสาเหตุไม่ใช่ Claude Code แต่เป็นบั๊กในเครื่องมือทดสอบบนเครื่องที่ตัวเองสร้างขึ้น

    • สรุปคือเป็น การแจ้งผิด
      ลิงก์ issue
    • คำว่า “เครื่องมือที่ฉันสร้าง” ฟังดูคลุมเครือนิดหน่อย มีโอกาสสูงว่าจะเป็น เครื่องมือ vibe-coded ที่รีบทำขึ้นมา
    • จริง ๆ แล้ว ticket นี้เองก็อาจถูกสร้างจาก ผลการวิเคราะห์ของ Claude Code (หรือก็คืออาการหลอน) ก็ได้

  • ถ้าใช้ เครื่องมือพัฒนาแบบ binary blob บน SaaS ก็ไม่น่าแปลกใจที่จะเจอปัญหาแกะรอยยากแบบนี้

  • สุดท้ายผู้ใช้ก็หาสาเหตุได้เอง และ ต้นเหตุก็คือเครื่องมือของตัวเอง
    เรื่องแบบนี้เคยเกิดมาก่อนและยังเกิดอยู่เสมอ
    ต่อให้ไม่มี LLM ช่วย ฉันก็เคยทำพังด้วยมือตัวเองได้ดีพอ ๆ กันหลายครั้ง
    เพราะงั้นฉันเลยพัฒนางานโดยเปิด Time Machine ของ Mac ไว้ตลอด
    ตอนที่ Claude ลบไฟล์ ถ้ามีข้อความถามว่า “จะกู้คืนไหม?” ก็แทบรู้สึกเหมือน Claude เองยังโล่งใจ
    แบ็กอัปคือ เส้นชีวิต จริง ๆ