Codex: thư mục local mới là sản phẩm
Nhiều người mặc định Codex chỉ để code và fix bug, hết. Xem hết buổi hướng dẫn thì hình dung khác hẳn: đọc tài liệu, phân tích yêu cầu, lên kế hoạch công việc, ghi nhớ context, tự động hoá việc lặp lại, kết nối tới hàng loạt công cụ bên ngoài. Không có việc nào trong số đó là code cả.
Nhưng liệt kê tính năng là cách sai để hiểu công cụ này, vì các tính năng không độc lập với nhau. Gần như tất cả đều là hệ quả của đúng một quyết định thiết kế:
Một project trong Codex là một thư mục thật trên máy bạn, và Codex thao tác trực tiếp trên đó.
ChatGPT làm việc trên bản sao bạn upload lên cloud. Codex làm việc trên bản gốc. Chấp nhận một câu đó rồi thì project, file Excel được sinh ra, hành vi bất ngờ của nút "xoá", các file memory và hai màn hình cài đặt đều thôi là một danh sách tính năng — chúng là một ý tưởng với năm gương mặt.
Về bài viết này
Viết từ video trên kênh. Phần đi qua giao diện, phần tích hợp Linear và job chạy theo lịch là những gì diễn ra trên màn hình. Có hai chỗ mình ghi rõ thay vì khẳng định: tên model trong phụ đề tự động sai quá nặng nên mình mô tả theo hành vi; và con số giá gói đăng ký nêu trong video là con số của tác giả, chưa đối chiếu với bảng giá.
Vào cuộc: ba hình hài, hai kiểu tính tiền
Codex có ba dạng, và chọn dạng nào ảnh hưởng đến cách bạn nghĩ về nó nhiều hơn là ảnh hưởng đến năng lực:
| Dạng | Lấy ở đâu | Cảm giác như |
|---|---|---|
| App desktop | tải cho macOS hoặc Windows | một khung ChatGPT có tay chạm được vào ổ đĩa |
| Tích hợp IDE | VS Code, Cursor, JetBrains, Vim | một trợ lý nằm ngay trong editor |
| Terminal | cài bằng npm | một agent CLI |
Video dùng app desktop — bản mà ý tưởng "thư mục local" hiện rõ nhất.
Đăng nhập có hai đường, và đây là hai cấu trúc chi phí khác nhau chứ không phải hai cánh cửa vào cùng một phòng:
- Continue with ChatGPT — gói trả phí, chi phí hàng tháng cố định dù bạn đẩy nó nặng đến đâu.
- Enter API key — tính theo token: dùng bao nhiêu trả bấy nhiêu.
Video chọn gói đăng ký và nêu con số khoảng 20 đô một tháng. Hãy coi đó là con số của tác giả và tự kiểm tra bảng giá hiện hành trước khi lập ngân sách — thứ đúng trong cả hai trường hợp là hình dạng của lựa chọn. Chi phí cố định khiến những phiên làm việc dài, mò mẫm, để agent tự chạy trở nên "miễn phí" về mặt tâm lý. Tính theo token khiến bạn giật mình mỗi lần agent quyết định đọc lại cả thư mục. Khác biệt đó sẽ thay đổi cách bạn dùng công cụ nhiều hơn bất kỳ tính năng nào trong bài.
Màn hình cài đặt đừng bỏ qua
Phần lớn bài giới thiệu công cụ coi mục settings là đoạn hắng giọng trước khi vào demo. Ở đây thì ngược lại, và lý do nằm ở câu mở đầu bài này: một agent thao tác trên hệ thống file thật thì có bán kính sát thương thật.
Phần appearance đúng là trang trí — theme sáng, tối hoặc tự chỉnh, đổi font, import theme từ ngoài vào. Phần configuration thì không.
Approval policy — khi nào nó dừng lại hỏi bạn?
Bốn lựa chọn, xếp theo mức độ che chắn cho bạn giảm dần:
| Hành vi | Nghĩa là gì | Có nên dùng? |
|---|---|---|
| Agent tự phán đoán | tự chạy những gì nó cho là an toàn, dừng hỏi khi đụng tới hệ thống | lựa chọn của video, và là mặc định hợp lý |
| Luôn luôn hỏi | hỏi duyệt ở mọi hành động động tới dữ liệu | an toàn, nhưng đủ chậm để bạn bấm duyệt theo phản xạ |
| Hỏi khi lỗi | tự duyệt hết, chỉ quay lại tìm bạn khi có lỗi | xem bên dưới |
| Không bao giờ hỏi | tự thực thi mọi thứ, im lặng | không nên |
Chỗ video phản đối hỏi khi lỗi là quan sát sắc nhất trong cả phần cài đặt, và đáng nhắc lại vì tuỳ chọn này nghe có vẻ thận trọng: đến lúc một hành động báo lỗi thì nó đã chạy rồi. Một lời hỏi duyệt đến sau khi thực thi thì không phải hỏi duyệt — đó là thông báo. Cái sự cố bạn muốn ngăn đã xảy ra; bạn chỉ đang được báo tin, và việc quay lại giờ là vấn đề của bạn.
Không bao giờ hỏi bị loại vì lý do quá hiển nhiên. Còn lại hai lựa chọn đầu là thật, và đánh đổi giữa chúng hoàn toàn nằm ở chỗ bạn tin phán đoán rủi ro của agent tới đâu.
Sandbox — nó với tới được những gì?
Ba lựa chọn, và đây mới là cái trục thực sự chặn thiệt hại:
- Read only — agent chỉ đọc file, không sửa không xoá được gì. Tuỳ chọn an toàn.
- Workspace write — được tạo, sửa, xoá nhưng chỉ trong thư mục bạn trỏ tới. Ngoài thư mục đó thì không đụng được. Đây là lựa chọn của video cho dự án này.
- Full access — sửa xoá được cả bên ngoài workspace, kể cả tập tin hệ thống nhạy cảm. Bị loại vì quá rủi ro.
Để ý cách hai cái núm này kết hợp. Approval policy quyết định bạn bị ngắt quãng bao nhiêu lần; sandbox quyết định tệ tới đâu nếu bạn lỡ duyệt nhầm. Read-only cộng không-bao-giờ-hỏi an toàn hơn full-access cộng luôn-luôn-hỏi, vì cặp đầu khiến hành động phá hoại là bất khả, còn cặp sau chỉ khiến nó chậm lại. Nếu bạn chỉ đủ tâm trí để đặt cẩn thận một trong hai, hãy đặt sandbox.
Toàn bộ những thứ này được ghi vào một file config bạn mở ra đọc được — đó mới là thiết kế đúng, vì một mô hình phân quyền mà bạn không tự kiểm tra được bằng chữ thì là mô hình bạn đang tin theo kiểu đức tin.
Project: một ý tưởng, năm gương mặt
Tạo project — từ con số 0 hoặc trỏ vào thư mục có sẵn — và Codex gắn cuộc trò chuyện vào thư mục đó. Cái gì nằm trong đó là trong phạm vi: file Excel, PDF, PowerPoint, hay nguyên một codebase. Cái gì nằm ngoài thì không.
Trong một project bạn chạy được nhiều cuộc trò chuyện song song. Mỗi cái hiện vòng tròn xoay khi đang chạy và một chấm xanh khi xong, nên việc chạy song song nhìn thấy được chứ không phải thứ bạn phải tự nhớ trong đầu.
Phần demo làm rõ khác biệt theo cách ít kịch tính nhất có thể. Đầu tiên là một prompt tóm tắt bình thường, loại mà ChatGPT trả lời y hệt. Rồi tới: hãy tạo một file Excel để lưu thông tin này lại.
Codex viết một script build rồi sinh ra file bảng tính — tổng quan, chi tiết và nguồn tham khảo — nằm trong workspace, trên ổ đĩa của bạn. Không phải link tải về. Không phải một file trong sandbox cloud rồi hết hạn. Một file nằm trong thư mục của bạn, cạnh những file khác của bạn, mà các công cụ khác của bạn mở được ngay.
Sau đó bạn mở nó bằng Excel hay Google Sheets, hoặc xem thẳng trong Codex và hỏi đáp ngay trên nội dung file. Phần cuối đó là tiện lợi dễ chịu. Phần quan trọng là phần trước nó: sản phẩm được sinh ra đúng chỗ mà sản phẩm nên nằm.
"Xoá" không phải là xoá
Tính năng search trông như việc dọn dẹp lặt vặt, cho tới khi phần demo biến nó thành thứ thú vị hơn.
Một project bị xoá khỏi giao diện Codex. Rồi search tìm lại được nó — vì project chưa bao giờ nằm trong Codex cả. Nó là một thư mục trên đĩa mà Codex giữ con trỏ tới. Trỏ lại vào thư mục gốc là cuộc trò chuyện quay về nguyên vẹn.
Chỗ này đáng ngồi lại nghĩ, vì nó là hai thứ cùng lúc và video chỉ nói nửa vui:
- Về mặt khôi phục, rất tốt. Gỡ một thứ khỏi giao diện không thể làm bạn mất công sức. Không có hộp thoại "bạn chắc chứ?" nào đủ sức phá hỏng buổi chiều của bạn.
- Về mặt vệ sinh dữ liệu, đó là cái bẫy. Nếu trong đầu bạn là "mình xoá rồi", bạn đang sai, và tài liệu vẫn nằm nguyên trong một thư mục — điều này thành vấn đề ngay khi project đó chứa thứ gì bạn không muốn để vương vãi.
Gỡ project khỏi Codex là đóng một con trỏ, không phải xoá dữ liệu. Cả hai nửa đều đến từ cùng một thiết kế, và bạn nên biết mình đang dựa vào nửa nào.
Plugin và skill: kết nối so với chỉ dẫn
Hai từ này bị dùng lẫn lộn ở hầu hết mọi công cụ, mà ở đây chúng thực sự khác nhau. Hiểu đúng khác biệt này là ranh giới giữa một agent về mặt kỹ thuật với tới được công cụ của bạn và một agent dùng chúng cho đúng.
Plugin là phần tích hợp — một MCP server hoặc kết nối API tới công cụ bên thứ ba: GitHub, Linear, Google Drive, Gmail, Teams. Nó trả lời câu hỏi agent với tới được những gì?
Skill là một file markdown hướng dẫn. Nó định nghĩa rule và chỉ dẫn về cách agent làm việc. Nó trả lời câu hỏi agent phải hành xử ra sao khi đã với tới được thứ đó? Kết nối GitHub bằng plugin, rồi viết một skill mã hoá quy tắc đặt tên branch và git flow của bạn — thế là agent thôi tự bịa ra quy ước riêng cho từng dự án.
Codex có sẵn cả kho plugin, và cài một plugin thì kèm luôn các skill mặc định, mà bạn mở ra đọc được trước khi tin. Bạn cũng tự viết thêm skill được — và nên viết, vì skill mặc định mã hoá quy ước nhà người khác, không phải của bạn.
Phần demo Linear, và chi tiết khiến nó đáng xem
Kết nối Linear diễn ra đúng như bạn hình dung: cài về, rồi có hai phần — phần app (kết nối MCP) và phần skill (dạy agent cách tương tác với Linear). Bật cả hai, bấm connect, xác thực qua web, approve, chọn workspace. Kiểm tra lại ở màn hình Manage.
Rồi tới một prompt yêu cầu tạo issue trên Linear, kèm title và chỉ định dùng REST API — và prompt không hề nhắc tên Linear như một công cụ. Codex đọc yêu cầu, nhận ra nó thuộc về plugin và skill Linear, định tuyến sang đó, và tạo issue. Reload lại Linear thì thấy issue nằm đúng chỗ.
Đó chính là phần thưởng của việc phân biệt hai khái niệm. Plugin khiến Linear với tới được; skill khiến yêu cầu kia được nhận diện là một yêu cầu Linear. Không có skill là bạn quay lại cảnh phải gọi tên công cụ bằng tay trong mọi prompt — chỉ hơi phiền, cho tới khi bạn có tám cái đang kết nối.
Automation: ba phần, một báo cáo theo lịch
Automation ở đây có cấu trúc tiêu chuẩn, và đáng nói rõ ra vì người ta hay bỏ qua phần từ vựng:
| Thành phần | Trong phần demo |
|---|---|
| Trigger | 9 giờ sáng, mỗi ngày |
| Condition | không có — bản thân cái lịch là toàn bộ điều kiện |
| Action | kiểm tra Linear issue và review các task Codex đã xử lý |
Bạn điền một cái form, đặt tên automation, đặt lịch, và nó được đăng ký thành một job đang active kèm thời điểm chạy kế tiếp. Bạn cũng chạy tay được bằng Run now thay vì ngồi đợi đồng hồ — đó là khác biệt giữa một bộ lập lịch bạn kiểm thử được và một bộ bạn buộc phải tin.
Một chi tiết nhỏ chứa bài học chung: prompt không hề chỉ định định dạng đầu ra, nên Codex sinh ra báo cáo markdown. Không phải lỗi — đó là giá trị mặc định. Vẫn nguyên tắc cũ trong mọi việc dính tới agent: một yêu cầu không được nêu ra không phải là yêu cầu không tồn tại, mà là yêu cầu agent sẽ quyết thay bạn.
Và đây là chỗ màn hình cài đặt xứng đáng với vị trí đầu bài. Một job nổ lúc 9 giờ sáng, khi bạn không ngồi ở bàn, có quyền ghi vào một thư mục, là một hồ sơ rủi ro hoàn toàn khác với khung chat bạn đang ngồi nhìn. Buổi bốn và năm của loạt SDLC lập luận đúng điều này từ phía quản trị, còn bài Antigravity 2.0 đánh vào từ hướng ngược lại: ngay khi một công cụ chạy được không người trông, mô hình phân quyền chính là bề mặt sản phẩm.
Memory: một cái bạn viết, một cái bạn chỉ nên đọc
Codex chia memory làm hai loại, và lời khuyên hữu ích cho mỗi loại lại khác nhau.
Manual memory là của bạn. Các file markdown bạn tự viết, tự sửa, tự cập nhật — hoặc nhờ agent soạn giúp — và bạn có thể có nhiều file, mỗi tầng thư mục một file, nên một quy tắc có thể áp toàn cục hoặc gói gọn trong một dự án. Trong demo, Codex sinh ra một file từ lịch sử local của project, có mục phạm vi và trạng thái hiện tại của dự án. Nó nằm trên đĩa của bạn, trong workspace, cạnh đúng thứ mà nó mô tả.
Auto memory là của agent. Codex tự học từ các cuộc trò chuyện — cách bạn làm việc, bạn thích gì, style của bạn — rồi tự ghi lại mà không cần được yêu cầu, mặc định nằm trong ~/.codex/memory.
Lời khuyên trong video là lời khuyên tốt và nó bất đối xứng: đừng sửa auto memory — cứ để agent làm chủ phần đó — nhưng hãy đọc nó mỗi một tới hai tuần để xem nó đã kết luận những gì về bạn.
Thói quen đó đáng học vì một lý do video không nói ra. Auto memory là phần âm thầm thay đổi hành vi của agent theo thời gian. Nếu nó học hơi sai một điều về cách bạn làm việc, chẳng có gì báo cho bạn biết — bạn chỉ nhận về những câu trả lời lệch lệch, suốt nhiều tuần, không rõ nguyên nhân. Đọc lại hai tuần một lần không phải là dọn dẹp. Đó là vòng phản hồi duy nhất bạn có trên một thành phần vốn vô hình.
Và có cả một con robot làm thú cưng
Có một con robot nhỏ bạn thả ở bất cứ đâu trên màn hình. Khi bạn chuyển sang tab khác hoặc app khác, nó báo cho bạn biết lượt chạy đã xong. Chọn loại pet trong phần cài đặt Appearance.
Đây là đồ chơi, và nó giải quyết một vấn đề thật. Các lượt chạy của agent đủ dài để bạn bỏ đi, và đủ dài để bạn quên mất là mình đã bỏ đi. Một tín hiệu nền còn sống sau khi bạn chuyển đi chỗ khác chính là khác biệt giữa chờ ba mươi giây và chờ mười lăm phút mà không hay.
Điều mình rút ra
Đặt sandbox trước khi đặt bất cứ thứ gì khác. Approval policy quyết định bạn bị ngắt bao nhiêu lần; sandbox quyết định mọi chuyện tệ tới đâu khi bạn duyệt nhầm một thứ không đọc kỹ.
"Hỏi tôi khi lỗi" không phải là một chế độ duyệt. Hành động đã chạy rồi. Bạn đang cấu hình một cái thông báo và gọi nó là lớp bảo vệ.
Học cho đúng phân biệt plugin/skill. Plugin là tầm với, skill là hành vi. Phần demo Linear chạy được — không hề gọi tên công cụ trong prompt — chính là vì có đủ cả hai.
Thứ gì bạn để trống, agent sẽ điền. Không yêu cầu định dạng, nên nó chọn markdown. Ở đây thì vô hại, và sẽ không phải lúc nào cũng vậy.
Đọc auto memory theo lịch. Đó là phần duy nhất trong hệ thống thay đổi kết quả của bạn mà không báo cho bạn biết.
Liên quan
- Google Antigravity 2.0: màn hình cài đặt mới là phần đáng đọc — cùng lập luận về agent chạy không người trông, từ một công cụ có bộ lập lịch và quyền shell.
- Claude Fable 5 trở lại: một demo có thể sai thật — một agent tự đối chiếu kết quả của chính nó, và con bug mà bước kiểm tra đó không phủ tới.
- Bộ não thứ hai tự bảo trì: Claude Fable 5 + Obsidian — một agent khác được trỏ vào thư mục local thật, giữ trung thực bằng một bản hợp đồng tường minh.
- Buổi 4 — Quản trị AI-Engineering — tự động hoá phần thực thi, giữ lại phần trách nhiệm.