คู่มือการใช้งาน OpenAI Codex อย่างมืออาชีพ: ตั้งค่า สั่งงาน และเชื่อมต่อ workflow

Codex คือ coding agent จาก OpenAI ที่ทำงานได้ทั้งบนเทอร์มินอล (CLI), ใน IDE, บนคลาวด์ และผ่าน GitHub โดยใช้บัญชีและบริบทร่วมกัน คู่มือนี้จะพาคุณตั้งค่าและใช้งานอย่างปลอดภัยตั้งแต่ต้นจนถึงระดับมืออาชีพ

เริ่มใช้ Codex ใน 5 ขั้นตอน (Quick Start)

  1. ติดตั้ง Codex CLI ด้วย npm install -g @openai/codex หรือ brew install --cask codex (ระวังอย่าใช้แพ็กเกจชื่อ codex แบบ unscoped)
  2. ล็อกอิน โดยรันคำสั่ง codex ในโฟลเดอร์โปรเจกต์ แล้วเลือก "Sign in with ChatGPT" (ใช้โควตาตามแผน) หรือใส่ OpenAI API key (คิดเงินตาม token)
  3. ตั้งค่า AGENTS.md ด้วยคำสั่ง /init เพื่อให้ Codex สแกน repo แล้วสร้างไฟล์คำสั่งประจำโปรเจกต์ที่ root
  4. เลือก sandbox และ approval ให้เหมาะกับงาน โดยงานประจำวันแนะนำคู่ sandbox_mode = workspace-write กับ approval_policy = on-request (ปรับได้ผ่าน /permissions)
  5. สั่งงาน โดยพิมพ์คำสั่งเป็นภาษาธรรมชาติในเซสชัน เช่น ให้แก้บั๊ก เขียนฟีเจอร์ หรือรีวิวโค้ด แล้วอนุมัติการเปลี่ยนแปลงเมื่อ Codex ร้องขอ

สารบัญ (Table of Contents)

  • บทที่ 1: OpenAI Codex คืออะไร และช่องทางการใช้งาน (Surfaces)
  • บทที่ 2: การติดตั้งและตั้งค่าเริ่มต้น (Install & Setup)
  • บทที่ 3: โมเดลของ Codex และการเลือกใช้งาน
  • บทที่ 4: โหมดการอนุมัติและระบบ Sandbox เพื่อความปลอดภัย
  • บทที่ 5: การกำหนดกฎและบริบทด้วย AGENTS.md
  • บทที่ 6: คำสั่งและฟีเจอร์หลักในการใช้งานประจำวัน
  • บทที่ 7: การขยายความสามารถด้วย MCP และเครื่องมือภายนอก
  • บทที่ 8: Codex Cloud งานแบบขนาน และการรวมกับ GitHub
  • บทที่ 9: การทำงานอัตโนมัติและ CI/CD ด้วย codex exec
  • บทที่ 10: ศิลปะการสั่งงาน Codex อย่างมืออาชีพ (Prompting & Agentic Workflow)
  • บทที่ 11: เวิร์กโฟลว์ตัวอย่างในงานจริง (Real-World Workflows)
  • บทที่ 12: คลัง Prompt สำเร็จรูป (Prompt Cookbook)
  • บทที่ 13: เปรียบเทียบ Codex กับ Claude Code, Cursor และ Google Antigravity
  • บทที่ 14: เคล็ดลับ ข้อควรระวัง และแนวทางสำหรับทีม/องค์กร
  • คำถามที่พบบ่อยเกี่ยวกับการใช้ Codex (FAQ)

บทที่ 1: OpenAI Codex คืออะไร และช่องทางการใช้งาน (Surfaces)

OpenAI Codex คือ coding agent หรือเครื่องมือ agentic software engineering ที่ OpenAI เปิดตัวใหม่ในปี 2025 หัวใจของมันคือการนำโมเดลเรือธงของ OpenAI (ตระกูล GPT-5 / gpt-5-codex) มาห่อด้วยความสามารถระดับ agent ได้แก่ การเข้าถึงและแก้ไขไฟล์ การรันคำสั่งเชลล์ภายใน sandbox ระบบ approval ก่อนลงมือ และการ review โค้ด พูดง่าย ๆ คือมันไม่ได้แค่ "เติมโค้ด" ให้ แต่ลงมือทำงานหลายขั้นตอนแทนเราได้จริง ตั้งแต่แก้บั๊ก เขียนฟีเจอร์ ไปจนถึงรีวิว pull request

💡 บริบท ณ กลางปี 2026: โมเดลเบื้องหลังเป็นตระกูล GPT-5 / gpt-5-codex แต่ชื่อรุ่นเรือธงเปลี่ยนเร็วมาก บทนี้จึงพูดถึงตัว "เครื่องมือ" เป็นหลัก ส่วนรายละเอียดการเลือกโมเดลและ reasoning effort ดูในบทว่าด้วยโมเดลและราคา

แยกให้ชัด: Codex ยุคใหม่ ไม่ใช่โมเดล Codex ปี 2021

จุดที่สับสนบ่อยที่สุดคือชื่อ "Codex" เพราะ OpenAI เคยมีโมเดลชื่อ Codex มาตั้งแต่ปี 2021 ซึ่งเป็นคนละตัวกับ Codex ที่เรากำลังพูดถึง และตัวเก่าถูกปลดระวางไปแล้ว

หัวข้อโมเดล Codex (2021)OpenAI Codex (2025–ปัจจุบัน)
เป็นอะไรโมเดล AI สำหรับสร้างโค้ด (ตัวโมเดลเดี่ยว ๆ)coding agent ที่ห่อโมเดลเรือธง + เครื่องมือ
สถานะปลดระวางแล้วใช้งานอยู่ (กลางปี 2026)
ทำอะไรได้รับ prompt แล้วสร้าง/เติมโค้ดอ่าน-แก้ไฟล์, รันเชลล์ใน sandbox, ขอ approval, review โค้ด, เดินงานหลายขั้นตอนเอง
ใช้ผ่านAPI เรียกโมเดลตรงหลาย surface (CLI, cloud, IDE, GitHub)

⚠️ เวลาอ่านบทความ/เอกสารเก่า ให้ระวังว่ากำลังพูดถึง Codex ตัวไหน หลักการง่าย ๆ คือ ถ้าพูดถึง codex เป็นคำสั่ง, AGENTS.md, sandbox หรือ @codex บน PR แสดงว่าเป็น Codex ยุคใหม่ (agent) ทั้งหมด

ภาพรวม 4 ช่องทาง (Surfaces)

Codex ทำงานได้ 4 surface อย่างเป็นทางการ ทุก surface แชร์บัญชีและ context ร่วมกัน เช่น อ่านไฟล์ AGENTS.md เดียวกัน และใช้ค่าตั้งจาก ~/.codex/config.toml ร่วมกัน ทำให้ตั้งค่าครั้งเดียวใช้ได้ข้ามช่องทาง

graph TD
    Shared["บัญชีเดียว + context ร่วมกัน<br/>AGENTS.md · ~/.codex/config.toml"] --> Core
    Core["Codex agent<br/>ห่อโมเดล GPT-5 / gpt-5-codex<br/>file access · sandbox · approval · MCP"]
    Core --> CLI["1 · Codex CLI<br/>เอเจนต์บนเทอร์มินัล"]
    Core --> Cloud["2 · Codex cloud<br/>ใน ChatGPT · sandbox container"]
    Core --> IDE["3 · IDE extension<br/>VS Code / Cursor / Windsurf"]
    Core --> GH["4 · GitHub integration<br/>code review · @codex"]

💡 เพราะ context ใช้ร่วมกัน เราจึงเริ่มงานบน CLI ได้ แล้ว delegate งานหนักขึ้น cloud ต่อ หรือให้ Codex ที่รีวิว PR บน GitHub เข้าใจกฎโปรเจกต์เดียวกัน โดยไม่ต้องตั้งค่าซ้ำ

Surface 1: Codex CLI

เอเจนต์ที่รันบนเทอร์มินัลของเครื่อง local คำสั่งหลักคือ codex (เปิด interactive TUI ในไดเรกทอรีโปรเจกต์) เป็นโอเพนซอร์ส สัญญาอนุญาต Apache-2.0 เขียนด้วย Rust (repo github.com/openai/codex) นอกจากโหมดโต้ตอบแล้ว ยังมี codex exec สำหรับงาน headless/non-interactive เหมาะกับ CI/CD และสคริปต์ที่ทำซ้ำได้

  • เหมาะกับ: นักพัฒนาที่ทำงานในเชลล์เป็นหลัก ต้องการควบคุมเต็มที่บนเครื่องตัวเอง และงาน automation ใน pipeline
  • รายละเอียดการติดตั้ง, flags, slash commands และการตั้งค่า config.toml / AGENTS.md / /init อยู่ในบทว่าด้วยการตั้งค่า Codex CLI

Surface 2: Codex cloud (ใน ChatGPT)

cloud agent ที่รันงานในคอนเทนเนอร์ sandbox แยกต่างหาก เข้าใช้ที่ chatgpt.com/codex และผ่าน ChatGPT desktop app (macOS/Windows) จุดเด่นคือ หนึ่ง environment ต่อหนึ่ง task และรันหลาย task ขนานกันได้ โดยไม่กินทรัพยากรเครื่อง local เราสั่ง delegate งานแบบ background แล้ว agent จะทำงานและเปิด pull request ให้ review ต่อ

  • เข้าจากหลายจุด: web dashboard, GitHub, Linear, Slack และ CLI
  • เหมาะกับ: งานยาว งานที่อยากปล่อยให้ทำเบื้องหลัง หรือทำหลายงานพร้อมกัน
  • ขั้นตอนตั้ง Environments และการเชื่อม repo เจาะลึกในบทว่าด้วย Codex cloud และ GitHub integration

Surface 3: IDE extension

ส่วนขยายสำหรับ VS Code และ editor ตระกูล VS Code เช่น Cursor และ Windsurf ทำงานได้ทั้งแบบ local agent ในเอดิเตอร์ และเชื่อม local session ขึ้นไปยัง Codex cloud เพื่อ delegate งานหนักโดยไม่ต้องออกจาก editor

  • เหมาะกับ: คนที่ใช้ชีวิตอยู่ใน editor เป็นหลัก และอยากได้สะพานเชื่อมระหว่างงานในเครื่องกับ cloud agent

Surface 4: GitHub integration

การรวม Codex เข้ากับ workflow บน GitHub โดยเน้นที่ code review ผ่าน @codex ในคอมเมนต์ของ pull request เมื่อพิมพ์ @codex review Codex จะ react ด้วย 👀 ก่อน แล้วโพสต์รีวิวเป็น GitHub code review ปกติ ตั้งค่าเปิด/ปิดต่อ repo (หรือเปิด automatic reviews ให้รีวิวทุก PR อัตโนมัติ) ได้ที่ Codex settings

  • เหมาะกับ: ทีมที่รีวิวโค้ดบน GitHub และอยากได้ตัวช่วยรีวิวที่เข้าใจ context ของ PR
  • คำสั่งอื่น ๆ เช่น @codex fix it, การตั้ง ## Code Review Rules ใน AGENTS.md และ GitHub Action อยู่ในบทว่าด้วย Codex cloud และ GitHub integration

เลือก Surface ให้เหมาะกับงาน

Surfaceรันที่ไหนเหมาะกับงานจุดเด่น
Codex CLIเทอร์มินัลบนเครื่อง localงาน interactive รายวัน, สคริปต์/CI ผ่าน codex execโอเพนซอร์ส ควบคุมเต็มที่ อยู่ในเชลล์
Codex cloudคอนเทนเนอร์ sandbox บนคลาวด์delegate งานยาว, ทำหลายงานขนาน, เปิด PR ให้ไม่กินเครื่อง local รันหลาย task พร้อมกัน
IDE extensionใน editor (local) + ต่อขึ้น cloudเขียนโค้ดในเอดิเตอร์ แล้วส่งงานหนักขึ้น cloudไม่ต้องออกจาก editor
GitHub integrationบน GitHub (pull request)รีวิว PR แบบตามสั่งหรืออัตโนมัติเข้ากับ workflow รีวิวของทีมบน GitHub

💡 ทั้ง 4 ไม่ใช่ทางเลือกที่ต้องเลือกอย่างใดอย่างหนึ่ง ในทีมจริงมักใช้ผสมกัน เช่น เขียนงานหลักบน CLI/IDE, ปล่อยงานยาวขึ้น cloud, และให้ GitHub integration คอยรีวิว PR

เหมาะกับใคร

Codex รวมอยู่ในทุกแผนของ ChatGPT (Free, Go, Plus, Pro, Business, Edu, Enterprise) โดยโควตาและ rate limit ต่างกันตามแผน และล็อกอินได้ 2 แบบคือ Sign in with ChatGPT (ใช้โควตาตามแผน) หรือ API key (จ่ายตาม token) ทำให้เข้าถึงได้ตั้งแต่นักพัฒนาเดี่ยวไปจนถึงองค์กร

  • นักพัฒนาเดี่ยว / สายเทอร์มินัล → เริ่มที่ Codex CLI ได้เลย รวมอยู่แม้ในแผน Free
  • ทีมที่อยากปล่อยงานให้ agent ทำเบื้องหลัง / ทำหลายงานขนาน → Codex cloud
  • คนที่ทำงานในเอดิเตอร์เป็นหลัก (VS Code / Cursor / Windsurf) → IDE extension
  • ทีมที่รีวิวโค้ดบน GitHub → GitHub integration

⚠️ Codex cloud และ GitHub integration ต้องใช้แผนจ่ายเงิน (Plus / Pro / Business / Edu / Enterprise) และต้องมีสิทธิ์ admin ของ repo ในการเชื่อมต่อ ส่วนตัวเลขราคา rate limit และเงื่อนไขต่อแผนเปลี่ยนบ่อย แนะนำยืนยันกับ rate card ทางการก่อนตัดสินใจ (ดูรายละเอียดในบทว่าด้วยโมเดลและราคา)

บทที่ 2: การติดตั้งและตั้งค่าเริ่มต้น (Install & Setup)

บทนี้จะพาตั้งต้นให้ครบตั้งแต่ติดตั้ง Codex CLI, ล็อกอินครั้งแรก, ทำความเข้าใจโฟลเดอร์ ~/.codex/ และไฟล์ config.toml, ตั้ง profiles ไปจนถึงการอัปเดตเวอร์ชัน เป้าหมายคือให้ทำตามได้จริงจนถึงจุดที่พิมพ์ codex แล้วเริ่มทำงานได้ทันที

ภาพรวมขั้นตอนตั้งค่าครั้งแรก:

flowchart LR
    A[ติดตั้ง CLI<br/>npm / brew / script] --> B[รัน codex<br/>ครั้งแรก]
    B --> C{เลือกวิธีล็อกอิน}
    C -->|มี ChatGPT plan| D[Sign in with ChatGPT]
    C -->|จ่ายตาม token| E[API key]
    D --> F[ปรับ ~/.codex/config.toml]
    E --> F
    F --> G[พร้อมใช้งาน]

2.1 ติดตั้ง Codex CLI

Codex CLI เป็นโอเพนซอร์ส (Apache-2.0) เขียนด้วย Rust คำสั่งหลักคือ codex ติดตั้งได้ 3 ทาง เลือกทางที่เข้ากับ workflow ของเครื่องได้เลย

วิธีคำสั่งเหมาะกับ
npmnpm install -g @openai/codexเครื่องที่มี Node.js อยู่แล้ว, ทีมที่ pin เวอร์ชันผ่าน package
Homebrewbrew install --cask codexmacOS/Linux ที่ใช้ brew บริหาร tool
Install scriptcurl -fsSL https://chatgpt.com/codex/install.sh | shติดตั้งเร็วโดยไม่ต้องมี Node.js

บน Windows ใช้ PowerShell:

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

ตรวจว่าติดตั้งสำเร็จและดู subcommand/flag ที่รองรับด้วย:

codex --help

⚠️ ระวังชื่อแพ็กเกจ npm ผิดตัว: แพ็กเกจชื่อ codex แบบ unscoped เป็นคนละโปรเจกต์กับ Codex ของ OpenAI ต้องติดตั้ง @openai/codex (มี scope @openai/) เท่านั้น

2.2 รันครั้งแรกและการล็อกอิน

เข้าไปในไดเรกทอรีโปรเจกต์แล้วพิมพ์ codex เพื่อเปิดเซสชันแบบ interactive ครั้งแรก Codex จะให้เลือกวิธีล็อกอิน 2 แบบ

cd path/to/your-project
codex
หัวข้อSign in with ChatGPTAPI key
การคิดค่าใช้จ่ายใช้โควตาตามแผน ChatGPTจ่ายตาม token (usage-based)
ข้อจำกัดหน้าต่างเวลามี rate limit ตามแผนไม่มี window limit
ครอบคลุมแผนรวมมาในทุกแผน (ตั้งแต่ Free ขึ้นไป)ผูกกับ OpenAI API account
เหมาะกับผู้ที่มี ChatGPT subscription อยู่แล้วงาน headless/CI และทีมที่คุม cost ระดับ token

แผน ChatGPT ที่รองรับ Codex ได้แก่ Free, Go, Plus, Pro, Business, Edu, Enterprise โดยโควตา/rate limit ต่างกันตามแผน

จัดการสถานะล็อกอินด้วย subcommand:

codex login    # เริ่มขั้นตอนล็อกอิน
codex logout   # ออกจากระบบ

💡 เคล็ดลับ: ถ้าจะใช้ Codex ใน CI/CD หรือรันแบบ headless ผ่าน codex exec การใช้ API key จะคุมได้ตรงกว่าเพราะไม่ติด window limit ส่วนงานประจำวันบนเครื่องตัวเองที่มีแผน ChatGPT อยู่แล้ว ให้ใช้ Sign in with ChatGPT จะคุ้มกว่า

⚠️ การใช้ Codex cloud และการรวมกับ GitHub ต้องมีแผนระดับ Plus/Pro/Business/Edu/Enterprise และต้องมีสิทธิ์ admin ของ repo ด้วย (ส่วน Codex cloud/GitHub จะลงรายละเอียดในบทว่าด้วย Codex cloud และ GitHub integration)

2.3 โครงสร้างโฟลเดอร์ ~/.codex/

Codex เก็บ state ทั้งหมดไว้ที่โฟลเดอร์ ~/.codex/ ซึ่งควบคุมตำแหน่งด้วย env var CODEX_HOME (ถ้าไม่ตั้งค่า จะ default เป็น ~/.codex) โฟลเดอร์นี้เก็บทั้ง authentication, config, history, logs และ caches

~/.codex/                       # = $CODEX_HOME (ค่าเริ่มต้น)
├── config.toml                 # config หลักระดับ user
├── deep-review.config.toml     # ตัวอย่างไฟล์ profile รูปแบบ <name>.config.toml
└── AGENTS.md                   # คำสั่ง agent ระดับ global (ดูบทว่าด้วย AGENTS.md)
#   + โฟลเดอร์นี้ยังเก็บ authentication, history, logs และ caches

💡 อยากแยก config ของ Codex ออกเป็นหลายชุด (เช่น แยกงานส่วนตัว/งานบริษัท) ทำได้โดยตั้ง CODEX_HOME ไปยังโฟลเดอร์อื่นก่อนรัน เช่น CODEX_HOME=~/work/.codex codex

2.4 config.toml เบื้องต้น

ไฟล์ ~/.codex/config.toml เป็น TOML ระดับ user คุมพฤติกรรมหลักของ Codex ตัวอย่างขั้นต่ำที่ใช้ทำงานได้จริง:

# ~/.codex/config.toml — ค่าตั้งระดับ user
model = "gpt-5.6"                    # โมเดลที่ใช้
model_reasoning_effort = "medium"   # ระดับการคิด: minimal|low|medium|high|xhigh (default medium)
approval_policy = "on-request"      # เมื่อไหร่ถึงขออนุมัติ: untrusted|on-request|never
sandbox_mode = "workspace-write"    # สิทธิ์ไฟล์: read-only|workspace-write|danger-full-access

ความหมายของ key หลัก:

Keyค่าที่รับได้หมายเหตุ
modelชื่อโมเดล เช่น "gpt-5.6"เลือก provider ด้วย model_provider (default "openai")
model_reasoning_effortminimal / low / medium / high / xhighค่า default คือ medium
approval_policyuntrusted / on-request / neverควบคุมว่าเมื่อไหร่ Codex หยุดขออนุมัติ
sandbox_moderead-only / workspace-write / danger-full-accessควบคุมสิทธิ์การเข้าถึงไฟล์

คู่ sandbox_mode = "workspace-write" + approval_policy = "on-request" คือชุดที่เหมาะกับงานประจำวัน (ตรงกับ preset "Auto") รายละเอียดเชิงลึกของ approval และ sandbox รวมถึงการเลือกโมเดล/reasoning effort จะอยู่ในบทว่าด้วย approval & sandbox และบทว่าด้วยโมเดล ตามลำดับ

⚠️ ชื่อรุ่นโมเดลเปลี่ยนเร็ว ตัวอย่างในเอกสารช่วงกลางปี 2026 อ้างถึงหลายชื่อ (เช่น gpt-5.5, gpt-5.6) ก่อนใส่ตัวเลขรุ่นลง config ควรยืนยันชื่อที่ใช้ได้จริงด้วย /model หรือ /status ในเซสชัน อย่าเดา

Codex ยังรองรับ config ระดับโปรเจกต์ที่ .codex/config.toml ภายใน repo (โหลดเฉพาะเมื่อ trust โปรเจกต์นั้น) โดย project config ไม่สามารถ override ค่าที่เป็น machine-local เช่น provider settings, authentication, notifications, การเลือก profile และ telemetry

ลำดับความสำคัญของการ merge config (สูง → ต่ำ):

  1. CLI flags และ -c/--config (ชนะทุกอย่าง)
  2. project config .codex/config.toml และ profile ที่เลือกด้วย --profile
  3. user config ~/.codex/config.toml
  4. system/managed config เช่น /etc/codex/config.toml
  5. ค่า default ในตัว

⚠️ ลำดับสัมพัทธ์ระหว่าง profile กับ project config ยังไม่นิ่งระหว่างแหล่งอ้างอิง (บางแหล่งวาง profile สูงกว่า project config) และอาจต่างตามเวอร์ชัน CLI ถ้าต้องพึ่งลำดับนี้จริง ให้ตรวจผลลัพธ์ที่ได้จริงด้วย /status

override ค่าเดี่ยว ๆ แบบรายครั้งได้จาก CLI ด้วย -c/--config โดยค่าเป็น TOML จึงต้องใส่ quote ซ้อน:

codex --config model='"gpt-5.5"'

2.5 Profiles

Profile คือชุด config สำเร็จรูปที่สลับใช้ตามงานได้ ตั้งแต่ปี 2026 profile ถูกเก็บเป็นไฟล์แยกต่อโปรไฟล์ที่ $CODEX_HOME/<name>.config.toml (ชื่อ profile ใช้ตัวอักษร ตัวเลข hyphen และ underscore ได้)

สร้างไฟล์ profile เช่น ~/.codex/deep-review.config.toml:

# ~/.codex/deep-review.config.toml — profile ชื่อ "deep-review"
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
approval_policy = "on-request"

เรียกใช้ด้วย flag --profile:

codex --profile deep-review

เมื่อส่ง --profile deep-review Codex จะโหลด ~/.codex/config.toml ก่อน แล้วจึง overlay ค่าจาก ~/.codex/deep-review.config.toml ทับ ทำให้ profile เก็บเฉพาะ key ที่ต่างจาก config หลักก็พอ

⚠️ การ migrate จากรูปแบบเดิม: เวอร์ชันก่อนหน้าใช้ inline table [profiles.NAME] ในไฟล์ config.toml ไฟล์เดียว ถ้าอัปเดตแล้ว inline profile ไม่ทำงาน ให้ย้ายแต่ละ [profiles.<name>] ไปเป็นไฟล์ ~/.codex/<name>.config.toml แล้วลบ inline table เดิมออก

2.6 การอัปเดตเวอร์ชัน

อัปเดตด้วยช่องทางเดียวกับที่ติดตั้งมา:

# ถ้าติดตั้งผ่าน npm
npm install -g @openai/codex@latest

# ถ้าติดตั้งผ่าน Homebrew
brew upgrade --cask codex

หลังอัปเดตควรตรวจ subcommand และ flag ที่รองรับในเวอร์ชันใหม่เสมอ เพราะรายการคำสั่งและค่าที่รับได้ (เช่น ชื่อโมเดล หรือค่าของ approval_policy) อาจต่างกันตามเวอร์ชัน:

codex --help

💡 บางเวอร์ชันอาจมี subcommand สำหรับอัปเดตในตัว ก่อนใช้ให้ยืนยันจาก codex --help ว่ามีจริงในเครื่องคุณ อย่าอิงจากความจำ และหากใช้ในทีม/CI แนะนำ pin เวอร์ชันผ่าน package manager เพื่อให้ผลลัพธ์คงที่

บทที่ 3: โมเดลของ Codex และการเลือกใช้งาน

Codex เป็นเพียง "เปลือก" (agent) ที่ห่อหุ้มโมเดลภาษาของ OpenAI ไว้ ดังนั้นการเลือกโมเดลและปรับระดับการคิด (reasoning effort) ให้เหมาะกับงาน จึงเป็นตัวแปรสำคัญที่กำหนดทั้ง คุณภาพผลลัพธ์ ความเร็ว และต้นทุน โดยตรง บทนี้จะพาไปรู้จักตระกูลโมเดลที่ Codex ใช้ แนวคิด reasoning effort และวิธีสลับโมเดลให้คล่องมือ

⚠️ อ่านก่อนเริ่ม: วงการโมเดลของ OpenAI เปลี่ยนเร็วมาก ชื่อรุ่นและ default ที่ระบุในบทนี้อ้างอิงข้อมูล ณ กลางปี 2026 และบางส่วนมาจากแหล่งที่ยังต้องยืนยัน ก่อนพึ่งพาชื่อรุ่นใด ให้ตรวจของจริงด้วย /model หรือ /status ในเซสชัน และดูรายชื่อล่าสุดที่ learn.chatgpt.com/docs/models เสมอ

ตระกูลโมเดล: จากยุค codex-1 ถึงตระกูล GPT-5.x

สิ่งแรกที่ต้องแยกให้ขาด: Codex (coding agent ที่เปิดตัวปี 2025) คนละตัวกับโมเดล "Codex" ปี 2021 ที่ปลดระวางไปแล้ว ที่พูดถึงในบทนี้คือ agent รุ่นใหม่ทั้งหมด

วิวัฒนาการของโมเดลที่อยู่เบื้องหลัง Codex สรุปได้ตามไทม์ไลน์นี้

timeline
    title วิวัฒนาการโมเดลเบื้องหลัง Codex
    พ.ค. 2025 : codex-1 (fine-tune จาก o3) : codex-mini (สำหรับ CLI)
    ก.ย. 2025 : gpt-5-codex (GPT-5 จูนเพื่อ agentic coding)
    ช่วงถัดมา : gpt-5.1-codex / -max / -mini : gpt-5.2-codex : gpt-5.3-codex
    กลางปี 2026 : ตระกูล GPT-5.6 (Sol / Terra / Luna)

จุดสำคัญของแต่ละยุค:

  • codex-1 / codex-mini (พ.ค. 2025) — จุดเริ่มต้นของ Codex ยุคใหม่ codex-1 เป็นเวอร์ชันของ o3 ที่ปรับจูนสำหรับงาน software engineering ใช้ใน Codex cloud agent ส่วน codex-mini เป็นโมเดลเล็กสำหรับ Codex CLI
  • gpt-5-codex (15 ก.ย. 2025) — GPT-5 ที่ปรับจูนเฉพาะงาน agentic coding จุดเด่นคือ ปรับเวลาคิด (thinking time) แบบ dynamic ตามความยากของงาน งานง่ายใช้โทเคนคิดน้อยลง (เคลมว่าน้อยกว่า GPT-5 ราว 93% ในงานง่ายมาก) ขณะที่งานยากสามารถทำงานต่อเนื่องยาวได้ (มีการทดสอบเกิน 7 ชั่วโมง) — แนวคิด "คิดหนักเท่าที่จำเป็น" นี้เองที่โยงตรงกับเรื่อง reasoning effort ในหัวข้อถัดไป
  • ตระกูล GPT-5.6 (กลางปี 2026) — ตามเอกสารทางการปัจจุบัน โมเดลเรือธงแบ่งเป็น 3 ระดับ ดูตารางด้านล่าง

💡 หมายเหตุเรื่อง o3 / o4-mini: ทั้งสองเป็นโมเดล reasoning ทั่วไป (ไม่ใช่ Codex โดยเฉพาะ) codex-1 สร้างต่อยอดจาก o3 ส่วน o4-mini ถูกปลดจาก ChatGPT ไปแล้วช่วงต้นปี 2026 จึงไม่ควรอ้างอิงเป็นตัวเลือกหลักอีกต่อไป

ตระกูลโมเดลปัจจุบัน (ตามเอกสาร ณ กลางปี 2026)

โมเดลตำแหน่งเหมาะกับ
GPT-5.6 Solเรือธง ทรงพลังที่สุดงานซับซ้อน/high-value เช่น refactor ใหญ่ ออกแบบสถาปัตยกรรม debug ยาก
GPT-5.6 Terraสมดุลงาน dev ทั่วไปในแต่ละวัน
GPT-5.6 Lunaเร็ว/ถูกที่สุดงานเบา iteration เร็ว งานปริมาณมาก
GPT-5.5รุ่นก่อนใช้เมื่อต้องการพฤติกรรม/เสถียรภาพแบบเดิม
GPT-5.3 Codex Sparkresearch preview (text-only) เฉพาะ ChatGPT Proการ iterate แบบ real-time

⚠️ ชื่อ Sol/Terra/Luna และสถานะของรุ่นเก่าอย่าง gpt-5-codex หรือ gpt-5.2-codex (ยัง GA อยู่หรือถูกแทนแล้ว) เป็นข้อมูลที่ยังต้องยืนยัน ให้ยึด /model ในเครื่องจริงเป็นหลัก

reasoning effort: ปรับสมดุลความเร็ว–คุณภาพ–ต้นทุน

Reasoning effort คือระดับที่โมเดลใช้ "คิด" ก่อนตอบ ยิ่งคิดมาก คุณภาพในงานยากยิ่งดีขึ้น แต่แลกมาด้วยความช้าและโทเคน (ต้นทุน) ที่เพิ่มขึ้น ตั้งค่าได้ผ่านคีย์ model_reasoning_effort ในไฟล์ config

ค่าที่รองรับ (จากเอกสาร config-reference) คือ minimal | low | medium | high | xhigh โดยค่า default คือ medium และ xhigh จะใช้ได้เฉพาะโมเดลที่รองรับ

ระดับความเร็วความลึก/คุณภาพต้นทุน (token)เหมาะกับ
minimalเร็วที่สุดตื้นต่ำสุดงานโค้ดตรงไปตรงมา ทำตามคำสั่งที่ชัดเจน
lowเร็วน้อยต่ำงานเล็ก งานซ้ำ ๆ
medium (default)สมดุลสมดุลปานกลางงานทั่วไปในแต่ละวัน
highช้าลงลึกสูงงานยากหลายขั้นตอน
xhighช้าที่สุดลึกที่สุดสูงสุดงานซับซ้อนมาก (เฉพาะโมเดลที่รองรับ)

ข้อสังเกตที่มีประโยชน์: GPT-5 family รองรับระดับ minimal ที่ ทำงานได้ดีกับงาน coding และการทำตามคำสั่ง (instruction following) โดยเฉพาะ ดังนั้นสำหรับงานโค้ดที่โจทย์ชัดอยู่แล้ว การลดลงมาที่ minimal/low มักเร็วขึ้นมากโดยคุณภาพไม่ตกอย่างมีนัยสำคัญ

นอกจากนี้ยังมีคีย์ที่เกี่ยวข้องอีกหลายตัว (ระบุในเอกสาร config-reference):

  • plan_mode_reasoning_effort — รับค่า none|minimal|low|medium|high|xhigh สำหรับปรับ effort เฉพาะตอนวางแผน
  • model_reasoning_summary — auto|concise|detailed|none คุมความละเอียดของสรุปการคิด
  • model_verbosity — low|medium|high คุมความยาวคำตอบ (สำหรับ GPT-5 ผ่าน Responses API)

💡 หน้า UI (model selector) อาจแสดงชื่อระดับที่ต่างจากค่าฝั่ง config เช่น Low/Medium/High/Extra High/Max/Ultra โดยความสัมพันธ์ระหว่างสองชุดนี้ยังไม่ชัดเจน หากเขียนสคริปต์หรือ config ให้ยึดค่าฝั่ง API (minimal…xhigh) เป็นมาตรฐาน

การเลือกและสลับโมเดล 3 ช่องทาง

Codex ให้เลือก/สลับโมเดลได้ตามบริบทการใช้งาน

1) ในเซสชัน interactive ด้วย /model — วิธีที่ยืดหยุ่นที่สุด สลับได้กลางทางโดยไม่ต้องออกจากเซสชัน และคำสั่งนี้ปรับได้ทั้ง โมเดล + reasoning effort พร้อมกัน

/model

2) ตอนเปิดโปรแกรมด้วย flag --model / -m

codex -m gpt-5.6

3) ตั้งค่าถาวรใน config.toml — เหมาะกับ default ประจำเครื่อง/โปรเจกต์

model = "gpt-5.6"
model_reasoning_effort = "high"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

หากต้องการ override เฉพาะรอบเดียวโดยไม่แก้ไฟล์ ใช้ -c / --config ได้ (ค่าเป็น TOML string จึงต้องใส่ quote ซ้อน)

codex --config model='"gpt-5.6"'

💡 บน ChatGPT / Codex cloud สลับโมเดลได้จาก model selector ใต้ช่องพิมพ์ ส่วนรายละเอียดการตั้งค่าไฟล์ config.toml แบบเต็ม (profiles, precedence, approval/sandbox) ดูในบทว่าด้วยการตั้งค่า Codex

ตารางแนะนำเลือกโมเดลตามงาน

ใช้เป็นจุดเริ่ม แล้วปรับตามผลจริงและงบประมาณของทีม

ลักษณะงานโมเดลแนะนำreasoning effort
ถาม-ตอบเร็ว, แก้บั๊กเล็ก, จัดรูปแบบโค้ดLuna (หรือ Terra)minimal–low
งาน dev ประจำวัน / เพิ่มฟีเจอร์ทั่วไปTerramedium
refactor ใหญ่, ออกแบบสถาปัตยกรรม, debug ซับซ้อนSolhigh–xhigh
code review เชิงลึก / มองหาช่องโหว่ securitySolhigh
งาน headless/CI จำนวนมาก (คุมต้นทุนเป็นหลัก)Luna / Terralow–medium
iterate โค้ดแบบ real-time (ChatGPT Pro)GPT-5.3 Codex Spark—

💡 ถ้ายังไม่แน่ใจ: เริ่มที่ Sol + medium เป็น baseline แล้วค่อยขยับ — ลด effort/ลงรุ่นเมื่อรู้สึกช้าหรือเปลืองเกินจำเป็น และเพิ่ม effort/ขึ้นรุ่นเมื่อผลลัพธ์ยังไม่ลึกพอ

ข้อควรระวัง: รายชื่อรุ่นเปลี่ยนบ่อย

โมเดลของ OpenAI ออกรุ่นใหม่และปลดรุ่นเก่าเป็นระยะ (เช่น gpt-5-codex → 5.1/5.2/5.3-codex → ตระกูล 5.6) ชื่อและ default ที่ hardcode ไว้ในสคริปต์หรือ AGENTS.md อาจล้าสมัยได้เร็ว แนวปฏิบัติที่ปลอดภัย:

  • ยืนยันโมเดล/effort ที่ใช้จริงด้วย /model และ /status ในเซสชัน ก่อนเชื่อค่าที่จำไว้
  • ตรวจรายชื่อรุ่นล่าสุดที่ learn.chatgpt.com/docs/models และเช็ค flag ที่แท้จริงด้วย codex --help
  • ในทีม/CI ให้ตั้งชื่อรุ่นไว้ที่จุดเดียว (เช่นใน config.toml หรือ profile) เพื่ออัปเดตครั้งเดียวแล้วมีผลทั้งระบบ แทนการกระจายชื่อรุ่นไว้หลายที่

บทที่ 4: โหมดการอนุมัติและระบบ Sandbox เพื่อความปลอดภัย

การใช้ Codex แบบมืออาชีพไม่ได้อยู่ที่ "สั่งเก่งแค่ไหน" แต่อยู่ที่ "คุมขอบเขตให้แน่นแค่ไหน" เพราะ Codex เป็น agent ที่รันเชลล์และแก้ไฟล์ได้จริง Codex จึงออกแบบระบบความปลอดภัยเป็น สองมิติที่แยกจากกันโดยสิ้นเชิง คือ approval (เมื่อไรต้องขออนุมัติจากคุณ) และ sandbox (Codex แตะอะไรได้บ้าง) เข้าใจสองมิตินี้แล้วคุณจะปรับความเร็ว/ความปลอดภัยได้ตามงานโดยไม่ต้องเสี่ยงเกินจำเป็น

สองมิติที่แยกกัน: Approval กับ Sandbox

หลายคนสับสนคิดว่าเป็นเรื่องเดียวกัน แต่จริง ๆ แล้วแยกกันชัดเจน:

  • approval_policy = จังหวะที่ Codex "หยุดถามคุณก่อนทำ" (เป็นเรื่องของการยืนยันจากมนุษย์)
  • sandbox_mode = "กำแพง" ที่จำกัดว่าสิ่งที่ Codex ทำจะกระทบระบบได้แค่ไหน (เป็นเรื่องของขอบเขตทางเทคนิค แม้ตอนที่ไม่ถาม)

ทั้งสองทำงานเป็นด่านซ้อนกัน ดังภาพ:

flowchart TD
    A[Codex ต้องการรันคำสั่ง หรือ แก้ไฟล์] --> B{approval_policy<br/>ต้องขออนุมัติไหม?}
    B -->|ต้องถาม| C[ผู้ใช้ อนุมัติ / ปฏิเสธ]
    B -->|ไม่ต้องถาม| D{sandbox_mode<br/>อยู่ในขอบเขตที่อนุญาตไหม?}
    C -->|อนุมัติ| D
    C -->|ปฏิเสธ| X[ยกเลิก]
    D -->|อยู่ในขอบเขต| E[ดำเนินการ]
    D -->|เกินขอบเขต| X

💡 คิดง่าย ๆ ว่า approval คือ "คนเฝ้าประตู" ส่วน sandbox คือ "ความสูงของกำแพง" คุณตั้งได้อิสระจากกัน เช่น ไม่ถามเลย (never) แต่ล้อมด้วยกำแพงแคบ ๆ (read-only) ก็ยังปลอดภัย

ระดับของ Sandbox (sandbox_mode)

sandbox_mode มี 3 ระดับ เรียงจากปลอดภัยสุดไปเปิดกว้างสุด:

sandbox_modeเขียนไฟล์ได้ขอบเขตเหมาะกับ
read-onlyไม่ได้ (อ่านอย่างเดียว)อ่านโค้ดได้ แต่ห้ามแก้ไฟล์/ห้ามรันคำสั่งที่เปลี่ยนสถานะสำรวจโค้ด ถาม-ตอบ วางแผน รีวิว
workspace-writeได้ เฉพาะภายใน workspaceเขียนได้ในโฟลเดอร์โปรเจกต์ (repo/cwd) แต่ส่วนอื่นของเครื่องยังถูกกันงานพัฒนาประจำวัน
danger-full-accessได้เต็มที่ทั้งเครื่องไม่มีการจำกัดจาก sandboxเฉพาะสภาพแวดล้อมที่แยกออกมาแล้วเท่านั้น

การควบคุม network

ในโหมดที่มี sandbox (โดยเฉพาะ read-only และ workspace-write) การเข้าถึงเครือข่ายออกนอกเครื่องจะถูกจำกัดโดยดีฟอลต์ เพื่อกันไม่ให้ Codex ดึง/ส่งข้อมูลออกไปโดยไม่ตั้งใจ (เช่น รัน npm install ที่โหลดของจากอินเทอร์เน็ต) ส่วน danger-full-access จะเปิด network เต็มที่ตามชื่อ

⚠️ ถ้างานของคุณจำเป็นต้องต่อเน็ต (ติดตั้ง dependency, เรียก API) ในโหมด sandbox ให้ตรวจสอบคีย์เปิด network ที่แน่นอนใน config-reference ของเวอร์ชันที่คุณใช้ อย่าเดาชื่อคีย์ และอย่าใช้วิธีลัดด้วยการเปิด danger-full-access ทั้งเซสชันเพียงเพราะขั้นตอนเดียวต้องการเน็ต

Approval policy (approval_policy)

approval_policy ควบคุมว่าเมื่อไร Codex จะหยุดขออนุมัติก่อนลงมือ ค่าที่รองรับหลัก ๆ:

approval_policyพฤติกรรม
untrustedเข้มที่สุด ถือว่าคำสั่งส่วนใหญ่ไม่น่าเชื่อถือ จึงขออนุมัติก่อนทำเกือบทุกอย่าง
on-requestCodex ตัดสินใจเองว่าอันไหนควรถาม อันไหนทำได้เลย เป็นค่าที่สมดุลสำหรับใช้งานจริง
neverไม่ถามเลย ทำงานต่อเนื่องภายใต้ขอบเขตของ sandbox ที่ตั้งไว้ล้วน ๆ

⚠️ บางแหล่ง/บางเวอร์ชันของ CLI ยังกล่าวถึงค่า on-failure (ขออนุมัติเฉพาะตอนคำสั่งใน sandbox ทำงานล้มเหลว) ด้วย ค่านี้อาจต่างกันตามเวอร์ชัน แนะนำยืนยันด้วย codex --help หรือ config-reference ของเวอร์ชันที่ติดตั้งจริงก่อนนำไปใส่ config

การจับคู่ที่แนะนำและ preset

เนื่องจากทั้งสองมิติแยกกัน คุณจึงจับคู่ได้หลายแบบ ตารางนี้ช่วยเลือกตามลักษณะงาน:

สถานการณ์sandbox_modeapproval_policy
อ่าน/สำรวจโค้ด, วางแผน, ไม่อยากให้แก้อะไรread-onlyon-request หรือ never
งานพัฒนาประจำวัน (ค่าแนะนำ)workspace-writeon-request
งานอัตโนมัติในสภาพแวดล้อมที่แยกแล้วdanger-full-accessnever

คู่ที่ Codex ใช้เป็น "Auto" preset คือ:

codex --sandbox workspace-write --ask-for-approval on-request

นี่คือจุดตั้งต้นที่ดีสำหรับงานส่วนใหญ่ Codex แก้ไฟล์ในโปรเจกต์ได้คล่อง แต่ยังถามก่อนทำสิ่งที่เสี่ยง

💡 อยากให้ค่าเหล่านี้ติดตัวทุกครั้งโดยไม่ต้องพิมพ์ flag ให้ตั้งใน ~/.codex/config.toml หรือแยกเป็น profile ตามระดับความเสี่ยง (ดูรายละเอียดในบทว่าด้วยการตั้งค่า config.toml, profiles และ AGENTS.md)

Flags และคำสั่งที่เกี่ยวข้อง

flags สำหรับ override รายเซสชัน (CLI flag ชนะค่าใน config เสมอ):

Flagย่อค่าที่รับ
--sandbox-sread-only | workspace-write | danger-full-access
--ask-for-approval-auntrusted | on-request | never
--config-coverride คีย์ config ใด ๆ แบบ inline
--profile-pเลือก profile ที่ตั้งค่าความเสี่ยงไว้ล่วงหน้า

ระหว่างเซสชัน interactive ปรับได้ด้วย slash command โดยไม่ต้องปิด/เปิดใหม่:

  • /approvals — ปรับ approval policy กลางทาง
  • /permissions — เลือกสิ่งที่ Codex ทำได้
  • /status — ตรวจดูว่าเซสชันนี้กำลังใช้ sandbox/approval แบบไหนอยู่

โหมดอัตโนมัติเต็มรูปแบบและ bypass ที่อันตราย

Codex มีวิธีสั่งให้ทำงานแบบไม่หยุดถาม (เช่นการจับคู่ Auto preset ด้านบนกับ never) และ มีตัวเลือกที่ปิดทั้ง sandbox และ approval พร้อมกัน ซึ่งเท่ากับถอดทั้งคนเฝ้าประตูและกำแพงออกทั้งหมด

⚠️ ชื่อ flag ที่แน่นอนสำหรับโหมด full-auto และตัว bypass แบบสุดขั้วอาจต่างกันตามเวอร์ชัน CLI ให้ยืนยันด้วย codex --help เสมอ ห้ามเดาหรือคัดลอกชื่อ flag จากบทความเก่า ๆ มาใช้แบบไม่ตรวจสอบ เพราะ flag ประเภทนี้กระทบความปลอดภัยโดยตรง

กลไก sandbox บน macOS/Linux

sandbox ของ Codex ไม่ได้เป็นแค่การ "ตกลงกันด้วยวาจา" กับตัวโมเดล แต่บังคับใช้ที่ระดับระบบปฏิบัติการ โดยพฤติกรรมและกลไกเบื้องหลังอาจต่างกันระหว่าง macOS กับ Linux รวมถึงต่างกันเมื่อรันในคอนเทนเนอร์หรือสภาพแวดล้อมที่ไม่มี sandbox ดั้งเดิมของ OS

ประเด็นที่ต้องรู้ในทางปฏิบัติ:

  • ผลลัพธ์เชิงพฤติกรรม (เช่น เขียนได้เฉพาะใน workspace, กัน network) จะเหมือนกันตามที่ตั้งไว้ แต่ "วิธีบังคับ" ต่างแพลตฟอร์มกัน
  • ในบางสภาพแวดล้อมที่ระบบ sandbox ของ OS ใช้ไม่ได้ พฤติกรรมอาจเปลี่ยน ต้องระวังเป็นพิเศษ
  • Codex cloud รันแต่ละ task ในคอนเทนเนอร์ sandbox ที่แยกกันอยู่แล้ว จึงเป็นสภาพแวดล้อมที่ปลอดภัยกว่าสำหรับงานอัตโนมัติเต็มรูปแบบ (ดูบทว่าด้วย Codex cloud และการรวมกับ GitHub)

💡 ถ้าต้องการรายละเอียดกลไกระดับ OS ที่แน่นอนของเวอร์ชันที่คุณใช้ ให้อ้างอิงเอกสารทางการ (learn.chatgpt.com) แทนการสรุปเอง เพราะรายละเอียดส่วนนี้เปลี่ยนได้ตามเวอร์ชัน

แนวปฏิบัติด้านความปลอดภัยที่แนะนำ

  1. ตั้งต้นให้แน่นไว้ก่อน ใช้ workspace-write + on-request เป็นค่ามาตรฐาน แล้วค่อยผ่อนเมื่อจำเป็น ไม่ใช่เริ่มจากเปิดหมดแล้วค่อยรัด
  2. สำรวจก่อนแก้ ถ้าแค่ต้องการให้ Codex อ่านโค้ด/วางแผน ให้เริ่มด้วย read-only จะแก้อะไรค่อยยกระดับ
  3. แยก posture ด้วย profile ทำ profile หนึ่งสำหรับงานอ่านอย่างเดียว อีกอันสำหรับงานแก้ไฟล์ เรียกด้วย --profile เพื่อไม่ให้เผลอใช้สิทธิ์เกินงาน
  4. danger-full-access และ bypass ใช้เฉพาะในสภาพแวดล้อมที่แยกแล้วเท่านั้น เช่น คอนเทนเนอร์แบบใช้แล้วทิ้ง, CI, หรือ Codex cloud ห้ามใช้บนเครื่องหลักที่มีข้อมูลหรือ credential สำคัญ
  5. ระวังโปรเจกต์ที่ไม่ไว้ใจ Codex จะโหลด config ระดับโปรเจกต์เฉพาะเมื่อคุณ trust โปรเจกต์นั้น อย่า trust repo แปลกหน้าแล้วปล่อยให้รันด้วยสิทธิ์กว้าง
  6. ใน CI ใช้ safety-strategy ที่รัดกุม GitHub Action ทางการ (openai/codex-action) มี safety-strategy โดยค่าดีฟอลต์คือ drop-sudo และมีตัวเลือกเข้มกว่าอย่าง read-only หลีกเลี่ยงค่า unsafe เว้นแต่จำเป็นจริง ๆ และเข้าใจผลกระทบเต็มที่
  7. บันทึกกฎความปลอดภัยลง AGENTS.md ใส่ security considerations ไว้ในไฟล์ AGENTS.md เพื่อให้ agent ยึดเป็นแนวทางทุกเซสชัน (ดูบทว่าด้วยการตั้งค่า AGENTS.md)

⚠️ คู่ที่อันตรายที่สุดคือ danger-full-access + never เพราะ Codex จะรันคำสั่งใด ๆ ทั่วทั้งเครื่องได้โดยไม่ถามและไม่มีกำแพงกั้นเลย ใช้ก็ต่อเมื่ออยู่ในสภาพแวดล้อมที่พังแล้วสร้างใหม่ได้ทันทีเท่านั้น อย่ารันบนเครื่องทำงานจริง

บทที่ 5: การกำหนดกฎและบริบทด้วย AGENTS.md

ถ้า config.toml คือการบอก Codex ว่า "ทำงานด้วยโมเดลอะไร ภายใต้สิทธิ์แค่ไหน" ไฟล์ AGENTS.md ก็คือการบอกว่า "โปรเจกต์นี้มีกฎอะไร ต้อง build/test อย่างไร และห้ามแตะอะไร" มองง่าย ๆ ว่า AGENTS.md คือ README สำหรับ agent ไฟล์นี้คือจุดที่คุณเปลี่ยน Codex จากผู้ช่วยทั่วไป ให้กลายเป็นวิศวกรที่เข้าใจ convention ของทีมคุณจริง ๆ

AGENTS.md คืออะไร

AGENTS.md เป็นไฟล์ Markdown ที่ให้บริบทและคำสั่งเชิงพฤติกรรมแก่ AI coding agent โดยตรง Codex จะอ่านไฟล์นี้ อัตโนมัติทุกครั้งที่เริ่มเซสชัน โดยไม่ต้องสั่งเพิ่ม

จุดสำคัญ 2 ข้อ:

  • แยกจาก README.md — README.md เขียนเพื่อให้มนุษย์อ่าน (วิธีติดตั้ง วิธีใช้งาน) ส่วน AGENTS.md เขียนเพื่อให้ agent อ่าน (กฎการทำงาน คำสั่งที่ต้องรัน สิ่งที่ห้ามทำ) จึงควรแยกกันเพื่อไม่ให้ README รกด้วยรายละเอียดที่มนุษย์ไม่ได้สนใจ
  • เป็นมาตรฐานเปิดข้ามเครื่องมือ — AGENTS.md เป็นฟอร์แมตเปิด (มาตรฐาน agents.md) ที่เครื่องมืออื่น เช่น Cursor, Copilot, Gemini CLI, Windsurf ก็อ่านร่วมกันได้ เขียนครั้งเดียวใช้ได้หลาย agent

💡 ให้คิดว่า AGENTS.md คือ onboarding doc ที่คุณจะยื่นให้วิศวกรใหม่วันแรก แต่แทนที่จะเป็นคน ผู้รับคือ agent ที่จะอ่านมันซ้ำทุกเซสชัน

ลำดับชั้นการอ่าน (hierarchy)

Codex ไม่ได้อ่าน AGENTS.md แค่ไฟล์เดียว แต่ไล่อ่านเป็นลำดับชั้นตั้งแต่ระดับ global ลงมาถึงโฟลเดอร์ที่ใกล้ไฟล์ที่กำลังแก้ที่สุด แล้วนำมา ต่อกัน (concatenate) จากบนลงล่าง คั่นด้วยบรรทัดว่าง หลักการทับซ้อนคือ ไฟล์ที่อยู่ใกล้ไฟล์ที่กำลังแก้ที่สุดชนะ (เพราะปรากฏทีหลังในการต่อไฟล์) และเหนือสิ่งอื่นใด prompt ที่คุณพิมพ์ใน chat override ทุกไฟล์เสมอ

flowchart TD
    A["~/.codex/AGENTS.md<br/>(global — preference ข้ามทุก repo)"] --> B["&lt;repo root&gt;/AGENTS.md<br/>(กฎระดับทั้งโปรเจกต์)"]
    B --> C["&lt;repo&gt;/services/payments/AGENTS.md<br/>(กฎเฉพาะโฟลเดอร์ย่อย)"]
    C --> D["ไฟล์ที่กำลังแก้ (cwd)"]
    P["prompt ใน chat"] -.->|"override ทุกไฟล์"| D

    classDef win fill:#007aff,stroke:#0a6ae6,color:#fff;
    class C win;

สรุปทั้งสามระดับ:

ระดับ (scope)ตำแหน่งไฟล์ใช้เก็บอะไร
Global~/.codex/AGENTS.mdpreference ส่วนตัวที่ใช้ข้ามทุก repo เช่น dependency manager ที่ชอบใช้, สไตล์การตอบ
Project root<repo>/AGENTS.mdกฎที่ใช้ทั้งโปรเจกต์ เช่น build/test/lint, code style หลัก
Subdirectory<repo>/services/x/AGENTS.mdกฎเฉพาะส่วน เช่น convention ของ service นั้น ๆ (เหมาะกับ monorepo — วางเพิ่มในแต่ละ package)

ไฟล์ override: แต่ละ scope จะตรวจ AGENTS.override.md ก่อน ถ้าไม่มีจึง fall back ไปที่ AGENTS.md

ระดับไฟล์ที่ตรวจก่อนไฟล์ fallback
Global~/.codex/AGENTS.override.md~/.codex/AGENTS.md
แต่ละ directory<dir>/AGENTS.override.md<dir>/AGENTS.md

⚠️ แต่ละ directory เลือกได้ มากสุด 1 ไฟล์เท่านั้น และใช้ไฟล์ non-empty ไฟล์แรกที่เจอ — ถ้ามีทั้ง AGENTS.override.md และ AGENTS.md ในโฟลเดอร์เดียวกัน ตัว override จะชนะและ AGENTS.md ในโฟลเดอร์นั้นถูกมองข้าม (ไม่ได้ merge สองไฟล์เข้าด้วยกัน) จึงอย่าคาดหวังว่าจะกระจายกฎไว้สองไฟล์ในโฟลเดอร์เดียว ประโยชน์จริงของ override คือใช้เขียนทับกฎเฉพาะทางในโฟลเดอร์ย่อย เช่น services/payments/AGENTS.override.md

ข้อจำกัดที่ต้องรู้:

  • ขนาด AGENTS.md ที่รวมกันทั้งหมดถูกจำกัดที่ 32 KiB โดย default (ปรับได้ผ่านคีย์ project_doc_max_bytes ใน config)
  • ไฟล์ว่างจะถูกข้าม
  • การค้นหา (discovery) หยุดที่ cwd ไม่ไล่ลึกลงไปในโฟลเดอร์ย่อยที่ต่ำกว่าตำแหน่งที่คุณทำงานอยู่

⚠️ 32 KiB คือเพดานที่รวมทุกไฟล์ในลำดับชั้น ยิ่งเขียนยาวเวิ่นเว้อ ยิ่งกินโควตาและ dilute คำสั่งที่สำคัญจริง ๆ เขียนให้กระชับ เน้น actionable — คุณภาพชนะปริมาณเสมอ

สิ่งที่ควรใส่ใน AGENTS.md

ไม่มี section ไหนที่ บังคับ — โครงสร้างยืดหยุ่นได้ตามโปรเจกต์ แต่สิ่งที่ควรมีเพื่อให้ agent ทำงานได้ตรงใจทีม ได้แก่

หัวข้อใส่อะไรตัวอย่างที่ actionable
Project overviewโปรเจกต์นี้คืออะไร stack หลักคืออะไร"REST API ด้วย FastAPI + PostgreSQL"
Build / Test / Lintคำสั่งที่ต้องรัน โดยเฉพาะก่อนเปิด PR"รัน npm run lint และ npm test ให้ผ่านก่อนเปิด PR ทุกครั้ง"
Code style & conventionsnaming, layout, pattern ที่ทีมยึด"ใช้ 2-space indent, ตั้งชื่อไฟล์ kebab-case"
Testing instructionsเขียน test อย่างไร วางไว้ที่ไหน"ทุกฟีเจอร์ใหม่ต้องมี unit test ใน tests/"
สิ่งที่ห้ามทำ (do-not)ข้อห้ามชัดเจน กันความเสียหาย"ห้ามแก้ไฟล์ใน migrations/ ที่ commit ไปแล้ว"
Security considerationsจุดอ่อนไหวที่ต้องระวัง"ห้าม log ค่า token หรือ secret ใด ๆ"
Deployment stepsขั้นตอน deploy (ถ้าเกี่ยวข้อง)—
PR guidelinesรูปแบบ commit / PR ที่ทีมต้องการ"commit message ใช้ Conventional Commits"
## Code Review Rulesกฎเฉพาะสำหรับ GitHub code reviewดูรายละเอียดในบทว่าด้วยการรวม Codex กับ GitHub

หลักการเลือกว่าจะวางกฎไว้ scope ไหน:

  • Global (~/.codex/AGENTS.md) — สำหรับ preference ที่ติดตัวคุณข้ามทุก repo เช่น dependency manager ที่คุณชอบใช้
  • Project root — กฎที่ทุกคนในทีมต้องยึดร่วมกัน
  • Subdirectory / nested — กฎเฉพาะ service นั้น ๆ วางไว้ใกล้โค้ดที่มันคุมมากที่สุด

💡 สำหรับ ## Code Review Rules กฎที่ดีควรกระชับ ระบุพฤติกรรมที่ต้อง flag พร้อมทางเลือกที่ปลอดภัย (safe alternative) มี scope ชัดและ durable และ ไม่ควรครอบคลุมงาน lint/format เพราะปล่อยให้ CI จัดการได้ดีกว่า

สร้างเริ่มต้นด้วยคำสั่ง /init

ไม่ต้องเขียน AGENTS.md จากศูนย์ — ในเซสชัน interactive พิมพ์คำสั่ง

/init

Codex จะสแกน repo เพื่อสร้างความเข้าใจโปรเจกต์เบื้องต้น แล้วเขียนไฟล์ AGENTS.md scaffold ให้ที่ project root คำสั่งนี้ใช้ได้ทั้งใน Codex CLI และ ChatGPT desktop app ด้วย workflow เดียวกัน

💡 workflow ที่แนะนำ: ใช้ /init วาง scaffold ก่อน แล้วค่อยแก้เสริมด้วยมือ — เติมคำสั่ง build/test/lint จริงของทีม ระบุข้อห้ามที่ agent เคยพลาด และตัดส่วนที่ไม่จำเป็นออกให้อยู่ในงบ 32 KiB

เทมเพลต AGENTS.md ตัวอย่างที่นำไปใช้ได้จริง

วางไฟล์นี้ที่ root ของ repo แล้วปรับให้ตรงกับ stack ของคุณ

# AGENTS.md

## Project overview
Web service สำหรับจัดการคำสั่งซื้อ เขียนด้วย TypeScript (Node.js) + PostgreSQL
โครงสร้างหลัก: `src/` โค้ดแอป, `tests/` เทสต์, `migrations/` schema migration

## Build, test, lint
- ติดตั้ง dependency: `npm ci`
- รัน dev server: `npm run dev`
- รันเทสต์ทั้งหมด: `npm test`
- ก่อนเปิด PR ทุกครั้ง: ต้องรัน `npm run lint` และ `npm test` ให้ผ่าน

## Code style & conventions
- TypeScript strict mode ห้ามใช้ `any` โดยไม่มีเหตุผลกำกับ
- ตั้งชื่อไฟล์แบบ kebab-case, ตั้งชื่อ type/interface แบบ PascalCase
- ใช้ async/await ไม่ใช้ raw Promise chain
- import แบบ absolute path จาก `src/` (ตั้ง alias ไว้ที่ `@/`)

## Testing
- ทุกฟีเจอร์ใหม่ต้องมี unit test คู่กัน วางใน `tests/` โครงสร้างสะท้อน `src/`
- ห้าม mock ทั้ง database layer — ใช้ test container ตาม `tests/setup.ts`

## สิ่งที่ห้ามทำ (Do not)
- ห้ามแก้ไฟล์ใน `migrations/` ที่ commit แล้ว ให้สร้าง migration ใหม่แทน
- ห้าม commit ค่า secret/API key ลง repo ใช้ตัวแปรจาก `.env` เท่านั้น
- ห้าม upgrade major version ของ dependency โดยไม่ถามก่อน

## Security
- ห้าม log ค่า token, password หรือ PII ใด ๆ
- validate input ทุกจุดที่รับข้อมูลจากภายนอกด้วย schema ใน `src/schemas/`

## PR guidelines
- commit message ใช้รูปแบบ Conventional Commits (feat:, fix:, chore:)
- 1 PR ต่อ 1 เรื่อง แยก refactor ออกจาก feature

## Code Review Rules
- flag ทุกจุดที่รับ input ภายนอกแล้วไม่ได้ validate ด้วย schema
  แนะนำทางแก้: เพิ่ม schema validation ก่อนประมวลผล
- flag การเพิ่ม dependency ใหม่ที่ไม่จำเป็น พร้อมเสนอทางเลือกใน stdlib
- ไม่ต้องรีวิวเรื่อง formatting/lint (CI ดูแลแล้ว)

รายละเอียดคีย์ project_doc_max_bytes, sandbox_mode และ approval_policy ที่กล่าวถึงในบทนี้ ดูเพิ่มในบทว่าด้วยการตั้งค่า Codex CLI ผ่าน config.toml ส่วนการนำ ## Code Review Rules ไปใช้กับ @codex review บน pull request ดูในบทว่าด้วยการรวม Codex กับ GitHub

บทที่ 6: คำสั่งและฟีเจอร์หลักในการใช้งานประจำวัน

เมื่อพิมพ์ codex ในโฟลเดอร์โปรเจกต์ คุณจะเข้าสู่ interactive TUI (terminal UI) ซึ่งเป็นสนามหลักที่คุณจะใช้ทำงานทุกวัน บทนี้ว่าด้วยลูปการทำงานจริง: การสั่งงานด้วย slash commands, การแนบรูปภาพและอ้างไฟล์เข้าไปในบทสนทนา, การสลับโมเดล/สิทธิ์กลางทาง, และการจัดการ session กับบริบทไม่ให้ล้น เนื้อหาการติดตั้ง/ล็อกอิน, การตั้งค่า config.toml กับ AGENTS.md, และรายละเอียด sandbox/approval อยู่ในบทก่อนหน้า บทนี้จะอ้างถึงเมื่อจำเป็นแทนการอธิบายซ้ำ

ลูปการทำงานประจำวันใน TUI

การทำงานส่วนใหญ่จะวนอยู่ในรอบสั้น ๆ นี้: พิมพ์คำสั่งเป็นภาษาธรรมชาติ → Codex เสนอ plan/แก้ไฟล์/รันคำสั่ง → คุณอนุมัติหรือปฏิเสธ (ตาม approval policy) → ตรวจผลด้วย /review หรือ /status → สั่งงานต่อ

flowchart LR
    A[พิมพ์ prompt] --> B[Codex เสนอ plan / แก้ไฟล์ / รันคำสั่ง]
    B --> C{approval?}
    C -->|approve| D[Codex ลงมือ]
    C -->|reject| A
    D --> E[ตรวจผล: /review, /status, git diff]
    E --> F{พอใจ?}
    F -->|ยัง| A
    F -->|เสร็จงานย่อย| G[/new เริ่มงานใหม่ หรือปิดเซสชัน]

💡 พิมพ์ / เพียงตัวเดียวในช่องพิมพ์ TUI จะเปิดเมนูรายการ slash commands ที่เวอร์ชันของคุณรองรับจริง พร้อมคำอธิบายสั้น ๆ วิธีนี้เชื่อถือได้กว่าการจำรายชื่อคำสั่ง เพราะชุดคำสั่งอาจต่างกันตามเวอร์ชัน CLI

Slash commands ที่ใช้บ่อย

ตารางนี้คือคำสั่งที่ยืนยันได้จากเอกสาร Codex CLI และเป็นชุดที่คุณจะหยิบใช้ประจำ

คำสั่งหน้าที่ใช้เมื่อ
/initสแกน repo แล้วสร้างไฟล์ AGENTS.md scaffold ที่ project rootเริ่มใช้ Codex กับโปรเจกต์ใหม่ครั้งแรก
/statusแสดง config ของ session ปัจจุบัน (โมเดล, sandbox mode, approval policy ฯลฯ)อยากรู้ว่าตอนนี้กำลังทำงานภายใต้ค่าอะไร
/modelสลับโมเดลและปรับ reasoning effort ระหว่างเซสชันงานยากขึ้น/ง่ายลง อยากเปลี่ยนรุ่นหรือระดับการคิด
/approvalsปรับ approval policy กลางเซสชันอยากผ่อน/เข้มการขออนุมัติชั่วคราว
/permissionsเลือกสิ่งที่ Codex ทำได้ (สิทธิ์การทำงาน)ปรับขอบเขตสิ่งที่ agent แตะได้
/reviewให้ Codex รีวิว change/diff เพื่อหา issueก่อน commit หรือก่อนเปิด PR
/newเริ่มบทสนทนาใหม่ (ล้างบริบทเดิม)ขึ้นงานใหม่ที่ไม่เกี่ยวกับงานก่อนหน้า
/exitออกจากเซสชันจบงาน

⚠️ /approvals และ /permissions ปรากฏในเอกสารคนละแหล่งและอาจซ้อนทับหน้าที่กัน หรือมีชื่อ/พฤติกรรมต่างกันตามเวอร์ชัน ถ้าไม่พบตัวใดตัวหนึ่ง ให้เปิดเมนู / ดูว่าเวอร์ชันของคุณใช้ชื่อใด

นอกเหนือจากตารางข้างต้น เวอร์ชัน CLI ที่คุณติดตั้งอาจมีคำสั่งเพิ่มเติม เช่น สำหรับดู diff, ล้าง/รีเซ็ตบทสนทนา (/clear), จัดการ MCP servers (/mcp), หรือบีบอัดบริบท (/compact) เอกสารที่ใช้ประกอบบทนี้ไม่ได้ยืนยันชื่อคำสั่งเหล่านี้ตรง ๆ จึงแนะนำให้พิมพ์ / เพื่อดูรายการจริง หรือรัน codex --help ก่อนพึ่งพาในสคริปต์/คู่มือทีม (การจัดการ MCP servers ยังตั้งค่าถาวรได้ผ่าน [mcp_servers.<id>] ใน config.toml และคำสั่งย่อย codex mcp — ดูบทว่าด้วย MCP)

สลับโมเดลและ approval ระหว่างทำงาน

ไม่ต้องออกจากเซสชันเพื่อเปลี่ยนโมเดล ใช้ /model เพื่อเลือกโมเดลและ reasoning effort ใหม่ได้ทันที เช่น ยกระดับเป็น effort สูงเมื่อเจอบั๊กที่ต้องคิดหลายขั้น แล้วลดกลับเป็น medium เมื่อทำงานทั่วไปเพื่อประหยัดเวลาและโทเคน ในทำนองเดียวกัน /approvals ใช้ผ่อนหรือเพิ่มความเข้มของการขออนุมัติชั่วคราวโดยไม่กระทบค่าใน config.toml

รายละเอียดว่าโมเดลแต่ละรุ่นเหมาะกับงานแบบใด, ค่า reasoning effort (minimal/low/medium/high/xhigh), และความหมายของ approval policy (untrusted/on-request/never) กับ sandbox mode อยู่ในบทเรื่องโมเดลและบทเรื่อง approval + sandbox

💡 ถ้าต้องปรับค่าเดิม ๆ ทุกครั้งที่เปิดเซสชัน ให้ย้ายไปตั้งเป็นค่า default ใน config.toml หรือทำเป็น profile (เรียกด้วย codex --profile <name>) แทนการมานั่งพิมพ์ /model /approvals ซ้ำ ๆ — ดูบทว่าด้วยการตั้งค่า

การแนบรูปภาพเป็นบริบท

Codex CLI รับรูปภาพเป็น context ได้ผ่าน flag --image เหมาะกับการส่งภาพ error, screenshot ของ UI, หรือ mockup ที่อยากให้ agent อ้างอิง

codex --image ./screenshot.png "อธิบายว่า error ในรูปนี้เกิดจากอะไร และเสนอวิธีแก้"

⚠️ รูปแบบการส่งหลายไฟล์ (เช่นใส่ --image ซ้ำหรือคั่นด้วยจุลภาค) และวิธีแนบรูปกลางเซสชันใน TUI (paste/drag) ยังไม่ได้ยืนยันจากเอกสารที่ใช้ประกอบบทนี้ ให้ตรวจกับ codex --help ของเวอร์ชันที่ติดตั้ง

การอ้างอิงไฟล์ในบทสนทนา

Codex มีสิทธิ์เข้าถึงไฟล์ในโปรเจกต์อยู่แล้ว (ภายใต้ sandbox) วิธีที่ตรงไปตรงมาที่สุดคือระบุ path ในคำสั่งเป็นภาษาธรรมชาติ เช่น

รีแฟกเตอร์ฟังก์ชัน login ใน src/auth/login.ts ให้แยก validation ออกเป็นฟังก์ชันย่อย

Codex จะเปิดอ่านไฟล์ที่เกี่ยวข้องเอง และจะปฏิบัติตามคำสั่งใน AGENTS.md ที่อยู่ใกล้ไฟล์นั้นที่สุด (ดูบทว่าด้วย AGENTS.md) หากเวอร์ชันของคุณรองรับ autocomplete สำหรับ path (เช่นผ่านสัญลักษณ์นำหน้าอย่าง @) จะเห็นได้จากเมนูที่เด้งขึ้นเมื่อเริ่มพิมพ์ — ตรวจกับเวอร์ชันจริงแทนการสมมติ syntax

จัดการ session: เริ่มใหม่ และกลับมาทำต่อ

เมื่อจบงานย่อยหนึ่งและจะขึ้นงานที่ไม่เกี่ยวข้องกัน ให้ใช้ /new เพื่อล้างบริบทและเริ่มบทสนทนาใหม่ในเซสชันเดิม การเริ่มสะอาดแบบนี้ช่วยให้ agent ไม่สับสนกับบริบทงานก่อนหน้า และประหยัดโทเคน

หากปิดเทอร์มินัลไปแล้วอยากกลับมาทำงานเดิมต่อ ใช้ subcommand codex resume เพื่อกลับเข้าสู่ session/แชทที่บันทึกไว้

codex resume

ประวัติ session ถูกเก็บใน $CODEX_HOME (ค่า default คือ ~/.codex ซึ่งเก็บ auth, config, history, logs และ caches) จึงกลับมาต่อได้แม้ข้ามวัน

💡 ตัวเลือกของ codex resume (เช่นการเลือก session ล่าสุดหรือเลือกจากรายการ) ให้ดูจาก codex resume --help เนื่องจากรายละเอียด flag อาจต่างกันตามเวอร์ชัน สำหรับงาน headless/CI ที่ต้องรันซ้ำได้โดยไม่มี TUI ให้ใช้ codex exec แทน (ดูบทว่าด้วย headless/CI)

จัดการบริบทไม่ให้ล้น (context compaction)

ยิ่งบทสนทนายาว บริบทที่ Codex ต้องแบกก็ยิ่งโต จนอาจเข้าใกล้ขีดจำกัด context ของโมเดล ทำให้คำตอบช้าลง แพงขึ้น และคุณภาพลดลง มีสามแนวทางจัดการ

  1. บีบอัดบริบท (compaction) — สรุปบทสนทนาที่ผ่านมาให้กระชับเพื่อคืนพื้นที่ context โดยยังเก็บใจความสำคัญไว้ เวอร์ชันของคุณอาจมีคำสั่งอย่าง /compact สำหรับสิ่งนี้ ให้พิมพ์ / เพื่อยืนยันว่ามีจริงในเวอร์ชันที่ติดตั้ง
  2. เริ่มใหม่ด้วย /new — เมื่องานใหม่ไม่ต้องพึ่งบริบทเก่า การเริ่มสะอาดเป็นทางที่คุ้มค่าและง่ายที่สุด
  3. ตรึงบริบทถาวรไว้ใน AGENTS.md — ข้อมูลโปรเจกต์ที่ต้องใช้ซ้ำทุกครั้ง (คำสั่ง build/test, conventions) ควรอยู่ใน AGENTS.md เพื่อไม่ต้องอธิบายซ้ำในทุกบทสนทนา (ดูบทว่าด้วย AGENTS.md)

💡 ใช้ /status เช็คสถานะเซสชันเป็นระยะ หากเริ่มรู้สึกว่า agent ตอบช้าหรือหลงประเด็น มักเป็นสัญญาณว่าถึงเวลา compact หรือ /new

⚠️ เอกสารที่ใช้ประกอบบทนี้ไม่ได้ยืนยันชื่อคำสั่ง /compact, /clear, /diff ตรง ๆ ก่อนนำไปใส่ runbook หรือสอนทีม ให้ยืนยันด้วยเมนู / หรือ codex --help ของเวอร์ชันที่ใช้จริงเสมอ อย่าเดาชื่อ flag/คำสั่ง

บทที่ 7: การขยายความสามารถด้วย MCP และเครื่องมือภายนอก

โดยตัวเอง Codex ทำงานกับไฟล์และรันเชลล์ใน sandbox ได้อยู่แล้ว แต่พลังจริงจะมาเมื่อเราเปิดให้มัน "เอื้อมมือ" ออกไปหาเครื่องมือภายนอก เช่น ฐานข้อมูล ระบบเอกสาร หรือเบราว์เซอร์ ผ่านมาตรฐานกลางที่ชื่อ Model Context Protocol (MCP) บทนี้จะพาดูสองบทบาทของ Codex กับ MCP: เป็น MCP client ที่ไปเรียกใช้ server อื่น และเป็น MCP server ที่ให้เครื่องมืออื่นมาเรียกใช้ Codex กลับ

MCP คืออะไร และ Codex เข้ามาเกี่ยวตรงไหน

MCP เป็นโปรโตคอลกลางที่ให้ AI agent เชื่อมต่อกับแหล่งข้อมูล/เครื่องมือภายนอกในรูปแบบมาตรฐานเดียว แทนที่จะต้องเขียน integration เฉพาะกิจต่อบริการ Codex รองรับ MCP สองทิศทาง ดังภาพ

flowchart LR
    subgraph ClientRole["Codex เป็น MCP client"]
        C[Codex CLI / cloud] -->|เรียก tools| DB[(MCP server: database)]
        C -->|เรียก tools| DOC[(MCP server: docs)]
        C -->|เรียก tools| BR[(MCP server: browser)]
    end
    subgraph ServerRole["Codex เป็น MCP server"]
        A[agent / เครื่องมืออื่น] -->|เรียก codex เป็น tool| CX[codex mcp]
    end
  • เป็น client: Codex ต่อออกไปหา MCP server ภายนอกเพื่อดึง context หรือสั่งงาน (เช่น query ฐานข้อมูล ค้นเอกสาร คุมเบราว์เซอร์) — ตั้งค่าผ่าน [mcp_servers] ใน config.toml
  • เป็น server: Codex เปิดตัวเองให้ MCP client อื่น (agent, orchestrator, เครื่องมือภายนอก) เรียกใช้เป็น tool ผ่านคำสั่ง codex mcp

Codex เป็น MCP client: ประกาศ [mcp_servers] ใน config.toml

การผูก MCP server เข้ากับ Codex ทำผ่านไฟล์ config เดียวกับที่ใช้ตั้ง model, approval_policy, sandbox_mode (รายละเอียดโครงสร้าง config.toml และลำดับการ merge อยู่ในบทว่าด้วยการตั้งค่า Codex CLI แล้ว บทนี้จะโฟกัสเฉพาะส่วน MCP) แต่ละ server ประกาศเป็นตาราง [mcp_servers.<id>] โดย <id> คือชื่อที่เราตั้งเองไว้อ้างอิง

Codex รองรับ MCP server สองแบบ คือ STDIO (รัน process ในเครื่อง คุยผ่าน stdin/stdout) และ HTTP (ต่อไป endpoint ระยะไกล)

แบบ STDIO — รัน server เป็น process ในเครื่อง

# ~/.codex/config.toml

[mcp_servers.database]
command = "npx"
args = ["-y", "<ชื่อ-mcp-server-package>"]
env = { DATABASE_URL = "postgresql://user@localhost/mydb" }
cwd = "/path/to/workdir"
startup_timeout_sec = 20

แบบ HTTP — ต่อไป endpoint ระยะไกล

[mcp_servers.remote_docs]
url = "https://mcp.example.com/mcp"
bearer_token_env_var = "MCP_DOCS_TOKEN"
http_headers = { "X-Org-Id" = "acme" }

💡 เคล็ดลับ: key คือ mcp_servers แบบ snake_case ไม่ใช่ mcpServers แบบ camelCase ที่หลายเครื่องมืออื่นใช้ — ถ้าก็อป config มาจากที่อื่นแล้ว server ไม่ขึ้น ให้เช็คจุดนี้เป็นอันดับแรก

⚠️ ข้อควรระวังเรื่อง secret: สำหรับ HTTP ให้เก็บ token ไว้ใน environment variable แล้วชี้ด้วย bearer_token_env_var (ระบุ "ชื่อ env" ไม่ใช่ตัว token) อย่าฝัง token ตรงๆ ในไฟล์ ส่วน STDIO ถ้าเลี่ยงได้ให้ส่ง secret ผ่าน env จากตัวแปรที่มีอยู่แล้วในเชลล์ แทนการ hardcode ลงไฟล์ที่อาจถูก commit

คีย์ที่ใช้บ่อยในตาราง [mcp_servers.<id>]

คีย์ใช้กับความหมาย
commandSTDIOคำสั่งที่ใช้สตาร์ท server (string)
argsSTDIOอาร์กิวเมนต์ของคำสั่ง (array of strings)
envSTDIOตัวแปรแวดล้อมที่ส่งให้ process (map)
cwdSTDIOworking directory ของ process (string)
urlHTTPendpoint ของ server (string)
bearer_token_env_varHTTPชื่อ env ที่เก็บ bearer token
http_headersHTTPHTTP header เพิ่มเติม (map)
enabledทั้งคู่เปิด/ปิด server นี้ชั่วคราวโดยไม่ต้องลบ config
startup_timeout_secทั้งคู่เวลารอ server สตาร์ทก่อนถือว่า fail
tool_timeout_secทั้งคู่เวลารอผลของแต่ละ tool call
enabled_toolsทั้งคู่จำกัดให้ Codex เห็นเฉพาะ tool ที่ระบุ
default_tools_approval_modeทั้งคู่ระดับ approval เริ่มต้นของ tool ใน server นี้

⚠️ รายชื่อคีย์และค่าที่รับได้อาจต่างกันเล็กน้อยตามเวอร์ชัน CLI (เช่น บางแหล่งพบคีย์ required เพิ่มมา) ก่อนใช้จริงกับเวอร์ชันที่ติดตั้ง ให้ยืนยันกับหน้า config reference หรือรัน codex --help เพื่อดูออปชันที่ตรงกับเครื่องคุณ

จัดการ MCP servers ด้วยคำสั่ง codex mcp

นอกจากประกาศใน config.toml แล้ว Codex ยังมี subcommand codex mcp เป็นจุดรวมงานที่เกี่ยวกับ MCP โดยเฉพาะ ใช้สำหรับเชื่อม/จัดการ MCP server ผ่าน CLI

# ดู subcommand และรูปแบบการใช้งานที่แน่นอนของเวอร์ชันที่ติดตั้ง
codex mcp --help

💡 เคล็ดลับ: รายละเอียด subcommand ย่อยของ codex mcp (เช่น การเพิ่ม/ลิสต์ server) เปลี่ยนได้ตามเวอร์ชัน จึงแนะนำให้ยึด codex mcp --help เป็นแหล่งอ้างอิงจริง แทนการจำคำสั่งจากคู่มือเก่า

Codex เป็น MCP server: ให้เครื่องมืออื่นเรียกใช้

อีกบทบาทหนึ่งคือกลับด้าน — เปิด Codex ให้เป็น MCP server เพื่อให้ MCP client ตัวอื่น (agent อีกตัว, orchestrator, หรือ IDE ที่พูด MCP ได้) เรียกใช้ Codex เป็น "tool" หนึ่งในสาย workflow ของมัน ประโยชน์คือคุณสามารถซ้อน Codex ไว้ในระบบ multi-agent หรือให้ agent ตัวหลักมอบงาน coding บางส่วนมาให้ Codex จัดการ โดยยังได้ระบบ approval + sandbox ของ Codex ติดมาด้วย

การเปิดโหมดนี้ทำผ่านตระกูลคำสั่ง codex mcp เช่นเดียวกัน

⚠️ ข้อควรระวัง: รูปแบบคำสั่งที่แน่นอนสำหรับสตาร์ท Codex เป็น server ให้ตรวจสอบด้วย codex mcp --help ก่อน อย่าเดา flag เอง เพราะชื่อ subcommand/flag อาจต่างกันตามเวอร์ชัน เมื่อรันเป็น server แล้ว client ฝั่งตรงข้ามจะเห็น Codex เป็น tool ที่เรียกได้ตามสัญญา MCP

Use cases: ต่อกับฐานข้อมูล เอกสาร และเบราว์เซอร์

MCP มักถูกใช้เพื่อดึง context จาก GitHub, ฐานข้อมูล และเครื่องมือภายนอก ตัวอย่างสถานการณ์ที่นำมาใช้ได้จริง

Use caseCodex ทำอะไรได้เพิ่มรูปแบบ server ที่เหมาะ
ฐานข้อมูลquery schema/ข้อมูลจริงมาช่วยเขียน migration หรือ debug querySTDIO (รัน connector ในเครื่อง)
ระบบเอกสาร / knowledge baseค้นสเปกภายในหรือ docs มาเป็น context ก่อนแก้โค้ดHTTP (endpoint ภายในองค์กร)
เบราว์เซอร์เปิดหน้า/ตรวจ UI/ดึงข้อมูลจากหน้าเว็บระหว่างทำงานSTDIO (คุม headless browser)

ตัวอย่างการประกาศหลาย server พร้อมกันในไฟล์เดียว

# ~/.codex/config.toml

[mcp_servers.db]
command = "npx"
args = ["-y", "<mcp-server-สำหรับฐานข้อมูล>"]
env = { DATABASE_URL = "postgresql://user@localhost/appdb" }

[mcp_servers.docs]
url = "https://mcp.internal.example.com/mcp"
bearer_token_env_var = "INTERNAL_DOCS_TOKEN"

[mcp_servers.browser]
command = "npx"
args = ["-y", "<mcp-server-สำหรับเบราว์เซอร์>"]
enabled_tools = ["<tool ที่อนุญาตเท่านั้น>"]
default_tools_approval_mode = "on-request"

💡 เคล็ดลับ: ค่า command/args/ชื่อ package และรายชื่อ tool ของแต่ละ server ให้ดูจากเอกสารของ MCP server ตัวนั้นโดยตรง — ในตัวอย่างข้างบนใช้ placeholder ไว้ เพราะแพ็กเกจที่ใช้ขึ้นกับ server ที่คุณเลือก

แนวปฏิบัติที่ดีและข้อควรระวัง

  • จำกัดพื้นผิวด้วย enabled_tools: ถ้า server หนึ่งมี tool หลายตัวแต่คุณใช้จริงไม่กี่ตัว ให้ระบุเฉพาะที่ต้องใช้ ลดโอกาสที่ agent จะเรียก tool ที่ไม่ตั้งใจ และลด context ที่ต้องประมวล
  • ตั้ง approval ให้เหมาะกับความเสี่ยง: MCP tool ที่แก้ข้อมูลจริง (เช่น เขียนฐานข้อมูล) ควรอยู่ภายใต้ approval ที่เข้มกว่า tool อ่านอย่างเดียว ใช้ default_tools_approval_mode ตั้งค่าเริ่มต้นต่อ server ได้ (แนวคิด approval_policy/sandbox_mode โดยรวมอธิบายไว้แล้วในบทว่าด้วยการตั้งค่า Codex CLI)
  • ระวัง MCP server เป็น process ภายนอก: server ที่รันแบบ STDIO ทำงานด้วยสิทธิ์ของ process นั้นเอง ไม่ได้ถูกครอบด้วย sandbox ของ Codex เสมอไป จึงควรใช้เฉพาะ server ที่เชื่อถือได้ และอย่าเปิด default_tools_approval_mode แบบไม่ถามกับ server ที่มี side effect
  • ตั้ง timeout ให้สมเหตุผล: ใช้ startup_timeout_sec และ tool_timeout_sec กันกรณี server ค้าง โดยเฉพาะ HTTP server ปลายทางที่อาจช้าหรือหลุด
  • แยก config ตามสภาพแวดล้อม: ถ้าต้องสลับชุด MCP server ระหว่าง dev/prod ให้ใช้กลไก profile ของ Codex (ดูบทว่าด้วยการตั้งค่า) แทนการแก้ config.toml ไปมา

⚠️ ก่อนพึ่งพา MCP ใน workflow จริงหรือใน CI (ผ่าน codex exec) ให้ทดสอบว่า server เชื่อมต่อได้และ tool ทำงานถูกต้องในเครื่อง dev ก่อนเสมอ เพื่อไม่ให้ pipeline ค้างเพราะ MCP server สตาร์ทไม่ขึ้น

บทที่ 8: Codex Cloud งานแบบขนาน และการรวมกับ GitHub

บทก่อนหน้าโฟกัสที่ Codex CLI ซึ่งรันบนเครื่องเราเอง แต่พลังจริงของ Codex เผยออกมาเต็มที่เมื่อเรา "มอบหมายงาน" (delegate) ให้ Codex cloud ไปทำแทนในคลาวด์ แต่ละงานรันในคอนเทนเนอร์ sandbox แยกกันบนเซิร์ฟเวอร์ของ OpenAI ไม่กินทรัพยากรเครื่อง local ของเรา ทำให้สั่งงานหลายงานพร้อมกันแบบขนานได้ แล้วให้ agent เปิด Pull Request กลับมาให้เรารีวิว บทนี้จะพาดูตั้งแต่การเชื่อม GitHub, ตั้งค่า environment, มอบหมายงานขนาน, ไปจนถึง code review อัตโนมัติด้วย @codex ใน PR

Codex cloud คืออะไร และทำงานอย่างไร

Codex cloud คือ cloud agent ที่เข้าใช้งานได้ที่ chatgpt.com/codex (และผ่าน ChatGPT desktop app) รับงานแบบ delegate เช่น แก้บั๊ก เขียนฟีเจอร์ หรือรีวิวโค้ด แล้วไปทำงานในสภาพแวดล้อม sandbox ที่แยกเป็นอิสระต่อกัน โดยเชื่อมกับ GitHub repo ของเรา

คุณสมบัติหลักที่ทำให้ต่างจากการรันบนเครื่อง local:

ประเด็นCodex CLI (local)Codex cloud
ที่รันเครื่องเราเอง (terminal)คอนเทนเนอร์ sandbox บนคลาวด์
การแยกงานรันทีละเซสชันบนเครื่องหนึ่ง environment ต่อหนึ่ง task
งานขนานจำกัดด้วยทรัพยากรเครื่องสั่งหลายงานพร้อมกันได้ ไม่กิน resource local
รูปแบบทำงานโต้ตอบ (interactive TUI)background agent ทำงานเบื้องหลัง
ผลลัพธ์แก้ไฟล์ในโฟลเดอร์ทำงานsummary + diff แล้วเปิด Pull Request

⚠️ ข้อกำหนดเบื้องต้น: จากข้อมูลที่มี การใช้ Codex cloud ร่วมกับ GitHub ต้องมีแผน Plus/Pro/Business/Edu/Enterprise และสิทธิ์ admin ของ repo ที่จะเชื่อม รายละเอียดแผนและโควตาเปลี่ยนแปลงบ่อย ควรตรวจสอบสถานะปัจจุบันที่หน้า settings ของ Codex ก่อนเริ่ม

เชื่อม GitHub และตั้งค่า Environment

ก่อนมอบหมายงานได้ ต้องเตรียมสองอย่างคือ การเชื่อม GitHub และการสร้าง environment ที่บอก Codex ว่าโปรเจกต์นี้ต้องเซตอัปอย่างไร

ขั้นตอนโดยรวม:

  1. เข้า chatgpt.com/codex แล้ว connect GitHub พร้อม authorize repo ที่ต้องการ
  2. สร้าง cloud environment สำหรับ repo นั้น โดยกำหนดองค์ประกอบต่อไปนี้
องค์ประกอบของ Environmentใช้ทำอะไร
dependenciesแพ็กเกจ/ไลบรารีที่โปรเจกต์ต้องมีเพื่อ build และรัน
toolsเครื่องมือ/CLI ที่ต้องติดตั้งในคอนเทนเนอร์
env varsตัวแปรสภาพแวดล้อมที่โค้ดต้องใช้
secretsค่าลับ (token/key) ที่ต้องใช้ตอนรัน
setup stepsคำสั่งเตรียมสภาพแวดล้อมก่อน agent เริ่มทำงาน

การตั้ง environment ให้ถูกตั้งแต่แรกสำคัญมาก เพราะ agent จะรันคำสั่ง (เช่น ติดตั้ง dependency, รันเทสต์) ในคอนเทนเนอร์นี้ ถ้า setup ไม่ครบ งานจะล้มตั้งแต่ต้น

💡 เคล็ดลับ: วางไฟล์ AGENTS.md ที่ root ของ repo เพื่อบอก Codex เรื่อง build/test/lint และ convention ของโปรเจกต์ cloud agent อ่านไฟล์นี้เช่นเดียวกับ CLI ทำให้ผลงานตรงมาตรฐานทีมมากขึ้น (รายละเอียดโครงสร้างและลำดับชั้นของ AGENTS.md อยู่ในบทว่าด้วยการตั้งค่า AGENTS.md)

มอบหมายงาน (delegate) — เข้าได้หลายทาง

จุดเด่นของ Codex cloud คือส่งงานเข้าได้จากหลายจุด ไม่ต้องผูกกับหน้าเว็บอย่างเดียว

จุดเข้า (entry point)เหมาะกับสถานการณ์
Web dashboard (chatgpt.com/codex)สั่งงานตรง ดู task list และ diff
GitHub (PR / issues)สั่งจาก context ของ PR หรือ issue โดยตรง
Linearเชื่อมงานจาก issue tracker
Slackสั่งงานจากแชทของทีม
CLIส่งงานขึ้น cloud จาก terminal
IDE extension (VS Code/Cursor/Windsurf)delegate ขึ้น cloud ได้โดยไม่ต้องออกจาก editor

ในทุกช่องทาง หลักการเดียวกันคือ อธิบายงานให้ชัด แล้ว agent จะไปทำงานเบื้องหลัง เมื่อเสร็จจะสรุปผล (summary) พร้อม diff และเปิด Pull Request ให้ ถ้าผลยังไม่ถูกใจ ขอ follow-up ต่อในเธรดเดิมได้ Codex จะทำงานต่อจากบริบทเดิม

งานแบบขนาน (parallel tasks)

เพราะแต่ละงานได้ environment แยกเป็นของตัวเอง (หนึ่ง environment ต่อ task) และรันบนคลาวด์ เราจึงสั่งหลายงานพร้อมกันได้โดยไม่แย่งทรัพยากรกันและไม่กินเครื่อง local เช่น มอบหมายพร้อมกันสามงาน: แก้บั๊กหน้า login, เพิ่ม unit test ให้โมดูล payment, และรีแฟกเตอร์ util ตัวหนึ่ง ทั้งสามจะเดินหน้าขนานกัน แต่ละงานเปิด PR ของตัวเอง แล้วเรารีวิวทีละอันตามสะดวก

💡 เคล็ดลับ: แตกงานใหญ่เป็นงานย่อยที่เป็นอิสระต่อกัน แล้ว delegate แบบขนาน จะได้ throughput สูงกว่าการทำทีละงาน โดยเฉพาะงานที่ไม่พึ่งพาผลของกันและกัน

จาก delegate ถึง Pull Request

ภาพรวมของ flow ตั้งแต่มอบหมายงานจนได้ PR และรีวิว เป็นดังนี้

flowchart TD
    A["มอบหมายงาน (delegate)<br/>Web / GitHub / Slack / Linear / CLI / IDE"] --> B["Codex cloud สร้าง sandbox container<br/>(1 environment ต่อ 1 task)"]
    B --> C["agent ทำงาน background<br/>อ่าน AGENTS.md · รันคำสั่งใน sandbox"]
    C --> D["ได้ summary + diff"]
    D --> E{"ผลลัพธ์โอเคหรือยัง?"}
    E -->|ต้องแก้เพิ่ม| F["ขอ follow-up<br/>ในเธรดเดิม"]
    F --> C
    E -->|โอเค| G["เปิด Pull Request บน GitHub"]
    G --> H["Code review ด้วย @codex<br/>(automatic หรือ on-demand)"]
    H --> I{"มี P0/P1 ไหม?"}
    I -->|มี| J["@codex fix it<br/>แก้แล้ว push เข้า PR"]
    J --> H
    I -->|ไม่มี| K["merge PR"]

จุดสำคัญคือช่วง review ไม่ใช่ทางเดียว เราวนขอ follow-up หรือให้ Codex แก้ตาม review ได้เรื่อยๆ ก่อน merge

Code review อัตโนมัติด้วย @codex

นอกจากเขียนโค้ด Codex ยังทำหน้าที่ reviewer บน GitHub ได้ เปิดใช้งานที่ Codex settings โดย toggle Code review ต่อ repository (หรือระดับ organization) มีสองโหมด

โหมดการทำงาน
Automatic reviewsรีวิวทุก PR อัตโนมัติเมื่อเปิด/อัปเดต
On-demandพิมพ์ @codex review ใน comment ของ PR เมื่อต้องการ

เมื่อถูกเรียก Codex จะ react ด้วย emoji 👀 ก่อน แล้วจึงโพสต์ผลเป็น standard GitHub code review วิธีวิเคราะห์คือเทียบ PR diff กับ intent ของ PR แล้ว flag เฉพาะ issue ระดับ P0/P1 ที่เสี่ยงสูง เช่น security regressions, missing test coverage, documentation gaps, risky behavior changes ส่วนงาน formatting/lint เชิงกลไกปล่อยให้ CI จัดการ เพื่อลด noise

คำสั่ง @codex ใน PR comment มีความหมายต่างกันตามข้อความที่ตามมา

คำสั่งผลลัพธ์
@codex reviewขอ review หนึ่งรอบ
@codex review for security regressions, missing tests, and risky behavior changesขอ review แบบระบุประเด็นที่อยากให้เพ่ง
@codex fix it / @codex fix the P1 issueให้ Codex แก้ตามที่ review แล้ว push เข้า PR
@codex <ข้อความอื่น> (ไม่มีคำว่า review)เริ่ม cloud chat ใหม่โดยใช้ PR เป็น context เช่น @codex fix the CI failures

⚠️ ข้อควรระวัง: @codex fix it จะเริ่ม cloud chat session ที่แก้ไขและอัปเดต PR โดยอัตโนมัติ ตรวจ diff ที่มันเสนอทุกครั้งก่อน merge อย่าปล่อยผ่านเพราะ agent เขียนให้เอง

ปรับแต่งกฎรีวิวด้วย AGENTS.md

พฤติกรรมการรีวิวปรับแต่งได้โดยเพิ่ม section ## Code Review Rules ใน AGENTS.md

## Code Review Rules
- Flag any raw SQL string built with user input; use parameterized queries instead.
- Flag new public API endpoints without an auth check.
- Do not comment on formatting or import order (handled by CI).

หลักการวางกฎ:

  • กฎระดับทั้ง repo ใส่ที่ root AGENTS.md
  • กฎเฉพาะ service ใส่ใน AGENTS.md ที่ nested ใกล้โค้ดส่วนนั้น
  • กฎที่ดีควร กระชับ, ระบุพฤติกรรมที่ต้อง flag พร้อม safe alternative, scoped และ durable และ ไม่ ครอบคลุมงาน lint/format (ปล่อยให้ CI)

รัน Codex ใน CI/CD ด้วย codex-action

ถ้าต้องการฝัง Codex ลงใน pipeline (เช่น ทำ PR review bot ของทีมเอง) มี official GitHub Action คือ openai/codex-action ที่รันแบบ headless พร้อมระบบควบคุมสิทธิ์ trigger บน event pull_request แล้วโพสต์ผลผ่าน actions/github-script ได้

input หลักที่ควรรู้:

inputหน้าที่
openai-api-keyAPI key เก็บใน GitHub secret
prompt / prompt-fileคำสั่งที่ให้ Codex ทำ
permission-profileสิทธิ์การทำงาน เช่น :workspace, :read-only
safety-strategyกลยุทธ์ความปลอดภัย: drop-sudo (default), unprivileged-user, read-only, unsafe
working-directoryโฟลเดอร์ทำงาน
output-fileไฟล์รับผลลัพธ์
codex-versionpin เวอร์ชัน Codex

output หลักคือ final-message ซึ่งนำไปโพสต์เป็นคอมเมนต์บน PR ต่อได้ สำหรับงาน headless นอก Action ยังใช้ codex exec เป็นทางเลือกได้เช่นกัน (ดูรายละเอียด subcommand ในบทว่าด้วย Codex CLI)

💡 เคล็ดลับ: เริ่มจาก safety-strategy เป็น drop-sudo (ค่า default) และ permission-profile แบบ :read-only สำหรับ review bot ที่แค่อ่านและคอมเมนต์ ค่อยขยายสิทธิ์เป็น :workspace เมื่อต้องการให้ agent แก้ไขและ push จริง เพื่อลดความเสี่ยงในสภาพแวดล้อม CI ที่รันอัตโนมัติ

ชื่อ flag บางตัว รูปแบบ input และรายละเอียดของ codex exec อาจต่างกันตามเวอร์ชัน แนะนำยืนยันด้วย codex --help และหน้าเอกสารทางการ (ย้ายไป learn.chatgpt.com/docs) ก่อนนำไปใช้จริงในทีม

บทที่ 9: การทำงานอัตโนมัติและ CI/CD ด้วย codex exec

จนถึงตอนนี้เราคุยกันเรื่องการใช้ Codex แบบโต้ตอบ (interactive) ในเทอร์มินัลเป็นหลัก แต่พลังจริงของมันในทีมวิศวกรรมคือการเอาไปฝังใน pipeline ให้ทำงานเองแบบไม่มีคนนั่งเฝ้า บทนี้ว่าด้วย codex exec ซึ่งเป็นประตูสู่การทำ automation และ CI/CD

codex exec คืออะไร

codex exec คือโหมด headless / non-interactive ของ Codex CLI ต่างจากคำสั่ง codex เปล่า ๆ ที่เปิด TUI ให้พิมพ์โต้ตอบ ตรงที่ codex exec จะรับ prompt เข้าไปครั้งเดียว ทำงานจนจบ แล้วพ่นผลลัพธ์ออกทาง stdout โดยไม่มี prompt ถามกลับ จึงเหมาะกับสคริปต์, CI runner, cron job และ pre-check อัตโนมัติ

💡 มี alias สั้น ๆ ว่า codex e (ข้อมูลจากเอกสารระดับ medium confidence) แต่ในสคริปต์แนะนำเขียน codex exec เต็ม ๆ เพื่อให้อ่านง่ายและกันสับสน

รูปแบบพื้นฐานที่สุด

codex exec "อธิบายว่าไฟล์ src/server.ts ทำอะไรบ้าง แบบสรุปย่อ"

ผลลัพธ์จะออกมาที่ stdout ทำให้ redirect หรือ pipe ต่อได้ทันที

codex exec "สรุปการเปลี่ยนแปลงจาก git log 10 commit ล่าสุดเป็น changelog" > CHANGELOG_DRAFT.md

ภาพรวมของ flow แบบ automation เป็นดังนี้

flowchart LR
    A[Trigger<br/>push / PR / cron] --> B[codex exec<br/>รันแบบ headless]
    B --> C{sandbox +<br/>approval}
    C --> D[Output<br/>stdout / output-file]
    D --> E[นำไปใช้ต่อ<br/>commit / PR comment / artifact]

กำหนด sandbox และ approval แบบไม่โต้ตอบ

หัวใจของการรัน headless คือ ต้องไม่มีจังหวะที่ Codex หยุดรอถามคน เพราะใน CI ไม่มีใครกดยืนยัน ถ้า approval policy ยังเป็น on-request งานจะค้างจน timeout ดังนั้นต้องตั้งค่าให้ชัดผ่าน flag

codex exec ใช้ระบบ sandbox และ approval ชุดเดียวกับ CLI ปกติ (รายละเอียดค่าและความหมายของ sandbox_mode / approval_policy อยู่ในบทว่าด้วย sandbox และ approval mode) โดยสั่งผ่าน global flag เหล่านี้

Flagย่อค่าที่รับได้ / ความหมาย
--sandbox-sread-only / workspace-write / danger-full-access
--ask-for-approval-auntrusted / on-request / never
--model-mเลือกโมเดลที่ใช้รัน
--profile-pเลือก profile จาก config
--config-coverride ค่า config แบบ inline รายครั้ง
--cd-Cกำหนด working directory

สำหรับงาน CI คู่ที่ใช้บ่อยคือ --ask-for-approval never บวกกับ sandbox ที่แคบที่สุดเท่าที่งานต้องการ

# งานที่ต้องแก้ไฟล์ (เช่น auto-fix): ให้เขียนได้ในเวิร์กสเปซ แต่ไม่ต้องถาม
codex exec --sandbox workspace-write --ask-for-approval never \
  "แก้ error ที่ตัว linter รายงานทั้งหมด โดยไม่เปลี่ยน business logic"

# งานที่แค่อ่าน/วิเคราะห์ (เช่น review, สรุป): ล็อกเป็น read-only
codex exec --sandbox read-only \
  "ตรวจว่ามีการ log ข้อมูล secret หลุดในโฟลเดอร์ src/ หรือไม่"

อีกทางที่สะอาดกว่าสำหรับ CI คือสร้าง profile เฉพาะ (เช่น ci) ไว้ใน config แล้วเรียกด้วย --profile ci เพื่อไม่ต้องพิมพ์ flag ยาว ๆ ซ้ำทุกที่ (วิธีสร้าง profile ดูบทว่าด้วย config.toml และ profiles) หรือ override ค่าเดียวแบบชั่วคราวด้วย -c เช่น codex exec -c approval_policy='"never"' "..." (ค่าเป็น TOML string จึงต้องใส่ quote ซ้อน)

⚠️ อย่าใช้ --sandbox danger-full-access ใน pipeline ยกเว้นจำเป็นจริง ๆ การรวม danger-full-access เข้ากับ --ask-for-approval never เท่ากับปล่อยให้ agent รันอะไรก็ได้บนเครื่องโดยไม่มีการยับยั้ง เลือก read-only เป็นค่าตั้งต้น แล้วขยับขึ้นเป็น workspace-write เฉพาะ step ที่ต้องเขียนไฟล์จริง

การนำ output ไปใช้ต่อ

เพราะผลลัพธ์ออกทาง stdout การต่อยอดจึงเป็นเรื่องของ shell ล้วน ๆ redirect ลงไฟล์, pipe เข้าเครื่องมืออื่น, หรือเก็บเป็นตัวแปรใน pipeline ได้ตามปกติ

# เก็บผลเป็นไฟล์ แล้วเอาไป commit หรือแนบเป็น artifact
codex exec --sandbox read-only "สร้างเอกสาร API เป็น Markdown จากโค้ดใน src/" > docs/api.md

# ส่งผลต่อให้ขั้นถัดไปตัดสินใจ
RESULT=$(codex exec --sandbox read-only "diff นี้ปลอดภัยจะ merge ไหม ตอบ YES/NO พร้อมเหตุผลสั้น")
echo "$RESULT"

💡 ถ้าต้องการ output แบบ structured (เช่น JSON) เพื่อ parse ต่อในสคริปต์ ให้ตรวจตัวเลือกที่มีจริงในเวอร์ชันที่ติดตั้งด้วย codex exec --help ก่อน เอกสารทางการยังไม่ยืนยัน flag สำหรับ output format/JSON แบบชัดเจน จึงอย่าเดารูปแบบ flag เอง

ใช้ใน GitHub Actions

OpenAI มี official GitHub Action คือ openai/codex-action ที่ห่อ codex exec ไว้ให้เรียกใน workflow ได้สะดวก โดยจัดการเรื่อง auth และการควบคุมสิทธิ์ให้ input/output ที่สำคัญมีดังนี้

Inputหน้าที่
openai-api-keyAPI key เก็บใน GitHub secret
prompt / prompt-fileโจทย์ที่ให้ Codex ทำ (ใส่ตรง ๆ หรือชี้เป็นไฟล์)
permission-profileโปรไฟล์สิทธิ์ เช่น :workspace, :read-only
safety-strategydrop-sudo (ค่าตั้งต้น) / unprivileged-user / read-only / unsafe
working-directoryไดเรกทอรีที่ให้ทำงาน
output-fileเขียนผลลัพธ์ลงไฟล์
codex-versionปักหมุดเวอร์ชัน Codex

ส่วน output ที่ได้กลับมาคือ final-message (ข้อความสรุปสุดท้ายจาก agent) นำไปโพสต์กลับเข้า PR ผ่าน actions/github-script ได้ ตัวอย่าง workflow รีวิว PR อัตโนมัติ

name: Codex PR Review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  codex-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Codex
        id: codex
        uses: openai/codex-action@main   # แนะนำปักหมุดเป็น tag/SHA ที่ปล่อยแล้ว
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          safety-strategy: read-only
          prompt: |
            รีวิว diff ของ PR นี้ โฟกัสเฉพาะความเสี่ยงสูง:
            security regression, missing test และ behavior change ที่อันตราย
            ข้ามเรื่อง formatting/lint ที่ CI จัดการอยู่แล้ว

      - name: Comment on PR
        uses: actions/github-script@v7
        env:
          CODEX_RESULT: ${{ steps.codex.outputs.final-message }}
        with:
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: process.env.CODEX_RESULT,
            });

⚠️ ปักหมุดเวอร์ชันของ action เสมอ เปลี่ยน @main เป็น tag หรือ commit SHA ที่ปล่อยเป็นทางการ (หรือใช้ input codex-version) เพื่อกันพฤติกรรมเปลี่ยนกะทันหันและลดความเสี่ยงด้านซัพพลายเชน

💡 workflow นี้เป็นการเรียก Codex เชิงโปรแกรมใน CI ซึ่งคนละทางกับการพิมพ์ @codex review ใน comment ของ PR โดยตรง (ที่ใช้ Codex cloud) รายละเอียดของ @codex และ automatic review ดูบทว่าด้วยการรวม Codex กับ GitHub

Use cases ที่ใช้ได้จริง

1. Auto-fix lint ให้ Codex ไล่แก้ error ที่ linter รายงาน แล้ว commit กลับเข้า branch อัตโนมัติ ใช้ workspace-write เพราะต้องแก้ไฟล์จริง

codex exec --sandbox workspace-write --ask-for-approval never \
  "รัน npm run lint แล้วแก้ทุก error ที่เจอ ห้ามแก้ logic ของโปรแกรม"
git add -A && git commit -m "chore: auto-fix lint via codex" || echo "ไม่มีอะไรต้องแก้"

2. สร้างเอกสารอัตโนมัติ รันเป็น step ใน CI หรือ cron เพื่อ generate เอกสาร API/README จากโค้ดล่าสุด ใช้ read-only แล้ว redirect ผลเป็นไฟล์ (การเขียนไฟล์เกิดที่ shell ไม่ต้องเปิดสิทธิ์ให้ agent)

codex exec --sandbox read-only \
  "อ่าน public function ในโฟลเดอร์ src/ แล้วเขียนเอกสารอ้างอิงเป็น Markdown" > docs/reference.md

3. Triage issue ให้ Codex อ่าน issue ที่เพิ่งเปิด แล้วจัดหมวด (bug / feature / question) พร้อมสรุปสั้น เพื่อช่วยทีมคัดกรอง ส่งเนื้อหา issue ผ่าน environment variable ไม่ใช่ต่อ string ตรง ๆ

codex exec --sandbox read-only \
  "จัดหมวด issue ต่อไปนี้เป็น bug/feature/question พร้อมสรุป 2 บรรทัด:
$ISSUE_BODY"

⚠️ เนื้อหา issue และ PR จากภายนอกถือเป็น ข้อมูลที่ไม่น่าเชื่อถือ อาจมีข้อความพยายาม prompt-injection สั่ง agent ให้ทำสิ่งที่ไม่ควร สำหรับงาน triage/review ให้ใช้ --sandbox read-only เสมอ และอย่าให้ workflow นี้มีสิทธิ์เขียนโค้ดหรือ push จากข้อมูลที่ควบคุมไม่ได้

บทที่ 10: ศิลปะการสั่งงาน Codex อย่างมืออาชีพ (Prompting & Agentic Workflow)

เวลาเราคุยกับ chatbot ทั่วไป เราถามคำถาม—มันตอบข้อความ จบ. แต่ Codex เป็น coding agent: มันอ่านไฟล์ในโปรเจกต์จริง รันคำสั่งใน sandbox แก้โค้ด รันเทสต์ และเปิด Pull Request ได้ด้วยตัวเอง. นั่นแปลว่า prompt ของเราไม่ใช่ "คำถาม" แต่เป็น การมอบหมายงาน (brief) ให้ลูกทีมคนหนึ่งลงมือทำแทน.

หลักคิดของทั้งบทนี้จึงสรุปได้ประโยคเดียว: สั่ง Codex เหมือน brief งานให้ junior dev ที่เก่งแต่ไม่รู้ context ของทีมเรา—เขาทำตามที่บอกได้ดีมาก แต่จะเดา intent ของเราไม่ออกถ้าเราไม่บอก. ยิ่ง brief ชัด ผลงานยิ่งตรง และเรายิ่งเสียเวลาแก้ย้อนน้อยลง.

💡 กฎเหล็กก่อนเริ่ม: prompt ที่พิมพ์ในแชท override ทุกอย่าง รวมถึงคำสั่งใน AGENTS.md. ดังนั้น context ถาวร (convention, คำสั่ง build/test) ให้ฝากไว้ใน AGENTS.md ส่วนเจตนาเฉพาะงานให้ใส่ใน prompt.

หลักการที่ 1: ให้บริบทและเป้าหมายชัด (Context & Goal)

ความผิดพลาดที่พบบ่อยสุดคือสั่งลอย ๆ เช่น "ปรับปรุงโค้ดให้ดีขึ้น" หรือ "เพิ่มระบบ login หน่อย". Codex จะเดา และมักเดาไม่ตรง. แทนที่จะทำแบบนั้น ให้ประกอบ context สามชั้น:

  • ชี้ไฟล์/โฟลเดอร์ให้เจาะจง — บอกว่าโค้ดที่เกี่ยวอยู่ที่ไหน (src/routes/auth.ts, tests/) แทนที่จะปล่อยให้ agent ไล่หาเองทั้ง repo
  • ฝาก context ถาวรไว้ใน AGENTS.md — ภาพรวมโปรเจกต์, คำสั่ง build/test/lint, code style, conventions. Codex อ่านไฟล์นี้อัตโนมัติทุกเซสชัน ทำให้ไม่ต้องพิมพ์ซ้ำทุกครั้ง (รายละเอียดโครงสร้าง/ลำดับชั้นของ AGENTS.md อยู่ในบทว่าด้วย AGENTS.md)
  • ระบุเกณฑ์ความสำเร็จ (definition of done) — เช่น "เทสต์ผ่านทั้งหมด และ npm run lint ไม่มี error"

ถ้างานต้องอิงข้อมูลภาพหรือข้อมูลภายนอก มีสองเครื่องมือช่วย:

codex --image ./mockup.png   # แนบภาพ (เช่น mockup/screenshot error) เป็น context
codex --search               # เปิด web search ให้ Codex ค้นข้อมูลภายนอก

⚠️ ตรวจชื่อ flag เวอร์ชันที่ติดตั้งจริงด้วย codex --help เสมอ เพราะ flag/สลาชคอมมานด์อาจเปลี่ยนตามเวอร์ชัน CLI.

หลักการที่ 2: วางแผนก่อนลงมือ (Plan First)

สำหรับงานที่ใหญ่กว่าการแก้บรรทัดเดียว อย่าปล่อยให้ Codex พุ่งเข้าไปแก้ทันที. ให้สั่งเป็นสองจังหวะ: "เสนอแผนก่อน แล้วรอให้ฉันอนุมัติ ค่อยลงมือ". วิธีนี้เปิดโอกาสให้เราจับ misunderstanding ตั้งแต่ยังไม่มีโค้ดเปลี่ยน ซึ่งถูกกว่าการมาแก้ diff ที่ผิดทิศทั้งก้อน.

การวางแผนสัมพันธ์กับ reasoning effort ด้วย. Codex ปรับความลึกในการคิดได้ผ่าน model_reasoning_effort (ค่า minimal | low | medium | high | xhigh โดย default = medium) และมีคีย์แยกสำหรับช่วงวางแผนคือ plan_mode_reasoning_effort. หลักการง่าย ๆ:

ระดับงานreasoning effort ที่เหมาะเหตุผล
แก้เล็ก/ทำตาม instruction ตรง ๆminimal – lowเร็ว ประหยัด token, GPT-5 family ทำงานโค้ดระดับ minimal ได้ดี
งานทั่วไปในแต่ละวันmedium (default)สมดุลความเร็วกับความลึก
งานยากหลายขั้น/ต้องวางสถาปัตยกรรมhigh – xhighคิดรอบคอบขึ้น แลกกับช้าและกิน token มากกว่า

ปรับได้กลางเซสชันด้วย /model (เลือกโมเดล + reasoning effort พร้อมกัน) โดยไม่ต้องออกจากงาน. (เรื่องเลือกโมเดลและ effort เชิงลึกอยู่ในบทว่าด้วยโมเดลและ reasoning effort)

หลักการที่ 3: Scope งานให้พอดีคำ

Agent ทำงานได้ดีที่สุดกับงานที่ "ใหญ่พอจะมีคุณค่า แต่เล็กพอจะรีวิวไหว". งานที่กว้างเกิน (เช่น "รีแฟกเตอร์ทั้งโปรเจกต์") จะได้ diff มหึมาที่รีวิวไม่ทัน และ error สะสมยากตามรอย. แนวทาง:

  • แตกงานใหญ่เป็น task ย่อยที่ตรวจได้ทีละก้อน แล้ว iterate ต่อในเธรดเดิม
  • งานที่รันขนานกันได้ ให้ delegate ขึ้น Codex cloud — cloud agent รันแต่ละ task ในคอนเทนเนอร์ sandbox แยก ทำหลายงานพร้อมกันได้โดยไม่กินทรัพยากรเครื่อง local แล้วเปิด PR กลับมาให้รีวิว (รายละเอียด Codex cloud/delegation อยู่ในบทว่าด้วย Codex cloud และการรวมกับ GitHub)
  • งานซ้ำ ๆ ใน pipeline ใช้ codex exec แบบ headless (ดูบทว่าด้วย headless/CI)

💡 เกณฑ์ง่าย ๆ ในการ scope: ถ้าอธิบายงานให้เพื่อนร่วมทีมเข้าใจใน 2–3 ประโยคไม่ได้ แสดงว่างานใหญ่เกินไปสำหรับหนึ่ง prompt—ให้ซอยก่อน.

หลักการที่ 4: อ้างไฟล์/เทสต์ และทำงานแบบ TDD

จุดแข็งที่สุดของ agentic coding คือ Codex รันเทสต์เองได้ ทำให้มันมี "feedback loop" ในการตรวจงานตัวเอง. ใช้จุดนี้ให้เต็มที่ด้วยแนวทาง Test-Driven Development:

  1. สั่งให้ เขียนเทสต์ที่สะท้อนเกณฑ์ความสำเร็จก่อน (หรือชี้ไปยังเทสต์ที่ต้องทำให้ผ่าน)
  2. ให้ implement จนเทสต์เขียว
  3. ให้รันคำสั่งเทสต์/lint ที่ระบุไว้ใน AGENTS.md แล้วยืนยันผล

เพื่อให้ loop นี้ทำงานได้ ต้องมั่นใจว่า AGENTS.md ระบุคำสั่งไว้ครบ เช่น npm test, npm run lint, ขั้นตอน build. เมื่อ agent รู้ว่า "ผ่าน" หน้าตาเป็นอย่างไร มันจะแก้จนสำเร็จเองแทนที่จะส่งงานครึ่ง ๆ กลาง ๆ มาให้เรา.

หลักการที่ 5: iterate ทีละขั้น + รีวิว diff ทุกครั้ง

อย่า commit อะไรที่ยังไม่ได้อ่าน. นี่คือวินัยที่แยกมืออาชีพออกจากคนใช้ AI แบบเสี่ยงดวง. Codex มีเครื่องมือช่วยคุมสองชั้น:

ชั้นที่หนึ่ง — คุมด้วย approval + sandbox. คู่ค่าที่แนะนำสำหรับงานประจำวันคือ preset "Auto":

codex --sandbox workspace-write --ask-for-approval on-request

workspace-write ให้ agent แก้ไฟล์ในโปรเจกต์ได้แต่ไม่หลุดออกนอกขอบเขต และ on-request ทำให้มันหยุดขออนุมัติก่อนทำสิ่งที่เสี่ยง เราจึงได้เห็นก่อนมันลงมือ. (ค่าที่รับได้ทั้งหมดของ approval_policy และ sandbox_mode อยู่ในบทว่าด้วย config.toml และ approval + sandbox)

ชั้นที่สอง — รีวิว diff ก่อนปิดงาน. ในเซสชันใช้ /review เพื่อให้ Codex ตรวจ change หาปัญหา (หรือรัน codex review). บน GitHub ใช้ @codex review ซึ่งจะโฟกัสเฉพาะ issue ระดับ P0/P1 (security regression, เทสต์ที่หายไป, พฤติกรรมเสี่ยง) และปล่อยงาน formatting/lint ให้ CI. เราสามารถกำหนดกฎรีวิวเฉพาะทีมได้ด้วย section ## Code Review Rules ใน AGENTS.md.

⚠️ /review เป็นตัวช่วย ไม่ใช่ตัวแทนสายตามนุษย์. อ่าน summary + diff ที่ Codex สรุปทุกครั้งก่อน commit—โดยเฉพาะไฟล์ config, migration, และอะไรก็ตามที่แตะ auth หรือข้อมูลผู้ใช้.

หลักการที่ 6: จัดการ context อย่างรู้จังหวะ

Context window มีจำกัด และเซสชันที่ยาวเกินไปจะเริ่ม "ลืมหัว-จำหาง" หรือหลงประเด็น. บริหารด้วยเครื่องมือเหล่านี้:

  • /status — ดู config ของเซสชันปัจจุบัน (โมเดล, approval, sandbox) เพื่อเช็คว่ากำลังทำงานในโหมดที่ถูกต้อง
  • /new — เปิดแชทใหม่ให้ context สะอาด. ใช้เมื่อ เปลี่ยนไปทำงานคนละเรื่อง หรือเมื่อเซสชันเริ่มสับสน/พา agent วนลูปผิด ๆ
  • codex resume — กลับเข้าเซสชันเดิมที่บันทึกไว้ เมื่อต้องการทำงานต่อจากที่ค้าง

หลักการตัดสินใจ: งานเดียวกันแต่หลายรอบ iterate → อยู่เธรดเดิม (agent จะได้จำ context ของงานนั้น); เปลี่ยนหัวข้องาน หรือ context เริ่มรก → /new.

💡 ถ้าคุณคุ้นกับคำสั่งบีบอัด context (เช่น /compact) จากเครื่องมืออื่น ให้ตรวจว่าเวอร์ชัน Codex ที่ติดตั้งมีคำสั่งเทียบเท่าหรือไม่ด้วย /help หรือ codex --help ก่อนใช้ อย่าเดา—แล้วถ้าไม่มี ให้ใช้ /new เพื่อเริ่ม context ใหม่แทน.

สูตรสั่งงาน Codex + เชื่อมโยงกับ C-R-F-E

รวบหลักการทั้งหมดข้างบนเป็นสูตรเดียวที่จำง่าย:

[เป้าหมาย] + [บริบท: ไฟล์/เทสต์] + [ข้อจำกัด] + [วิธีทำงาน: plan → TDD → diff] + [เกณฑ์สำเร็จ]

ถ้าคุณคุ้นกับสูตร C-R-F-E ที่นักพัฒนาไทยใช้กันอยู่แล้ว สามารถ map เข้ากับการสั่ง agent ได้ตรง ๆ:

C-R-F-Eความหมายเดิมปรับใช้กับการสั่ง Codex
C — Contextบริบทชี้ไฟล์/โฟลเดอร์ที่เกี่ยว, สรุปโครงสร้าง, ฝาก convention ถาวรใน AGENTS.md, แนบภาพด้วย --image, เปิด --search เมื่อต้องข้อมูลภายนอก
R — Role / Requestบทบาท + คำขอระบุงานให้ชัดและ scope พอดี ("แก้บั๊ก X ในไฟล์ Y") ไม่ใช่คำสั่งลอย ("ทำให้ดีขึ้น")
F — Formatรูปแบบผลลัพธ์กำหนด "วิธีทำงาน": เสนอแผนก่อน, เขียนเทสต์ก่อน (TDD), ส่งผลเป็น diff, รัน lint/test ให้ผ่าน
E — Exampleตัวอย่างอ้าง pattern/โค้ดใกล้เคียงที่มีอยู่, ชี้เทสต์ที่ต้องทำให้ผ่าน, ยกตัวอย่าง input/output

ตัวอย่างเปรียบเทียบ

Prompt อ่อน (agent ต้องเดาเยอะ):

ช่วยเพิ่มระบบ login หน่อย

Prompt แข็งแรง (ครบ C-R-F-E):

เป้าหมาย: เพิ่ม endpoint POST /api/login ที่ src/routes/auth.ts
บริบท (C): ใช้ pattern เดียวกับ /api/register ในไฟล์เดียวกัน, DB helper อยู่ที่ src/db/users.ts
คำขอ (R): รับ email + password คืน JWT; ทำเฉพาะ endpoint นี้ อย่าแตะฟีเจอร์อื่น
ข้อจำกัด: ห้ามแก้ schema, ใช้ bcrypt ตัวที่มีอยู่แล้ว
วิธีทำงาน (F): เสนอแผนก่อนให้ฉันอนุมัติ → เขียนเทสต์ที่ tests/auth.test.ts ก่อน → ค่อย implement → รัน npm test ให้ผ่าน
ตัวอย่าง (E): flow และ error handling ให้เลียนแบบ /api/register
เกณฑ์สำเร็จ: เทสต์ผ่านทั้งหมด และ npm run lint ไม่มี error

ภาพรวม agentic workflow ในหนึ่งลูป

flowchart TD
    A[เขียน prompt ตามสูตร C-R-F-E] --> B[Codex เสนอแผน]
    B --> C{อนุมัติแผน?}
    C -->|ยังไม่ตรง ปรับ prompt| A
    C -->|ตกลง| D[Codex ลงมือ: แก้ไฟล์ + รันเทสต์ ใน sandbox]
    D --> E[รีวิว diff ด้วย /review]
    E --> F{ผ่านเกณฑ์สำเร็จ?}
    F -->|ต้องแก้| G[สั่ง iterate ต่อในเธรดเดิม]
    G --> D
    F -->|ผ่าน| H[commit / เปิด PR]

Checklist ก่อนกด Enter

  • เป้าหมายชัด — บอกงานเจาะจง scope พอดีคำ ไม่กว้างจนรีวิวไม่ไหว
  • บริบทครบ — ชี้ไฟล์/เทสต์ที่เกี่ยว, context ถาวรอยู่ใน AGENTS.md แล้ว
  • สั่งวางแผนก่อนงานใหญ่ — "เสนอแผนก่อน แล้วรออนุมัติ" + ตั้ง reasoning effort ให้เหมาะกับความยาก
  • มีเกณฑ์สำเร็จที่ตรวจได้ — เทสต์/lint เป็นเส้นชัย ไม่ใช่ความรู้สึก
  • โหมดปลอดภัย — workspace-write + on-request สำหรับงานประจำวัน
  • รีวิว diff ทุกครั้ง ก่อน commit—/review ช่วยได้ แต่ไม่แทนสายตาเรา
  • บริหาร context — งานเดิม iterate ในเธรดเดิม, เปลี่ยนเรื่องใช้ /new

บทที่ 11: เวิร์กโฟลว์ตัวอย่างในงานจริง (Real-World Workflows)

หลังจากบทก่อน ๆ ได้ปูพื้นเรื่องการติดตั้ง, config.toml, ระบบ approval + sandbox, การเลือกโมเดล และการรวมกับ GitHub มาแล้ว บทนี้จะพาลงสนามจริง เรารวบรวมสถานการณ์ที่วิศวกรเจอบ่อย 6 แบบ แต่ละแบบมี บริบท → prompt ตัวอย่าง → ขั้นตอนที่ Codex ทำ → ผลลัพธ์ เพื่อให้ลอกไปปรับใช้กับงานตัวเองได้ทันที

ทุกเวิร์กโฟลว์วางอยู่บนลูปการทำงานเดียวกันของ Codex ซึ่งควรจำภาพนี้ไว้เป็นแกน:

flowchart LR
    A["เขียน Prompt<br/>+ AGENTS.md"] --> B["สำรวจโค้ด<br/>(read-only)"]
    B --> C["วางแผน + เสนอ diff"]
    C --> D{"approval<br/>on-request"}
    D -->|อนุมัติ| E["แก้ไฟล์<br/>(workspace-write)"]
    E --> F["รัน test / build"]
    F -->|ไม่ผ่าน| C
    F -->|ผ่าน| G["รีวิว diff ด้วย /review"]
    G --> H["commit / เปิด PR"]

💡 คู่ preset ที่แนะนำสำหรับงานประจำวันคือ Auto preset = --sandbox workspace-write --ask-for-approval on-request ให้ Codex อ่านและแก้ไฟล์ในโปรเจกต์ได้ แต่ยังขออนุมัติก่อนลงมือในจุดสำคัญ

1. แก้บั๊กในโปรเจกต์ใหญ่ (Bug Fix)

บริบท: โค้ดเบสใหญ่ที่เราไม่ได้รู้ทุกซอกทุกมุม มีบั๊กที่ reproduce ได้แต่ยังไม่รู้ต้นตอ จุดสำคัญคือให้ Codex "สืบก่อน แก้ทีหลัง" ไม่ใช่รีบแก้แบบเดา

Prompt:

มีบั๊ก: ผู้ใช้กดปุ่ม "ส่งฟอร์ม" แล้วได้ HTTP 500 เฉพาะตอนแนบไฟล์ขนาดเกิน 5MB
ช่วยไล่หาสาเหตุจากโค้ดใน src/upload/ และ log ที่ logs/app.log
อธิบาย root cause ให้เข้าใจก่อน แล้วค่อยเสนอ diff ให้ฉันอนุมัติก่อนลงมือแก้

ขั้นตอนที่ Codex ทำ:

  1. เปิดเซสชันในไดเรกทอรีโปรเจกต์ (codex) อ่าน AGENTS.md ที่ root และในโฟลเดอร์ใกล้เคียงเพื่อเข้าใจ convention
  2. สำรวจโค้ดแบบอ่านอย่างเดียว ไล่ grep หา handler ที่เกี่ยวกับ upload และตรวจ log — ระยะนี้เหมาะกับ --sandbox read-only (หรือปรับด้วย /permissions) เพื่อกันการแก้ไฟล์โดยไม่ตั้งใจ
  3. ระบุ root cause แล้วอธิบายให้ฟัง จากนั้นเสนอ diff และหยุดรอ เพราะ approval_policy เป็น on-request
  4. เมื่อเราอนุมัติ Codex สลับมาแก้จริงภายใต้ workspace-write แล้วรันชุด test ที่เกี่ยวข้องเพื่อยืนยัน

ผลลัพธ์: ได้ patch พร้อมคำอธิบายว่าแก้อะไรและเพราะอะไร โดยผ่าน test เดิม ก่อน commit สั่ง /review ให้ Codex ตรวจ diff ของตัวเองอีกรอบเพื่อจับ regression

💡 ถ้าเจอ stack trace หรือ error จาก dependency ที่ไม่คุ้น เปิด --search ให้ Codex ค้นเว็บประกอบการวินิจฉัยได้ และสำหรับบั๊กหลายขั้นตอนที่ซับซ้อน ยกระดับด้วย /model เป็น reasoning effort high

2. Refactor / ปรับโครงสร้างโค้ด (Refactoring)

บริบท: ฟังก์ชันหรือโมดูลบวม รับผิดชอบหลายอย่างจนแก้ยาก ต้องการจัดโครงสร้างใหม่ โดยพฤติกรรมภายนอกต้องเหมือนเดิมเป๊ะ หัวใจของงานนี้คือ test suite เดิมที่ทำหน้าที่เป็นตาข่ายนิรภัย

Prompt:

Refactor ฟังก์ชัน processPayment ใน src/services/payment.js (ยาวราว 300 บรรทัด)
แยกออกเป็นฟังก์ชันย่อยตามหลัก single-responsibility ตาม code style ใน AGENTS.md
ข้อบังคับ: ห้ามเปลี่ยนพฤติกรรมภายนอก และ test suite เดิมต้องผ่านครบทุกเคสหลังแก้

ขั้นตอนที่ Codex ทำ:

  1. อ่าน AGENTS.md เพื่อดึง code style / conventions ที่โปรเจกต์กำหนด แล้วอ่านทั้งฟังก์ชันและ test ที่ครอบมันอยู่
  2. รัน test suite ก่อนแก้เพื่อจับ baseline ว่าปัจจุบันเขียวหมด
  3. แยกฟังก์ชันย่อยแบบค่อยเป็นค่อยไป ระหว่างทางถ้าติด (test แดง) จะวนกลับไปแก้ตามลูปในแผนภาพด้านบน
  4. รัน test ซ้ำจนผ่านครบ ยืนยันว่าพฤติกรรมไม่เปลี่ยน

ผลลัพธ์: โค้ดถูกจัดโครงสร้างใหม่ให้อ่านง่ายขึ้น โดย test ทั้งชุดยังเขียว ปิดท้ายด้วย /review เพื่อตรวจว่าไม่มีอะไรหลุด

⚠️ อย่า refactor โค้ดที่ยังไม่มี test คุ้มครอง — ถ้าโมดูลเป้าหมายยังไม่มีเทสต์ ให้ทำ เวิร์กโฟลว์ที่ 5 (เขียนเทสต์) ก่อน แล้วค่อย refactor ทีหลัง มิฉะนั้นจะไม่มีทางรู้ว่าพฤติกรรมเพี้ยนไปหรือไม่

3. สร้างฟีเจอร์ใหม่จาก spec (Feature from Spec)

บริบท: มีเอกสาร spec หรือ mockup อยู่แล้ว ต้องการให้ Codex สร้างฟีเจอร์ครบชุดตั้งแต่ backend ถึง UI พร้อมเทสต์ที่ครอบ acceptance criteria งานแบบนี้มักใหญ่พอที่จะ delegate ขึ้น Codex cloud ให้ทำ background แล้วเปิด PR มาให้

Prompt:

อ่าน spec ที่ docs/specs/notifications.md แล้ว implement ฟีเจอร์แจ้งเตือน in-app
ให้ครบ: endpoint, model, migration ของฐานข้อมูล และ UI component
เขียน test ครอบทุก acceptance criteria ในเอกสาร และรันให้ผ่านทั้งหมด

ขั้นตอนที่ Codex ทำ:

  1. อ่าน spec และสำรวจโครงสร้างโปรเจกต์เพื่อวางแผนว่าไฟล์ไหนต้องเพิ่ม/แก้
  2. ลงมือสร้างทีละส่วนตาม convention ใน AGENTS.md เขียน test ควบคู่ตาม acceptance criteria
  3. รัน build + test จนผ่าน
  4. ถ้าสั่งผ่าน Codex cloud (จาก web dashboard, GitHub, Linear, Slack หรือ CLI) agent จะรันในคอนเทนเนอร์ sandbox แยก แล้วเปิด Pull Request พร้อมสรุปการเปลี่ยนแปลงและ diff ให้รีวิว

ผลลัพธ์: ฟีเจอร์พร้อมเทสต์ในรูปแบบ PR ที่ทบทวนต่อได้ ขอ follow-up ในเธรดเดิมได้เลยถ้าต้องปรับ

💡 ถ้า spec เป็นภาพ mockup ให้แนบเป็น context ด้วย flag --image เพื่อให้ Codex เห็นดีไซน์ที่ต้องทำตาม การมอบงานใหญ่ให้ cloud agent ยังช่วยให้เครื่อง local ว่าง และรันได้หลาย task ขนานกัน

4. Migration / อัปเกรด framework หรือ dependency (Migration)

บริบท: ต้องยกเวอร์ชัน framework หรือไลบรารีข้าม major version ซึ่งมี breaking changes กระจายทั่วโค้ดเบส งานลักษณะนี้ยาว ซ้ำซาก และได้ประโยชน์จาก reasoning effort สูงกับการค้นข้อมูล breaking changes

Prompt:

อัปเกรด dependency <ชื่อไลบรารี> จาก v18 เป็น v19 ทั้งโปรเจกต์
ค้นหา breaking changes ที่เกี่ยวข้อง แล้วแก้โค้ดทุกจุดที่ได้รับผลกระทบ
รัน build + test ให้ผ่าน และสรุปรายการการเปลี่ยนแปลงทั้งหมดที่ทำ

ขั้นตอนที่ Codex ทำ:

  1. เปิด --search เพื่อค้น release notes / migration guide ของเวอร์ชันใหม่
  2. อัปเดตเวอร์ชันใน manifest แล้วไล่แก้ API ที่เปลี่ยนทีละจุด วนลูปแก้–รัน–แก้จนไม่มี error
  3. รัน build และ test suite เต็มเพื่อยืนยันว่าไม่มีอะไรพัง
  4. สรุปการเปลี่ยนแปลงเป็นรายการให้ตรวจทาน

ผลลัพธ์: โปรเจกต์ทำงานบนเวอร์ชันใหม่ โดย build/test ผ่าน พร้อมสรุปสิ่งที่แตะ

💡 งาน migration ยาว ๆ เหมาะกับ reasoning effort high หรือ xhigh (ปรับผ่าน /model หรือ model_reasoning_effort ใน config.toml) และเหมาะกับการ delegate ขึ้น Codex cloud ที่รัน background ได้ต่อเนื่อง นอกจากนี้ยัง wrap เป็นขั้นใน CI ด้วย codex exec (headless) ได้

5. เขียนชุดเทสต์ให้โค้ดเดิม (Test Coverage)

บริบท: โค้ด legacy ที่ทำงานได้แต่ไม่มีเทสต์ ทำให้แก้อะไรก็เสียว ต้องการเติม coverage โดยใช้ test framework เดียวกับที่โปรเจกต์ใช้อยู่

Prompt:

โมดูล src/utils/date.js ยังไม่มี test เลย
เขียน unit test ครอบทุกฟังก์ชัน public พร้อม edge case (timezone, leap year, input ที่ไม่ถูกต้อง)
ใช้ test framework เดียวกับที่โปรเจกต์ใช้อยู่ และรันให้ผ่านทั้งหมด

ขั้นตอนที่ Codex ทำ:

  1. อ่านโมดูลเป้าหมายเพื่อเข้าใจ behavior จริงของแต่ละฟังก์ชัน และตรวจจาก AGENTS.md / โครงสร้างโปรเจกต์ว่าใช้ test framework อะไร รันเทสต์ด้วยคำสั่งไหน
  2. เขียน test ครอบ happy path และ edge case
  3. รันชุดเทสต์ ถ้ามีเคสแดงจะวนกลับไปปรับจนเขียว

ผลลัพธ์: ได้ test suite ใหม่ที่รันผ่าน กลายเป็นตาข่ายนิรภัยสำหรับงาน refactor หรือ migration รอบถัดไป

💡 ระบุคำสั่งรันเทสต์/lint ไว้ใน AGENTS.md ตั้งแต่แรก (เช่น "รัน npm run lint ก่อนเปิด PR") จะช่วยให้ Codex เลือกเครื่องมือและคำสั่งได้ถูกโดยไม่ต้องเดา และเมื่อ workflow นิ่งแล้วสามารถนำไปรันเป็น pre-check อัตโนมัติใน CI ผ่าน codex exec

6. รีวิว Pull Request (Code Review)

บริบท: มี PR รอรีวิว ต้องการให้ Codex ช่วยจับความเสี่ยงระดับสูงก่อนเพื่อนร่วมทีมลงมือ ผ่านการรวมกับ GitHub

Prompt (พิมพ์เป็น comment ใน PR):

@codex review for security regressions, missing tests, and risky behavior changes

ขั้นตอนที่ Codex ทำ:

  1. Codex react ด้วย emoji 👀 เพื่อบอกว่ารับงานแล้ว
  2. วิเคราะห์ diff ของ PR เทียบกับ intent ของ PR โดยโฟกัสเฉพาะ issue ระดับ P0/P1 (เช่น security regressions, missing test coverage, documentation gaps, พฤติกรรมที่เสี่ยงเปลี่ยน) และปล่อยงาน formatting/lint ให้ CI จัดการ
  3. โพสต์ผลเป็น standard GitHub code review
  4. ถ้าต้องการให้แก้ต่อ พิมพ์ @codex fix the P1 issue หรือ @codex fix it แล้ว Codex จะเริ่ม cloud chat แก้ไขและ push เข้า PR ให้ (พิมพ์ @codex ตามด้วยอย่างอื่นที่ไม่ใช่ review เช่น @codex fix the CI failures จะเปิด cloud chat โดยใช้ PR เป็น context)

ผลลัพธ์: ได้รีวิวที่เน้นความเสี่ยงจริง ลด noise จาก lint และเลือกให้ Codex แก้ตามได้ในที่เดียว

💡 ปรับพฤติกรรมรีวิวได้ด้วยการเพิ่มหัวข้อ ## Code Review Rules ใน AGENTS.md — กฎระดับ repo วางที่ root, กฎเฉพาะ service วางใน AGENTS.md ที่ nested ใกล้โค้ดนั้น และเปิด Automatic reviews ใน Codex settings เพื่อให้รีวิวทุก PR อัตโนมัติ (รายละเอียดการตั้งค่าอยู่ในบทว่าด้วยการรวมกับ GitHub) ก่อน push ยังตรวจ diff ในเครื่องล่วงหน้าได้ด้วย slash command /review

สรุป: เลือก surface และ preset ให้เหมาะกับงาน

เวิร์กโฟลว์surface ที่เหมาะsandbox + approvalreasoning effort
แก้บั๊กCLI (interactive)read-only ตอนสืบ → workspace-write ตอนแก้high ถ้าซับซ้อน
RefactorCLI (interactive)workspace-write + on-requestmedium
ฟีเจอร์จาก specCLI หรือ Codex cloud (เปิด PR)workspace-write + on-requestmedium–high
MigrationCodex cloud / codex exec (CI)workspace-write + on-requesthigh–xhigh + --search
เขียนเทสต์CLI หรือ codex exec (CI)workspace-write + on-requestminimal–medium
รีวิว PRGitHub (@codex review)(จัดการฝั่ง cloud)—

⚠️ ค่า flag, subcommand และชื่อโมเดล/เวอร์ชันเปลี่ยนได้ตามรุ่นของ Codex CLI ที่ติดตั้ง ก่อนนำ prompt และคำสั่งในบทนี้ไปใช้จริง ควรยืนยันด้วย codex --help และ /status ในเครื่องของคุณเสมอ

ทั้ง 6 เวิร์กโฟลว์ใช้กลไกเดียวกันหมด ต่างกันแค่การจูน sandbox, approval, reasoning effort และเลือก surface (CLI / cloud / GitHub) ให้เข้ากับขนาดและความเสี่ยงของงาน เมื่อจับลูป "สำรวจ → วางแผน → อนุมัติ → แก้ → ทดสอบ → รีวิว" ได้แล้ว จะปรับใช้กับสถานการณ์อื่นนอกเหนือจากนี้ได้เอง

บทที่ 12: คลัง Prompt สำเร็จรูป (Prompt Cookbook)

Codex เก่งแค่ไหนขึ้นกับโจทย์ที่เราป้อนให้ บทนี้รวมสูตร prompt พร้อมใช้สำหรับงานวิศวกรรมที่เจอบ่อยที่สุด ทุกสูตรออกแบบให้ copy ไปปรับ <placeholder> แล้วใช้งานได้ทันที ทั้งในเซสชัน interactive (codex) และแบบ headless (codex exec)

กายวิภาคของ prompt ที่ดี

ก่อนดูสูตร ให้จำโครงสร้าง 4 ส่วนนี้ไว้ prompt ที่ได้ผลเกือบทั้งหมดมีครบทั้ง 4 ส่วน

ส่วนทำหน้าที่อะไรตัวอย่าง
Contextให้ข้อมูลตั้งต้นerror log, path ของไฟล์, เวอร์ชัน, ขั้นตอน reproduce
Taskบอกงานเป็นขั้นเป็นตอน"1. reproduce ก่อน 2. หา root cause 3. แก้..."
Constraintsกันพฤติกรรมไม่พึงประสงค์"minimal diff", "อย่าแก้ test เพื่อให้ผ่าน"
Output formatกำหนดรูปแบบผลลัพธ์"แยกเป็น P0/P1/P2", "รายงานตัวเลข before/after"

💡 อย่าทำงานให้ prompt แบกทุกอย่าง คำสั่ง build/test/lint และ convention ประจำโปรเจกต์ควรเขียนลง AGENTS.md ครั้งเดียว (ดูบทว่าด้วย AGENTS.md) แล้ว Codex จะรู้เองทุกเซสชัน ทำให้ prompt สั้นลงและผลแม่นขึ้นมาก

เลือกโหมดให้ตรงกับสูตร

แต่ละสูตรเหมาะกับ sandbox_mode และ approval ต่างกัน แผนภาพนี้ช่วยเลือกก่อนเริ่ม (รายละเอียด mode อยู่ในบทว่าด้วย sandbox และ approval)

flowchart TD
  A[เลือกงานที่จะทำ] --> B{แก้ไฟล์หรือไม่?}
  B -->|อ่านอย่างเดียว| C["read-only<br/>review, security audit, explain codebase"]
  B -->|ต้องเขียนไฟล์| D["workspace-write + on-request<br/>bug fix, tests, docs, perf, upgrade"]
  A --> E{อยู่บน GitHub PR?}
  E -->|ใช่| F["@codex review / @codex fix<br/>หรือ delegate ขึ้น Codex cloud"]
ประเภทงานsandbox_mode แนะนำmodel_reasoning_effort แนะนำ
Review / Security audit / Explainread-onlyhigh (หรือ xhigh ถ้าโค้ดซับซ้อน)
Bug fix / Dependency upgradeworkspace-write + on-requesthigh
สร้าง test / เอกสาร / commit messageworkspace-write + on-requestmedium
Performance tuningworkspace-write + on-requesthigh

สูตรที่ 1: แก้บั๊กเบ็ดเสร็จ (End-to-end bug fix)

เมื่อไรใช้: มี bug report, error หรือ failing test และต้องการให้ Codex ตามหาสาเหตุจริง แก้ และยืนยันว่าหายจบในรอบเดียว

บั๊ก: <อธิบายอาการ + ขั้นตอน reproduce + error/stack trace ที่เจอ>
Expected: <พฤติกรรมที่ควรจะเป็น>

ช่วยแก้แบบครบวงจร:
1. reproduce บั๊กก่อน (เขียน failing test หรือรันคำสั่งที่ทำให้เกิดอาการ)
2. หา root cause จริง อย่าแก้แค่อาการ (symptom) — อธิบายสาเหตุให้ฟังก่อนลงมือแก้
3. แก้ให้น้อยที่สุดเท่าที่จำเป็น (minimal diff) อย่ารื้อโครงสร้างเกินขอบเขตบั๊กนี้
4. รัน test/lint ที่เกี่ยวข้องให้ผ่าน และยืนยันว่า failing test เดิมกลับมา pass
5. สรุปว่าแก้อะไรไป และมี edge case ไหนที่ยังต้องเฝ้าระวัง

💡 ถ้าอาการเป็นภาพ (เช่น UI เพี้ยน หรือ error บนหน้าจอ) แนบภาพเป็น context ด้วย flag --image ได้เลย

สูตรที่ 2: Code review ทั้ง repo

เมื่อไรใช้: อยากได้มุมมองรวมทั้งโปรเจกต์ก่อน merge ใหญ่ หรือเพิ่งรับช่วง codebase ต่อจากคนอื่น (ต่างจากการรีวิว diff รอบเดียวที่ใช้ /review — ดูสูตรที่ 9)

ทำ code review ทั้งโปรเจกต์นี้ในโหมดอ่านอย่างเดียว (อย่าแก้ไฟล์)
โฟกัสตามลำดับความสำคัญ:
1. ช่องโหว่ security และการจัดการ secret/credential
2. บั๊กเชิง correctness และ error handling ที่ขาดหาย
3. race condition / resource leak / ปัญหา concurrency
4. หนี้เทคนิคเชิงโครงสร้าง (tight coupling, code duplication)

รูปแบบผลลัพธ์: จัดกลุ่มเป็น P0 (ต้องแก้ทันที) / P1 (ควรแก้) / P2 (ปรับปรุงได้)
แต่ละข้อระบุ path:line, ปัญหาคืออะไร, ทำไมถึงเสี่ยง, และแนวทางแก้ที่ปลอดภัย
ข้ามเรื่อง formatting/lint ที่ CI จับได้อยู่แล้ว

💡 ตั้ง sandbox_mode = "read-only" เพื่อการันตีว่า Codex จะไม่แตะไฟล์ระหว่างรีวิว และดันไป reasoning effort ระดับ high เพื่อให้เห็นภาพเชิงสถาปัตยกรรม

สูตรที่ 3: สร้างเทสต์ (Generate tests)

เมื่อไรใช้: coverage ต่ำ, โมดูลยังไม่มีเทสต์ หรือกำลังจะ refactor และต้องมี test เป็นตาข่ายกันพลาดก่อน

เขียน unit test ให้ <path/to/module>
- ใช้ test framework และ convention เดิมของโปรเจกต์ (ดูตัวอย่างจากไฟล์ test ที่มีอยู่)
- ครอบคลุม: happy path, edge case (empty/null/boundary) และ error path
- อย่า test รายละเอียด implementation ภายใน ให้ test ที่ behavior/สัญญาของ public API
- mock dependency ภายนอก (network, DB, filesystem) อย่าเรียกของจริง
- รัน test ที่เขียนให้ผ่านจริงก่อนจบงาน

สำคัญ: ถ้าเจอบั๊กระหว่างเขียน test ให้รายงาน อย่าแอบแก้โค้ด production
เพียงเพื่อให้ test ผ่าน

⚠️ บรรทัดสุดท้ายสำคัญมาก ถ้าไม่กำกับไว้ agent อาจ "แก้โค้ดให้ตรงกับผลที่ผิด" เพื่อให้ test เขียว ทำให้บั๊กถูกกลบแทนที่จะถูกเปิดเผย

สูตรที่ 4: สร้างเอกสาร (Generate documentation)

เมื่อไรใช้: README ล้าสมัย, โมดูลไม่มี docstring หรือกำลังเตรียม onboarding คนใหม่

สร้าง/อัปเดตเอกสารสำหรับ <ขอบเขต เช่น โมดูล auth หรือทั้ง repo>
1. อัปเดต README: จุดประสงค์โปรเจกต์, prerequisite, วิธีติดตั้ง, วิธีรัน dev, วิธีรัน test
2. เพิ่ม docstring/comment ให้ public function/class ที่ยังไม่มี
   (ระบุ input/output และ error ที่อาจ throw)
3. ถ้ามี API ให้ทำตารางสรุป endpoint และพารามิเตอร์

เงื่อนไข: อ้างอิงจากโค้ดจริงเท่านั้น ห้ามเดา behavior ที่ไม่มีในโค้ด
ถ้าไม่แน่ใจให้ใส่ TODO ไว้แทนการแต่งเรื่อง

💡 อย่าสับสนระหว่าง README.md (สำหรับมนุษย์) กับ AGENTS.md (คำสั่งสำหรับ agent) — คนละไฟล์ คนละผู้อ่าน สูตรนี้เขียน README ให้คน ส่วน AGENTS.md สร้างด้วย /init (ดูสูตรที่ 8)

สูตรที่ 5: ปรับ Performance

เมื่อไรใช้: endpoint ช้า, function ขึ้นมาร้อนใน profiler หรือ query กินเวลาเกินควร

โปรไฟล์และปรับ performance ของ <ฟังก์ชัน/endpoint/หน้าจอ>
1. วัดก่อน: หา bottleneck จริงด้วยการวัด (benchmark/profiler/timing log)
   อย่าเดาว่าตรงไหนช้า
2. เสนอแนวทางแก้เรียงตาม impact เทียบกับความเสี่ยง บอก trade-off ของแต่ละทาง
3. ลงมือแก้เฉพาะที่คุ้ม โดยห้ามเปลี่ยน behavior ที่ผู้ใช้เห็น
   (ต้องผ่าน test เดิมทั้งหมด)
4. วัดหลังแก้ แล้วรายงานเป็นตัวเลข before/after

จุดที่ควรตรวจ: N+1 query, allocation ใน loop ร้อน, งานซ้ำที่ cache ได้,
และ I/O แบบ sync ที่ควรทำเป็น batch/async

⚠️ การจูน performance เสี่ยงต่อ regression เสมอ ยืนยันว่ามี test ครอบคลุม behavior เดิมก่อนเริ่ม ถ้ายังไม่มี ให้รันสูตรที่ 3 ก่อน

สูตรที่ 6: Security audit

เมื่อไรใช้: ก่อน release, มีโค้ดจัดการ input จากภายนอก หรือมีส่วน auth/payment ที่ความเสี่ยงสูง

ทำ security audit โค้ดเบสนี้แบบอ่านอย่างเดียว (อย่าแก้ไฟล์)
เน้นช่องโหว่ที่ใช้โจมตีได้จริง:
- injection (SQL / command / template), XSS, path traversal, SSRF
- authentication/authorization ที่พลาด (missing check, IDOR)
- secret/credential/key ที่ hardcode หรือถูก log ออกมา
- input จากภายนอกที่ขาดการ validate/sanitize
- dependency ที่รู้อยู่แล้วว่ามีช่องโหว่

รายงานแยกความรุนแรง (critical/high/medium) แต่ละข้อระบุ path:line,
attack scenario ที่เป็นรูปธรรม, และวิธีแก้
รอบนี้ยังไม่ต้องแก้โค้ด ให้เสนอเป็นรายการก่อน

⚠️ การ audit ด้วย LLM เป็นด่านแรกที่คุ้มค่า แต่ไม่แทน pentest หรือเครื่องมือ SAST มืออาชีพ ใช้เป็นตัวเสริม อย่าใช้เป็นหลักฐานความปลอดภัยเพียงอย่างเดียว

สูตรที่ 7: อัปเกรด Dependency

เมื่อไรใช้: ขยับเวอร์ชัน major/minor, ปิดช่องโหว่ที่มาจาก dependency หรือปลด API ที่ deprecated

อัปเกรด <ชื่อ dependency> จาก <เวอร์ชันเดิม> เป็น <เวอร์ชันเป้าหมาย>
1. อ่าน changelog/migration guide ของเวอร์ชันเป้าหมาย
   สรุป breaking change ที่กระทบเราให้ฟังก่อน
2. อัปเดต manifest/lockfile ให้ถูกต้องตาม package manager ของโปรเจกต์
3. แก้โค้ดที่เรียก API ที่เปลี่ยน/ถูกลบ ให้ครบทุกจุดที่ใช้งาน
4. รัน build + test ทั้งชุด แก้จนผ่าน
5. สรุปไฟล์ที่แก้ และจุดที่ควร verify ด้วยมือ (เช่น behavior ที่ test ยังไม่ครอบคลุม)

💡 ถ้าต้องอ่าน changelog ออนไลน์ เปิด web search ด้วย flag --search งานประเภทนี้ยังเหมาะจะ delegate ขึ้น Codex cloud (รันใน container แยก แล้วเปิด Pull Request มาให้รีวิว) เพราะกินเวลานานและไม่ควรบล็อกเครื่อง local — ดูสูตรที่ 10

สูตรที่ 8: อธิบาย Codebase

เมื่อไรใช้: เพิ่งรับช่วงโปรเจกต์, onboarding เข้าทีม หรือก่อนแก้ของในส่วนที่ยังไม่คุ้น

อธิบายโค้ดเบสนี้ให้คนที่เพิ่งเข้าทีมเข้าใจ (โหมดอ่านอย่างเดียว):
1. โปรเจกต์นี้ทำอะไร และสถาปัตยกรรมภาพรวมเป็นอย่างไร (layer/service หลัก)
2. entry point อยู่ที่ไหน และ request/ข้อมูลไหลอย่างไรตั้งแต่ต้นจนจบ
3. โมดูลสำคัญมีอะไรบ้าง แต่ละอันรับผิดชอบอะไร
4. ข้อมูล/สถานะเก็บที่ไหน (DB, cache, external service)
5. จุดที่ควรระวังเป็นพิเศษ (โค้ดซับซ้อน/เปราะ, TODO/FIXME)

ยกตัวอย่างอ้างอิง path:line จริงประกอบ อย่าอธิบายแบบลอย ๆ

💡 พอเข้าใจภาพรวมแล้ว ใช้ /init ให้ Codex สแกน repo แล้วสร้างไฟล์ AGENTS.md scaffold เพื่อบันทึกความเข้าใจไว้ให้ทุกเซสชันถัดไป ไม่ต้องอธิบายซ้ำ

สูตรที่ 9: เขียน Commit message / PR description

เมื่อไรใช้: แก้เสร็จแล้ว กำลังจะ commit หรือเปิด PR และอยากได้ข้อความที่สื่อ "ทำไม" ไม่ใช่แค่ "อะไร"

ดู diff ที่ค้างอยู่ (staged + unstaged) แล้วช่วย:
1. เขียน commit message แบบ Conventional Commits:
   หัวข้อ <type>(<scope>): <สรุปสั้น> ไม่เกิน ~72 ตัวอักษร
   ตามด้วยเนื้อความอธิบาย "ทำไม" ที่แก้ (ไม่ใช่แค่ "อะไร")
2. เขียน PR description: สรุปการเปลี่ยนแปลง, เหตุผล/บริบท,
   วิธีทดสอบ (how to test), และความเสี่ยง/จุดที่ต้องรีวิวเป็นพิเศษ

อ้างอิงเฉพาะสิ่งที่อยู่ใน diff จริง อย่าใส่สิ่งที่ไม่ได้แก้

💡 ก่อน commit ใช้ /review ในเซสชันเพื่อให้ Codex ตรวจ diff หา issue ได้อีกชั้น (นอกจากนี้ยังมี subcommand codex review — แนะนำเช็ครูปแบบใช้งานที่แน่นอนด้วย codex --help ก่อน)

สูตรที่ 10: มอบงานให้ Codex บน GitHub / Cloud

เมื่อไรใช้: งานอยู่บน Pull Request อยู่แล้ว, ต้องการ review อัตโนมัติ หรือมีงานยาว/ทำขนานหลายชิ้นที่อยากให้รันแบบ background

พิมพ์ใน comment ของ PR:

@codex review for security regressions, missing tests, and risky behavior changes

Codex จะ react ด้วย 👀 แล้วโพสต์รีวิวกลับมา โดยโฟกัสเฉพาะ issue ระดับ P0/P1 (เช่น security regression, missing test, risky behavior change) และปล่อยงาน formatting/lint ให้ CI จัดการ จากนั้นสั่งให้แก้ต่อได้เลย:

@codex fix the P1 issue you flagged, then update this PR
คำสั่งใน PRCodex ทำอะไร
@codex reviewรีวิว PR หนึ่งรอบ แล้วโพสต์เป็น GitHub review
@codex fix it / @codex fix the P1 issueแก้แล้ว push เข้า PR ให้
@codex <ข้อความอื่น>เริ่ม cloud chat ใหม่โดยใช้ PR เป็น context (เช่น @codex fix the CI failures)

💡 อยากปรับให้ review ตรงกับมาตรฐานทีม? เพิ่มหัวข้อ ## Code Review Rules ใน AGENTS.md — กฎระดับ repo ใส่ที่ root ส่วนกฎเฉพาะ service ใส่ในไฟล์ AGENTS.md ที่ nested ใกล้โค้ดนั้น (ดูรายละเอียดในบทว่าด้วย GitHub integration)

บทที่ 13: เปรียบเทียบ Codex กับ Claude Code, Cursor และ Google Antigravity

ตลาดเครื่องมือ agentic software engineering กลางปี 2026 มีผู้เล่นหลักหลายค่าย แต่ละตัวมีปรัชญาการออกแบบต่างกัน บทนี้เปรียบเทียบ OpenAI Codex กับ Claude Code, Cursor และ Google Antigravity อย่างเป็นกลาง เพื่อช่วยให้ทีมเลือกใช้ให้เหมาะกับงาน และเห็นวิธีใช้หลายตัวร่วมกันแบบเสริมพลังกัน

⚠️ ข้อมูลของ Codex ในบทนี้อ้างอิงจาก research ของหนังสือเล่มนี้โดยตรง ส่วนข้อมูลของ คู่แข่ง เป็นการวางตำแหน่ง (positioning) ระดับภาพรวม รายละเอียดเชิงลึก (โมเดลที่รองรับ, ระบบสิทธิ์, ราคาต่อ tier) ของแต่ละค่ายเปลี่ยนเร็วมาก ควรยืนยันกับเว็บทางการของแต่ละผลิตภัณฑ์ก่อนตัดสินใจ

ภาพรวมการวางตำแหน่ง

จุดต่างที่สำคัญที่สุดคือ surface หลักที่แต่ละตัวยึด Codex เป็นตัวเดียวที่กระจายตัวครบทุก surface (CLI + cloud + IDE extension + GitHub) โดยแชร์บัญชีและ context เดียวกัน

graph TD
    A["งาน software engineering<br/>ด้วย AI agent"] --> B["Terminal-centric"]
    A --> C["IDE-centric"]
    A --> D["Cloud / Multi-agent"]
    B --> B1["Codex CLI"]
    B --> B2["Claude Code"]
    C --> C1["Cursor"]
    C --> C2["Codex IDE extension"]
    D --> D1["Codex cloud + GitHub (@codex)"]
    D --> D2["Google Antigravity"]

ตารางเปรียบเทียบ

มิติOpenAI CodexClaude CodeCursorGoogle Antigravity
โมเดลเบื้องหลังโมเดล OpenAI (ตระกูล GPT-5 / gpt-5-codex; กลางปี 2026 เอกสารทางการแสดงตระกูล GPT-5.6 Sol/Terra/Luna — ควรยืนยันชื่อรุ่น) ล็อกกับค่าย OpenAIโมเดล Anthropic (ตระกูล Claude) ล็อกกับค่าย Anthropicผูกกับ IDE เป็นหลัก (รองรับหลายโมเดล — ยืนยันกับเว็บทางการ)โมเดลของ Google (ยืนยันกับเว็บทางการ)
Surfaces หลักCLI (Rust, open source), Codex cloud ใน ChatGPT, IDE extension (VS Code/Cursor/Windsurf), GitHub integration — แชร์บัญชี/context ทุก surfaceTerminal agent เชิงลึกเป็นหลักIDE รูปแบบ VS Code fork เป็นหลักเน้น multi-agent ทำงานขนานหลายงาน (รายละเอียด surface นอกขอบเขต research)
ราคา/แผนเริ่มต้นผูกกับแผน ChatGPT: Free, Go, Plus ($20/เดือน), Pro (~$100–200), Business, Enterprisetier จ่ายเงินเริ่มต้น ~$20/เดือน~$20/เดือนมี free public preview สำหรับ individual
Sandbox / Approvalสองมิติแยกกัน: sandbox_mode (read-only / workspace-write / danger-full-access) + approval_policy (untrusted / on-request / never)มีระบบ permission/approval ของตัวเอง (รายละเอียดต่างกัน — นอกขอบเขต research นี้)มีระบบสิทธิ์ของตัวเอง (นอกขอบเขต research)มีระบบของตัวเอง (นอกขอบเขต research)
ไฟล์คำสั่งโปรเจกต์AGENTS.md (มาตรฐานเปิด)CLAUDE.mdรองรับ AGENTS.md (มาตรฐานเปิด)ยืนยันกับเว็บทางการ
จุดเด่นecosystem หลาย surface, cloud delegation + parallel tasks, GitHub PR review เน้น P0/P1, CLI open source, codex exec headless, MCP, plugin เรียกข้ามเครื่องมือterminal agent เชิงลึก workflow แบบ hands-onประสบการณ์แก้โค้ดใน IDE เต็มรูปรันงานหลาย agent ขนานกัน + ทดลองฟรี
จุดสังเกต/ข้อจำกัดล็อกกับ OpenAI/ChatGPT; cloud + GitHub ต้องแผน Plus ขึ้นไปล็อกกับ Anthropic; terminal-centric อาจไม่ถูกจริตสายชอบ IDEรายละเอียด sandbox/ราคาต่อ tier นอกขอบเขต researchยังเป็น preview รายละเอียดยังเปลี่ยนได้

💡 จุดที่ Codex ต่างจากคนอื่นชัดที่สุดคือ ความครบของ surface: ตัวเดียวกันทำงานได้ทั้งบนเทอร์มินัล, ในคลาวด์แบบ background, ใน IDE และบน GitHub โดยใช้บัญชี/ไฟล์ตั้งค่า (~/.codex/config.toml, AGENTS.md) ชุดเดียว รายละเอียดแต่ละ surface ดูในบทว่าด้วย Codex CLI, Codex cloud และการรวมกับ GitHub

เมื่อไรควรใช้ตัวไหน

การเลือกไม่ได้ขึ้นกับ "ตัวไหนเก่งกว่า" แต่ขึ้นกับ ecosystem ที่ทีมอยู่ และรูปแบบงานเป็นหลัก

สถานการณ์ตัวเลือกที่เหมาะเหตุผล
ทีมอยู่ใน ecosystem OpenAI/ChatGPT อยู่แล้วCodexใช้บัญชี ChatGPT เดิม รวม CLI + cloud + GitHub ในบัญชีเดียว
อยากส่งงานให้ agent รัน background แล้วเปิด PR เองCodex cloudรันในคอนเทนเนอร์ sandbox แยกต่อ task ทำงานขนานได้
อยากได้ code review อัตโนมัติบน PR ที่โฟกัสความเสี่ยงสูงCodex GitHub (@codex)flag เฉพาะ P0/P1 (security, missing tests, risky changes) ปล่อย lint ให้ CI
งาน CI/CD, cron, pre-check headlessCodex codex execnon-interactive รันในสคริปต์/pipeline ได้
ชอบทำงาน agentic เชิงลึกบนเทอร์มินัล และอยู่ค่าย AnthropicClaude Codeterminal agent เชิงลึกผูกกับโมเดล Claude
ต้องการแก้โค้ดในบรรยากาศ IDE เต็มรูปแบบCursorAI ฝังใน editor แบบ VS Code
อยากทดลองรันหลาย agent ขนานกันแบบไม่มีค่าใช้จ่ายเริ่มต้นGoogle Antigravityเน้น multi-agent + มี free public preview

💡 ถ้ายังไม่แน่ใจ ให้เริ่มจากตัวที่เข้ากับ ecosystem และวิธีทำงานปัจจุบันของทีมก่อน (บัญชีที่มี, editor ที่ใช้, โมเดลที่ไว้ใจ) แล้วค่อยเสริมตัวอื่นเข้ามาเฉพาะงานที่มันเด่นจริง

การใช้หลายตัวร่วมกัน

เครื่องมือเหล่านี้ไม่จำเป็นต้องเลือกอย่างใดอย่างหนึ่ง กลางปี 2026 มีสองกลไกที่ทำให้ใช้ร่วมกันได้ราบรื่น

1. AGENTS.md เป็นมาตรฐานเปิดข้ามเครื่องมือ

AGENTS.md ไม่ได้ผูกกับ Codex ตัวเดียว แต่เป็นฟอร์แมตเปิดที่หลายเครื่องมือใช้ร่วมกัน (เช่น Cursor, Copilot, Gemini CLI, Windsurf) หมายความว่าเขียนคำสั่งโปรเจกต์ไฟล์เดียวแล้วใช้ได้กับหลาย agent — ลดงานซ้ำและทำให้ทีมที่ใช้เครื่องมือคละกันยังคุมพฤติกรรม agent ให้สอดคล้องได้ (รายละเอียดโครงสร้าง/ลำดับชั้น AGENTS.md ดูในบทว่าด้วยการตั้งค่า AGENTS.md)

2. เรียก Codex จากภายใน Claude Code ด้วย official plugin

OpenAI มี plugin ทางการ openai/codex-plugin-cc ให้เรียก Codex ได้จากภายใน Claude Code เพื่อ review หรือ delegate งาน — เป็นตัวอย่างรูปแบบ "agent หนึ่งเขียน อีก agent หนึ่งรีวิว" ที่ใช้ต่างค่ายกันได้

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

คำสั่งที่ใช้ได้หลังติดตั้ง เช่น /codex:review, /codex:adversarial-review (รีวิวแบบท้าทายหาจุดอ่อน), /codex:rescue (delegate งาน), /codex:transfer (thread Codex แบบต่อเนื่อง), และ /codex:status / /codex:result / /codex:cancel สำหรับติดตามงาน รองรับ flags เช่น --background, --wait, --base <ref>

⚠️ plugin นี้ต้องมี ChatGPT subscription หรือ API key และ Node.js เวอร์ชัน 18.18 ขึ้นไป และรายชื่อคำสั่ง/flags อาจเปลี่ยนตามเวอร์ชัน — ตรวจสอบ README ของ openai/codex-plugin-cc ก่อนใช้จริง

3. Codex IDE extension ทำงานใน Cursor/Windsurf ได้

เนื่องจาก Cursor และ Windsurf เป็น VS Code fork ตัว Codex IDE extension จึงใช้ได้ในนั้นด้วย ทำให้ใช้ Cursor เป็น editor หลักแต่ delegate งานหนักขึ้น Codex cloud ได้โดยไม่ต้องออกจาก editor

รูปแบบผสมที่ใช้ได้จริง (mix-and-match)

  • ใช้ Claude Code หรือ Cursor เป็นตัวหลักในการเขียนโค้ด แล้ว delegate adversarial review ให้ Codex ผ่าน plugin เพื่อได้มุมมองจากคนละโมเดล
  • ใช้ Codex cloud + GitHub (@codex) เป็นด่าน review อัตโนมัติบนทุก PR ไม่ว่าโค้ดจะเขียนด้วยเครื่องมือใด
  • วาง AGENTS.md เป็น single source of truth ของกฎโปรเจกต์ให้ทุก agent อ่านตรงกัน

💡 คุณค่าของการใช้หลายตัวไม่ได้อยู่ที่ "มีของเยอะ" แต่อยู่ที่ การได้มุมมองจากคนละโมเดล โดยเฉพาะขั้นตอน review การให้ agent ที่ไม่ได้เป็นคนเขียนโค้ดเป็นคนตรวจ มักจับ bug และ regression ได้ดีกว่าให้ตัวเดิมตรวจงานตัวเอง

บทที่ 14: เคล็ดลับ ข้อควรระวัง และแนวทางสำหรับทีม/องค์กร

บทก่อนหน้าปูพื้นเรื่องการติดตั้ง, config.toml, AGENTS.md, การเลือกโมเดล, Codex cloud และ GitHub integration มาแล้ว บทนี้จะรวบยอดทั้งหมดในมุม "ทำงานจริงในทีม/องค์กร" คือทำอย่างไรให้ Codex ทั้งคุ้มต้นทุน ปลอดภัย และควบคุมได้เมื่อมีคนใช้หลายคน โดยเน้น actionable ทำตามได้ทันที

⚠️ ตัวเลขราคา, rate limit และชื่อโมเดลรุ่นล่าสุดในบทนี้ ณ กลางปี 2026 เปลี่ยนแปลงบ่อยและบางส่วนมาจากแหล่งรอง ก่อนตัดสินใจเชิงงบประมาณให้ยืนยันกับ Codex rate card ทางการ (help.openai.com) และหน้า pricing เสมอ ส่วนชื่อโมเดลให้ยืนยันด้วย /model หรือ /status ในเครื่องจริง

14.1 การบริหาร rate limit แผนการใช้งาน และต้นทุน

Codex ผูกกับ ecosystem ของ ChatGPT ไม่ได้ขายแยก การคุมต้นทุนจึงเริ่มที่ "เลือกวิธี login ให้ตรงรูปแบบการใช้งาน"

ประเด็นSign in with ChatGPTAPI key
การคิดเงินใช้โควตาตามแผน (รวมในค่าสมาชิกอยู่แล้ว)จ่ายตาม token แบบ usage-based
ข้อจำกัดหน้าต่างเวลามี rate limit ตามแผน (5-hour rolling window + weekly cap)ไม่มี window limit จ่ายตามที่ใช้
เหมาะกับนักพัฒนาที่ใช้ประจำวัน มีแผนอยู่แล้วงาน headless/CI, ปริมาณ spike, ต้องการคุมด้วย budget ของ API

แผนที่รองรับ Codex ครอบคลุมตั้งแต่ Free, Go, Plus, Pro, Business, Edu ถึง Enterprise โดยโควตา/rate limit ต่างกันตามแผน แผน Pro มีตัวเลือกเพิ่ม rate limit (เช่น tier 5x/20x) ส่วน Enterprise/Edu ใช้ระบบ credit

⚠️ สิ่งที่ต้องรู้สำหรับทีม: การใช้ Codex cloud และ GitHub integration ต้องมีแผน Plus/Pro/Business/Edu/Enterprise และผู้ตั้งค่าต้องมีสิทธิ์ admin ของ repo — วางแผนเรื่องสิทธิ์คนตั้งค่าไว้ล่วงหน้า

ตัวเลขราคาโดยประมาณ (แหล่งรอง confidence ต่ำ ต้องยืนยัน): Free $0, Go ~$8, Plus ~$20/เดือน, Pro ~$100 (tier 5x) และ ~$200 (tier 20x), Business ~$20–25/ผู้ใช้/เดือน, Enterprise ตามสัญญา ในช่วงเดือน เม.ย. 2026 OpenAI ปรับการคิด usage ของ Codex มา อิงโทเคน (token/credit) แทนการนับต่อข้อความ และ rate limit ใช้หน้าต่าง 5 ชั่วโมงแบบ rolling บวก weekly cap (reset 7 วันหลังข้อความแรก)

เทคนิคคุมต้นทุนที่ทำได้จริง:

  • ปรับ model_reasoning_effort ตามความยากงาน — ค่า default คือ medium งานโค้ดทั่วไป/instruction following ระดับ minimal ก็ทำได้ดีและประหยัดโทเคน สงวน high/xhigh ไว้เฉพาะงานยากหลายขั้นตอน เพราะช้าและกินโทเคนมากกว่ามาก
  • เลือก tier โมเดลให้เหมาะกับงาน — ตระกูลโมเดลปัจจุบันแบ่งเป็นระดับ (เช่นรุ่นเร็ว/ถูก, รุ่นสมดุล, รุ่นแรงสุด) ใช้รุ่นเร็ว/ถูกกับงาน routine แล้วค่อยยกระดับเมื่อจำเป็น (ดูรายละเอียดการเลือกโมเดลในบทว่าด้วยโมเดลและ reasoning effort)
  • ตั้ง profile สำหรับงานหนัก แยกจากงานประจำวัน เช่น profile deep-review ที่ใช้ effort สูงเฉพาะตอนรีวิวจริง แล้วเรียกด้วย codex --profile deep-review เท่านั้น
# ~/.codex/deep-review.config.toml — ใช้เฉพาะตอนต้องคิดหนัก
model_reasoning_effort = "xhigh"
approval_policy = "on-request"

💡 ให้ทีมตกลง "ค่า default ต้นทุนต่ำ" ใน config ที่ commit เข้า repo (เช่น effort = medium/minimal) แล้วให้แต่ละคน opt-in ระดับสูงผ่าน profile ส่วนตัว จะคุมค่าใช้จ่ายรวมได้ดีกว่าปล่อยให้ทุกคนตั้งเอง

14.2 การรีวิวความปลอดภัยของโค้ดที่ AI สร้าง

หลักการพื้นฐาน: โค้ดที่ agent สร้างต้องผ่านสายตามนุษย์และผ่าน gate อัตโนมัติก่อน merge เสมอ อย่าถือว่า Codex "ถูกเสมอ" Codex มีกลไกความปลอดภัยหลายชั้น ใช้ให้ครบ

ชั้นที่ 1 — ป้องกันด้วย sandbox + approval (ก่อนโค้ดจะถูกสร้าง/รัน)

สองมิตินี้แยกกันใน config.toml (รายละเอียดเต็มอยู่ในบทว่าด้วยการตั้งค่า config.toml):

คีย์ค่าที่รับได้ใช้เมื่อ
sandbox_moderead-only / workspace-write / danger-full-accessจำกัดสิทธิ์เขียนไฟล์/รันคำสั่ง
approval_policyuntrusted / on-request / never (+ รูปแบบ granular)จุดที่ Codex ต้องหยุดขออนุมัติ

คู่ที่แนะนำสำหรับงานประจำวัน (preset "Auto") คือ --sandbox workspace-write --ask-for-approval on-request

⚠️ หลีกเลี่ยง danger-full-access + approval_policy = "never" พร้อมกัน โดยเฉพาะกับ repo ที่ยังไม่ trust หรือ prompt ที่มาจากแหล่งภายนอก — เท่ากับปิดกลไกป้องกันทั้งหมด ค่า approval_policy บางค่าต่างกันตามเวอร์ชัน CLI (บางแหล่งพูดถึง on-failure) ให้ตรวจกับ codex --help หรือ config-reference ของเวอร์ชันที่ใช้จริง

ชั้นที่ 2 — รีวิว diff ก่อนเปิด PR

  • ในเซสชัน CLI ใช้ /review เพื่อให้ Codex ตรวจ diff หาปัญหา หรือใช้ subcommand codex review
  • เขียน prompt รีวิวให้เจาะความเสี่ยง เช่น @codex review for security regressions, missing tests, and risky behavior changes

ชั้นที่ 3 — รีวิวอัตโนมัติบน GitHub

เปิด Code review ต่อ repo (หรือระดับ org) ที่ Codex settings แล้วเลือกโหมด On-demand (@codex review ใน PR comment) หรือ Automatic (รีวิวทุก PR) เมื่อพบปัญหาให้สั่ง @codex fix it หรือ @codex fix the P1 issue ให้ Codex แก้และ push เข้า PR

⚠️ ข้อจำกัดสำคัญของ code review บน GitHub: Codex ตั้งใจ flag เฉพาะ issue ระดับ P0/P1 (security regressions, missing test coverage, risky behavior changes, documentation gaps) และปล่อยงาน formatting/lint ให้ CI ดังนั้น อย่าถือ Codex review แทน linter/CI/SAST ทีมยังต้องมี lint + test + security scan ของตัวเองใน pipeline ครบ

ชั้นที่ 4 — คุมสิทธิ์เมื่อรันใน CI

Official GitHub Action openai/codex-action มี safety-strategy ให้เลือก: drop-sudo (default), unprivileged-user, read-only, unsafe และ permission-profile (:workspace, :read-only) เก็บ openai-api-key เป็น GitHub secret เสมอ ให้ตั้งค่าที่จำกัดสิทธิ์ที่สุดเท่าที่งานยังทำได้

💡 ต้องการ "รีวิวเชิงโจมตี" ลึกขึ้น: plugin openai/codex-plugin-cc (เรียก Codex จากภายใน Claude Code) มีคำสั่ง /codex:adversarial-review นอกเหนือจาก /codex:review เหมาะกับการหาช่องโหว่แบบตั้งใจแหย่

14.3 การวาง AGENTS.md ระดับทีม

AGENTS.md คือ "README สำหรับ agent" เป็นมาตรฐานเปิดที่หลายเครื่องมือใช้ร่วม (Cursor, Copilot, Gemini CLI, Windsurf ฯลฯ) การวางให้ดีระดับทีมคือหัวใจของการควบคุมพฤติกรรม agent ให้สม่ำเสมอ (โครงสร้างและลำดับชั้นเต็มอยู่ในบทว่าด้วย AGENTS.md)

หลักการวางระดับทีม:

  • commit AGENTS.md ที่ project root เข้า repo เพื่อให้ทุกคนและ agent ทุก surface ใช้กฎชุดเดียวกัน สร้าง scaffold เริ่มต้นด้วย /init
  • monorepo วาง nested ไฟล์เพิ่มในแต่ละ package/service ไฟล์ที่ใกล้โค้ดที่กำลังแก้ที่สุดชนะ (concatenate จาก root ลงล่าง) เหมาะกับกฎเฉพาะทางเช่น services/payments/AGENTS.md
  • แยก global vs repo: กฎส่วนตัวข้าม repo (เช่น dependency manager ที่ชอบ) ไว้ที่ ~/.codex/AGENTS.md ส่วนกฎที่ทั้งทีมต้องปฏิบัติตามไว้ใน repo
  • ใช้ AGENTS.override.md เมื่อต้อง override กฎเฉพาะจุดโดยไม่แตะไฟล์หลัก (แต่ละ scope ตรวจไฟล์ override ก่อน)
  • ใส่ section ## Code Review Rules สำหรับ GitHub integration — กฎควรกระชับ ระบุพฤติกรรมที่ต้อง flag พร้อม safe alternative, scoped และ durable และไม่ครอบคลุมงาน lint/format

เนื้อหาที่ควรมีสำหรับทีม (ไม่มี section บังคับ):

# AGENTS.md (ตัวอย่างโครงสำหรับทีม)
## ภาพรวมโปรเจกต์
## คำสั่ง build / test / lint   (เช่น รัน `npm run lint` ก่อนเปิด PR)
## Code style / conventions
## Testing instructions
## Deployment steps
## Security considerations
## PR guidelines
## Code Review Rules            (กฎที่ให้ Codex ใช้ตอน @codex review)

⚠️ ขนาด AGENTS.md รวมถูกจำกัดที่ 32 KiB โดย default (คีย์ project_doc_max_bytes) ไฟล์ว่างถูกข้าม และการค้นหยุดที่ cwd (ไม่ค้นลึกกว่านั้น) อย่าอัดทุกอย่างในไฟล์เดียว — ให้กระชับและกระจายเป็น nested files

💡 จำไว้ว่าลำดับความสำคัญคือ prompt ที่ผู้ใช้พิมพ์ใน chat override AGENTS.md ทุกไฟล์ ดังนั้น AGENTS.md เป็น "ค่า default ที่ดี" ไม่ใช่ "รั้วกันเด็ดขาด" กฎความปลอดภัยเชิงบังคับต้องอยู่ที่ชั้น sandbox/approval/CI ไม่ใช่แค่ในเอกสาร

14.4 Data privacy และการเก็บข้อมูล

รู้ว่าอะไรถูกเก็บที่ไหน — ไดเรกทอรี CODEX_HOME (default ~/.codex) เก็บ authentication, config, history, logs และ caches ในเครื่อง local

การจัดการ secret อย่างถูกวิธี:

  • อย่า hardcode token ใน config — MCP HTTP server ให้ใช้ bearer_token_env_var (ชี้ชื่อ env ที่เก็บ token) ส่วน custom provider ใช้ env_key
  • ใน CI เก็บ API key เป็น GitHub secret (openai-api-key) ไม่ commit เข้า repo
  • project config มีขอบเขตจำกัดโดยตั้งใจ — .codex/config.toml ในโปรเจกต์โหลดเฉพาะเมื่อ trust โปรเจกต์นั้น และ ห้าม override ค่า machine-local เช่น provider settings, authentication, notifications, profile selection และ telemetry เป็นการป้องกันไม่ให้ repo ที่โคลนมาแอบเปลี่ยน auth/telemetry ของเครื่อง

data residency / การควบคุมปลายทางข้อมูล:

  • ใช้คีย์ openai_base_url ชี้ built-in provider openai ไปที่ proxy/router/data-residency endpoint ได้โดยไม่ต้องสร้าง provider ใหม่ เหมาะกับองค์กรที่ต้องผ่าน gateway กลาง
  • Codex cloud รัน task ในคอนเทนเนอร์ sandbox แยกต่อ task ไม่ปนกับงานอื่นและไม่กินทรัพยากรเครื่อง local

⚠️ รายละเอียด managed/system config ระดับองค์กร (admin-pushed config, requirements.toml, allow_managed_hooks_only) เห็นได้เพียงบางส่วนและยังไม่ยืนยันตำแหน่งไฟล์/รูปแบบที่แน่นอนจากเอกสารทางการ ก่อนวาง policy บังคับระดับองค์กรให้ตรวจ config-reference/config-advanced เวอร์ชันที่ทีมใช้จริง และยืนยันนโยบายการเก็บ/ใช้ข้อมูลของ OpenAI สำหรับแผนที่องค์กรใช้ (Business/Enterprise) โดยตรง — อย่าอนุมานจากบทนี้

14.5 ข้อจำกัดที่ควรรู้ของ Codex

ข้อจำกัดผลกระทบสิ่งที่ควรทำ
ชื่อโมเดลเรือธง/ค่า default เปลี่ยนเร็วconfig ที่ hardcode ชื่อรุ่นอาจล้าสมัยยืนยันด้วย /model / /status ก่อน pin ชื่อรุ่นใน config
รูปแบบ profiles เปลี่ยน (inline [profiles.NAME] เดิม → ไฟล์แยก <name>.config.toml)profile เก่าอาจหยุดทำงานหลังอัปเดตmigrate แต่ละ inline table ไปเป็นไฟล์ ~/.codex/<name>.config.toml
ค่า approval_policy ต่างตามเวอร์ชันสคริปต์อาจใช้ค่าที่เวอร์ชันนั้นไม่รองรับตรวจ codex --help / config-reference ของเวอร์ชันจริง
Code review บน GitHub flag แค่ P0/P1ไม่จับ style/lint/ปัญหาเล็กคง linter + CI + security scan ของทีมไว้ครบ
AGENTS.md จำกัด 32 KiB, ค้นหยุดที่ cwdกฎที่ยาวเกินหรืออยู่ลึกเกินอาจไม่ถูกอ่านกระชับ + กระจายเป็น nested files
prompt ใน chat override ทุกไฟล์ AGENTS.mdผู้ใช้เขียน prompt ทับกฎได้บังคับความปลอดภัยที่ชั้น sandbox/CI ไม่ใช่แค่เอกสาร
ราคา/rate limit เปลี่ยนบ่อย (แหล่งรอง)งบประมาณคลาดเคลื่อนยืนยันกับ rate card ทางการก่อนวางแผน
แพ็กเกจ npm codex (unscoped) เป็นคนละโปรเจกต์ติดตั้งผิดตัวติดตั้ง @openai/codex เท่านั้น

💡 หลายข้อจำกัดข้างต้นมาจาก "เอกสารเปลี่ยน host และเวอร์ชันไล่เร็ว" (เอกสารทางการย้ายจาก developers.openai.com/codex/* ไป learn.chatgpt.com/docs/* แบบ 308 redirect) วิธีที่ปลอดภัยที่สุดคือยึด codex --help, /status และ config-reference ของเวอร์ชันที่ติดตั้งจริงเป็นแหล่งความจริง แทนการจำค่าจากคู่มือเก่า

14.6 Checklist การใช้อย่างมืออาชีพ

ก่อนเริ่มโปรเจกต์ / ตั้งค่าทีม

  • ติดตั้งจากแพ็กเกจถูกตัว (@openai/codex / brew install --cask codex / install script) ไม่ใช่ codex unscoped
  • เลือกวิธี login ให้ตรงงาน (Sign in with ChatGPT สำหรับงานประจำวัน, API key สำหรับ CI/headless)
  • รัน /init สร้าง AGENTS.md แล้วเติมกฎ build/test/lint, security, PR guidelines และ ## Code Review Rules
  • commit AGENTS.md (+ .codex/config.toml ที่ปลอดภัย) เข้า repo ให้ทีมใช้ร่วม
  • ตกลง default ต้นทุนต่ำ (model tier + model_reasoning_effort) และให้ opt-in ระดับสูงผ่าน profile

ระหว่างใช้งานทุกวัน

  • ใช้ preset ปลอดภัย: sandbox_mode = workspace-write + approval_policy = on-request
  • ตรวจ /status ให้แน่ใจว่ากำลังใช้โมเดล/profile/sandbox ที่ตั้งใจ
  • ปรับ reasoning effort ลงให้เท่าที่งานต้องการ เพื่อคุมโทเคน
  • รัน /review (หรือ codex review) กับ diff ก่อนเปิด PR

ก่อน merge / บน CI

  • เปิด @codex review (หรือ Automatic reviews) บน PR และสั่ง @codex fix it เมื่อพบ P0/P1
  • ยืนยันว่า linter + test + security scan ของทีมยังรันครบ (Codex review ไม่แทน)
  • ใน codex-action ตั้ง safety-strategy/permission-profile ให้จำกัดสิทธิ์ที่สุดเท่าที่งานทำได้ และเก็บ key เป็น GitHub secret

ด้าน privacy / governance

  • ไม่ hardcode secret — ใช้ bearer_token_env_var / env_key / GitHub secrets
  • ถ้าต้องผ่าน gateway/data-residency ตั้ง openai_base_url ชี้ปลายทางกลาง
  • ตรวจว่า project config ไม่พยายามแตะค่า machine-local (auth/telemetry) และ trust เฉพาะ repo ที่มั่นใจ
  • ยืนยันนโยบายการเก็บ/ใช้ข้อมูลของแผนองค์กรกับเอกสารทางการก่อน rollout วงกว้าง

💡 หัวใจของการใช้ Codex อย่างมืออาชีพในทีมสรุปได้สามข้อ: (1) ควบคุมพฤติกรรมด้วย AGENTS.md ที่ commit ร่วมกัน (2) บังคับความปลอดภัยที่ชั้น sandbox/approval/CI ไม่ใช่แค่เอกสาร และ (3) คุมต้นทุนด้วย model tier + reasoning effort + profile — แล้วให้มนุษย์เป็นผู้ตัดสินใจ merge เสมอ

คำถามที่พบบ่อยเกี่ยวกับการใช้ Codex (FAQ)

รวมคำถามที่มักเจอบ่อยเมื่อเริ่มใช้ OpenAI Codex พร้อมคำตอบแบบตรงประเด็น สำหรับรายละเอียดเชิงลึกของแต่ละหัวข้อ ดูได้จากบทที่เกี่ยวข้องซึ่งอ้างอิงไว้ในแต่ละคำตอบ

OpenAI Codex คืออะไร

Codex คือ coding agent ที่ OpenAI เปิดตัวใหม่ในปี 2025 (คนละตัวกับโมเดล Codex ปี 2021 ที่ปลดระวางไปแล้ว) ทำงานโดยห่อหุ้มโมเดลเรือธงของ OpenAI ตระกูล GPT-5 / gpt-5-codex เข้ากับความสามารถอ่านและแก้ไฟล์ รันคำสั่งเชลล์ภายใน sandbox ระบบ approval และการทำ code review

Codex ใช้งานได้หลาย surface ที่แชร์บัญชีและ context ร่วมกัน ได้แก่ Codex CLI (เอเจนต์บนเทอร์มินัล), Codex ใน ChatGPT / Codex cloud (cloud agent รันในคอนเทนเนอร์ sandbox), IDE extension (VS Code / Cursor / Windsurf) และการรวมกับ GitHub สำหรับ code review ผ่าน @codex

จะเริ่มใช้ Codex ต้องทำอะไรบ้าง

เส้นทางที่เร็วที่สุดคือเริ่มจาก Codex CLI สามขั้นตอน

  1. ติดตั้ง CLI ผ่านช่องทางใดช่องทางหนึ่ง เช่น npm install -g @openai/codex, brew install --cask codex หรือ curl install script
  2. รันคำสั่ง codex ในไดเรกทอรีโปรเจกต์ แล้วเลือกวิธีล็อกอิน (Sign in with ChatGPT หรือ API key)
  3. พิมพ์ /init เพื่อให้ Codex สแกน repo และสร้างไฟล์ AGENTS.md ตั้งต้น

💡 เคล็ดลับ: แพ็กเกจ npm ชื่อ codex (แบบ unscoped) เป็นคนละโปรเจกต์ ต้องติดตั้ง @openai/codex เท่านั้น

ขั้นตอนติดตั้งและตั้งค่าละเอียดอยู่ในบทว่าด้วยการติดตั้งและเริ่มต้นใช้งาน Codex CLI

Codex ใช้ฟรีได้ไหม ต้องสมัครแผนอะไร

การ Sign in with ChatGPT รวมอยู่ในทุกแผน รวมถึงแผน Free ด้วย โดยโควตาและ rate limit จะต่างกันตามแผน (Free, Go, Plus, Pro, Business, Edu, Enterprise) อีกทางเลือกคือใช้ OpenAI API key ซึ่งจ่ายตามการใช้ token แบบ usage-based

ข้อควรรู้: การใช้ Codex cloud และการรวมกับ GitHub ต้องมีแผนระดับ Plus/Pro/Business/Edu/Enterprise และสิทธิ์ admin ของ repo

⚠️ ตัวเลขราคาและ rate limit ต่อแผนมาจากแหล่งรองและเปลี่ยนแปลงบ่อย ควรยืนยันกับ Codex rate card ทางการก่อนตัดสินใจ ดูรายละเอียดเพิ่มในบทว่าด้วยโมเดลและราคา

Codex CLI กับ Codex cloud ต่างกันอย่างไร

ทั้งสองเป็น surface ของ Codex ตัวเดียวกันแต่ต่างสภาพแวดล้อมการรัน

ประเด็นCodex CLICodex cloud
ที่รันเครื่อง local ผ่านเทอร์มินัลคอนเทนเนอร์ sandbox แยกบนคลาวด์
รูปแบบงานinteractive TUI โต้ตอบทีละขั้นbackground task, หนึ่ง environment ต่อ task, รันขนานได้
จุดเข้าคำสั่ง codexWeb dashboard, GitHub, Linear, Slack และ CLI
ผลลัพธ์แก้ไฟล์ในเครื่องโดยตรงสรุปงาน + diff แล้วเปิด Pull Request ให้ review

เลือก CLI เมื่อต้องการทำงานคู่กับโค้ดในเครื่องแบบโต้ตอบ และเลือก cloud เมื่ออยาก delegate งานให้ทำ background โดยไม่กินทรัพยากรเครื่อง ดูเชิงลึกในบทว่าด้วย Codex cloud และการรวมกับ GitHub

Codex ต่างจาก GitHub Copilot และ Claude Code อย่างไร

โดยตำแหน่งผลิตภัณฑ์ Codex เป็น dual-platform (มีทั้ง web/cloud และ CLI ที่เป็นโอเพนซอร์ส) ผูกกับโมเดล OpenAI และ ChatGPT ecosystem ส่วน Claude Code เป็น terminal agent เชิงลึกที่ผูกกับโมเดลของ Anthropic ทั้งสองตัวจึงล็อกกับโมเดลของค่ายตัวเอง โดยราคา tier จ่ายเงินเริ่มต้นของ Codex, Claude Code และเครื่องมือกลุ่มนี้อยู่ราว $20/เดือน

จุดร่วมที่น่าสนใจคือ AGENTS.md เป็นฟอร์แมตมาตรฐานเปิดที่ใช้ข้ามเครื่องมือ ทั้ง Codex, Cursor, Copilot, Gemini CLI และ Windsurf จึงย้ายกฎประจำโปรเจกต์ระหว่างเครื่องมือได้ ดูการเทียบแบบละเอียดในบทเปรียบเทียบ Codex กับเครื่องมืออื่น

⚠️ RESEARCH ที่มีไม่ได้ลงรายละเอียดฟีเจอร์ของ GitHub Copilot โดยตรง จุดเปรียบเทียบที่ชัดที่สุดจึงเป็น Codex เทียบกับ Claude Code

Codex ปลอดภัยกับโค้ดของบริษัทไหม

Codex ออกแบบการควบคุมความปลอดภัยเป็นสองมิติที่แยกกันในไฟล์ config.toml

  • sandbox_mode คุมสิทธิ์เข้าถึงไฟล์ระบบ: read-only, workspace-write, danger-full-access
  • approval_policy คุมว่าจะขออนุมัติก่อนรันคำสั่งเมื่อไหร่: untrusted, on-request, never

คู่ที่แนะนำสำหรับงานประจำวันคือ workspace-write + on-request เพื่อให้แก้ไฟล์ในโปรเจกต์ได้แต่ยังต้องขออนุมัติก่อนทำสิ่งที่เสี่ยง ส่วนงานบน Codex cloud จะรันในคอนเทนเนอร์ sandbox ที่แยกออกจากกันต่อ task

💡 องค์กรที่ต้องการควบคุมเข้มขึ้นสามารถใช้ API key และ managed/system config layer เพื่อบังคับนโยบายกลางได้ ดูการตั้งค่า approval และ sandbox แบบเต็มในบทว่าด้วยการตั้งค่า config.toml และ AGENTS.md

สั่งงาน Codex เป็นภาษาไทยได้ไหม

โดยทั่วไปทำได้ เพราะ Codex ทำงานบนโมเดลภาษาธรรมชาติตระกูล GPT-5 จึงเข้าใจ prompt ภาษาไทยได้ อย่างไรก็ตามเพื่อความแม่นยำ แนะนำให้คงคำสั่ง (command), flag, ชื่อไฟล์/พาธ และ identifier ในโค้ดเป็นภาษาอังกฤษเสมอ

ในทางปฏิบัติ ไฟล์บริบทอย่าง AGENTS.md และ config.toml นิยมเขียนคำสั่งเป็นภาษาอังกฤษ ส่วนคำอธิบายงานหรือ prompt โต้ตอบจะเขียนภาษาไทยก็ได้

Codex ใช้โมเดลอะไร แล้วเลือกโมเดลได้ไหม

Codex ทำงานบนโมเดลตระกูล GPT-5 โดยมี gpt-5-codex ที่เป็น GPT-5 ซึ่งปรับจูนสำหรับงาน agentic coding โดยเฉพาะ (เปิดตัว 15 ก.ย. 2025 ปรับเวลาคิดแบบ dynamic ตามความยากของงาน) เลือกหรือสลับโมเดลได้สามช่องทาง

  • ใน CLI ใช้ slash command /model หรือ flag --model / -m
  • ใน ChatGPT ใช้ model selector ใต้ช่องพิมพ์
  • ในไฟล์ตั้งค่า model = "..." ใน config.toml

นอกจากนี้ปรับระดับการคิดได้ด้วย model_reasoning_effort (ค่า minimal | low | medium | high | xhigh โดย default เป็น medium)

⚠️ ชื่อโมเดลเรือธงล่าสุด ณ กลางปี 2026 เปลี่ยนเร็วมากและแหล่งข้อมูลไม่ตรงกัน (เอกสารอ้างถึงทั้ง gpt-5-codex และตระกูล GPT-5.x รุ่นใหม่กว่า) ควรยืนยันชื่อ/ID โมเดลจริงด้วย /model หรือ /status ในเครื่องของคุณก่อนนำไปตั้งใน config ดูรายละเอียดในบทว่าด้วยโมเดลและราคา

ต้องเขียนโปรแกรมเป็นก่อนไหมถึงจะใช้ Codex ได้

Codex เป็นเครื่องมือ agentic software engineering ที่ช่วยงานเขียนโค้ดจริง แม้จะเริ่มลองใช้ได้โดยไม่ต้องเชี่ยวชาญ แต่ความรู้พื้นฐานด้านการเขียนโปรแกรมจะช่วยให้คุณ

  • ตรวจทาน (review) diff และ Pull Request ที่ Codex สร้างได้อย่างมั่นใจ
  • ตั้งค่า approval_policy และ sandbox_mode ให้เหมาะกับความเสี่ยงของงาน
  • เขียน AGENTS.md อธิบายบริบทและ convention ของโปรเจกต์ให้ agent ทำงานได้ตรงเป้า

สรุปคือ ยิ่งเข้าใจโค้ดที่กำลังทำ ยิ่งใช้ Codex ได้ปลอดภัยและมีประสิทธิภาพ

จำเป็นต้องมีไฟล์ AGENTS.md ไหม

ไม่บังคับ แต่แนะนำอย่างยิ่ง AGENTS.md เปรียบเหมือน "README สำหรับ agent" ที่ Codex อ่านอัตโนมัติทุกครั้งที่เริ่มเซสชัน ใช้บอกภาพรวมโปรเจกต์ คำสั่ง build/test/lint, code style และกฎ code review (ผ่านหัวข้อ ## Code Review Rules)

สร้างไฟล์ตั้งต้นได้ง่ายด้วย /init และวางแบบลำดับชั้นได้ (root สำหรับกฎทั้ง repo, nested ในแต่ละ package สำหรับกฎเฉพาะส่วน โดยไฟล์ที่ใกล้โค้ดที่สุดจะชนะ) ดูโครงสร้างและตัวอย่างเนื้อหาในบทว่าด้วยการตั้งค่า config.toml และ AGENTS.md

แหล่งอ้างอิงหลัก (References)