Claude Code ทำงานในเทอร์มินัล แต่ยังต้องใช้ runtime ที่ถูกต้อง สิทธิ์ของไดเรกทอรี การจัดเก็บ credentials ที่ปลอดภัย และการตั้งค่า proxy ขององค์กร คู่มือนี้อธิบายสิ่งที่ต้องเตรียมในเครื่องและวิธีแชร์ configuration ภายในทีม
Claude Code เป็นเครื่องมือที่ทำงานในเทอร์มินัล หลังติดตั้งแล้วก็เริ่มใช้งานได้ด้วยคำสั่งเดียว จึงทำให้หลายคนสนใจเรื่องเครือข่ายเป็นหลัก แต่ในทางปฏิบัติ จุดที่ทำให้ติดขัดมักเป็นเรื่องอื่น เช่น runtime version ถูกต้องหรือไม่, project directory มีสิทธิ์เขียนหรือไม่, เก็บ keys ไว้ที่ไหน, corporate proxy ทำงานอย่างไร และเพื่อนร่วมทีมจะแชร์ configuration เดียวกันอย่างไร
จัด runtime environment และ dependencies ให้ตรงกันก่อน
เริ่มจากตรวจ official documentation ว่าปัจจุบันต้องใช้ runtime version ใด แล้วติดตั้งตามที่ระบุ อย่ารีบลอง version ที่เพิ่งออกมาไม่กี่วัน package manager ก็ควรใช้ตามมาตรฐานของทีม เพราะการผสม npm, pnpm และ yarn อาจทำให้ lock files ขัดแย้งกันได้ git และ command-line tools พื้นฐานก็จำเป็น เพราะเครื่องมือประเภทนี้ต้องอ่าน repository, execute commands และ run tests หากขาดส่วนใดก็อาจเกิด error ทันที
หลังติดตั้ง ให้ทดสอบสามอย่างใน directory ว่างก่อน: อ่าน file ได้, แก้ไข file ได้ และ run tests ได้ ปัญหา environment จะเห็นได้เร็วใน directory เล็ก แต่ถ้าค้นหาปัญหาใน business code ต้นทุนจะสูงกว่ามาก
Project directory, permissions และขอบเขต
อย่าเริ่มใช้งานจาก home directory ของ user หรือ root ของทั้ง drive ให้กำหนด repository root ที่ชัดเจนและจำกัด read/write scope ให้อยู่ใน project หากจำเป็นต้องใช้ขอบเขตกว้างขึ้นจริง ให้ใช้ one-time authorization แทนการเปิดสิทธิ์ถาวร
ก่อน commit ให้ตรวจ .gitignore โดย cache, logs และ temporary scripts ที่สร้างใน local ควรอยู่นอก version control ในทีม ปัญหาร้ายแรงที่เกิดง่ายไม่ใช่แค่เขียน code ผิด แต่คือการเผลอ commit sensitive files ที่เกิดขึ้นระหว่าง local debugging
ควรเก็บ keys และ credentials อย่างไร
API keys, access tokens และ secrets อื่น ๆ ควรส่งผ่าน environment variables หรือ credential manager ของ operating system อย่าเขียนลงใน source code, configuration files หรือ script comments ตัว .env เองก็ควรอยู่ใน .gitignore และใน repository ควรเหลือเพียง sample file ที่อธิบายความหมายของแต่ละ field
แยก personal credentials ออกจาก team credentials หากหลายคนใช้ key เดียวกัน เมื่อเกิดปัญหาจะตามได้ยากว่าใครเป็นผู้ใช้งาน กำหนด rotation schedule ล่วงหน้า: เปลี่ยนเป็นระยะ, เปลี่ยนในวันที่สมาชิกออกจากทีม และเปลี่ยนทันทีเมื่อสงสัยว่ารั่วไหล หากพบ exposure ให้ revoke ก่อนแล้วค่อยตรวจสอบ อย่าลบ logs ก่อน
ใช้งานร่วมกับ corporate proxy และ network environment
ในเครือข่ายองค์กร ปัญหาของเครื่องมือประเภทนี้มักไม่ใช่แค่เชื่อมต่อได้หรือไม่ แต่เป็นเรื่อง proxy และ certificates หาก enterprise gateway ทำ TLS interception เครื่องมืออาจ fail เพราะไม่เชื่อถือ certificate chain ในกรณีนี้ให้ขอ internal root certificate จาก IT แล้วติดตั้งใน trust store ที่ถูกต้อง แทนการปิด verification ชั่วคราว
Login flow จะเปิด browser ดังนั้น command line และ browser ควรใช้ egress path เดียวกัน และ path นี้ควร fixed, stable และ controllable หากขาดข้อใดข้อหนึ่ง อาจเกิดการ login ซ้ำหรือ CAPTCHA verification ได้ง่ายขึ้น การสลับ node บ่อย ๆ มีแนวโน้มกระตุ้นการตรวจสอบมากกว่าการใช้ node เดิม เพราะแบบหลังดูคล้ายผู้ใช้ประจำมากกว่า
หากต้องการตรวจว่า egress ใช้งานจริงหรือไม่ ให้ใช้ command line พร้อม proxy parameter เรียก IP lookup service หนึ่งครั้ง
curl -x http://127.0.0.1:7897 https://ipinfo.io
Address ที่แสดงควรเป็นค่าที่คาดไว้ และควรตั้ง time zone กับ language ของ browser ให้สอดคล้องกับ egress region ด้วย หลีกเลี่ยงกรณีที่ด้านหนึ่งชี้ไป North America แต่อีกด้านเป็น UTC+8
แชร์ configuration ในทีมอย่างไร
สิ่งที่แชร์ได้คือ structure ไม่ใช่ secrets ให้นำ working-directory conventions, proxy routing rules, allowed command scope และ code-style constraints ใส่ไว้ใน configuration file ที่ version control ได้ภายใน repository ส่วน keys ให้แต่ละเครื่อง inject ผ่าน environment variables ของตัวเอง
สมาชิกใหม่จึงทำตาม documentation แล้วเริ่มใช้งานได้โดยไม่ต้องถามเพื่อนร่วมงานทีละคน หากทีมมีหลาย identities หรือหลาย environments พร้อมกัน PurpleMark ก็สามารถทำให้ browser state ของแต่ละ environment คงที่ เพื่อให้ภายหลังตรวจสอบได้ว่า login ใดเกิดขึ้นใน environment ไหน
สรุป
เมื่อเครื่องมือประเภทนี้มีปัญหา สาเหตุมักไม่ใช่ bug ของตัวเครื่องมือเอง แต่เป็น prerequisites ที่ยังไม่ตรงกัน Runtime และ dependencies, directory permissions, ตำแหน่งของ keys, proxy egress และ shared configuration คือห้าจุดที่ควรจัดให้เรียบร้อยใน project เล็กก่อน ซึ่งช่วยลดเวลาการแก้ปัญหาซ้ำในภายหลังได้มาก
