0

Cách dùng Codex CLI tại Việt Nam không cần VPN: setup từ A đến Z

Có một kiểu mệt mà rất nhiều developer ở Việt Nam từng gặp khi thử AI coding tools lần đầu: web thì mở được, docs thì đọc được, nhưng đến lúc cần dùng CLI cho công việc thật thì lại bắt đầu vòng lặp quen thuộc — đổi mạng, bật VPN, đăng nhập lại, sửa key, rồi vẫn không chắc workflow có chạy ổn vào ngày mai hay không.

Nếu bạn chỉ muốn test vài lệnh cho biết thì có thể chịu được. Nhưng nếu bạn muốn đưa AI coding vào nhịp làm việc hằng ngày, kiểu setup như vậy rất nhanh chóng trở nên khó chịu.

Bài này không phải để nói rằng chỉ có một cách đúng. Mục tiêu của mình là chỉ ra một hướng setup thực tế hơn cho developer ở Việt Nam: ưu tiên một access path ổn định, giữ client flow càng quen càng tốt, và đừng bắt workflow phụ thuộc vào quá nhiều biến số như VPN, session hay billing path ngay từ đầu.

Vì sao nhiều người thấy Codex CLI “khó dùng hơn kỳ vọng”?

Khi mới nhìn vào Codex CLI, nhiều người thường nghĩ bài toán chỉ là cài tool rồi chạy.

Thực tế, cái khó không nằm ở một lệnh cài đặt. Nó nằm ở chỗ Codex CLI chỉ thật sự có ích khi bạn dùng nó trong workflow dài hơn, ví dụ:

  • đọc cấu trúc project
  • giải thích lỗi build
  • sửa một file cụ thể
  • tạo test cho một function
  • chạy lại nhiều vòng để kiểm tra kết quả

Lúc này, bất kỳ điểm yếu nào trong network path, session, access path hoặc workflow setup đều lộ ra rất nhanh.

Đó là lý do có người cảm thấy:

  • web vẫn dùng được
  • tài khoản nhìn như đã ổn
  • nhưng CLI lại timeout, fail ngắt quãng hoặc dùng không đủ yên tâm để đưa vào công việc thật

Sai lầm phổ biến nhất: nghĩ rằng vấn đề chỉ nằm ở VPN

VPN thường là thứ đầu tiên mọi người nghĩ đến.

Đúng là VPN có thể giúp ở một số bước ngắn hạn. Nhưng với workflow AI coding hằng ngày, phụ thuộc quá nhiều vào VPN thường tạo ra thêm một lớp mong manh nữa.

Bạn không chỉ phải lo:

  • model có trả lời không
  • key có đúng không
  • quota có ổn không

mà còn phải lo thêm:

  • session hôm nay có còn hợp lệ không
  • mạng hiện tại có làm đường đi thay đổi không
  • CLI có đang dùng đúng access path mình nghĩ hay không
  • một lỗi timeout có đến từ tool hay đến từ lớp mạng trung gian

Nếu mỗi lần mở terminal là mỗi lần phải nghĩ “hôm nay có cần VPN không?”, workflow đó rất khó trở thành thói quen làm việc.

Điều quan trọng hơn là giữ setup càng đơn giản càng tốt

Sau một thời gian thử nhiều cách, mình thấy câu hỏi hữu ích hơn không phải là:

“Làm sao để chạy được một lần?”

Mà là:

“Làm sao để ngày mai mở máy lên vẫn dùng được mà không phải debug lại từ đầu?”

Với Codex CLI, một hướng thực tế hơn cho nhiều developer ở Việt Nam là:

  1. Dùng một access path ngắn và ổn định
  2. Giữ cách gọi API/client flow càng quen càng tốt
  3. Test bằng request tối thiểu trước khi đẩy lên workflow dài
  4. Chỉ thêm độ phức tạp từng lớp một

Đó cũng là lý do mình ưu tiên những hướng tích hợp OpenAI-compatible: ít nhất bạn giữ được cấu trúc client quen thuộc, dễ thay base_urlapi_key, và đỡ phải đập lại toàn bộ cách gọi khi cần đổi workflow.

Setup từ A đến Z: cách mình làm để giảm ma sát

Phần này không nhằm mô tả “cấu hình duy nhất đúng”. Nó là một checklist thực dụng để Codex CLI hoặc workflow tương tự đỡ gãy hơn.

Bước 1: xác định mục tiêu thật sự của bạn

Trước khi cài gì thêm, hãy tự trả lời 3 câu:

  • Bạn chỉ muốn thử vài prompt hay muốn dùng hằng ngày?
  • Bạn cần xử lý tác vụ ngắn hay muốn làm refactor / test / debug dài hơi?
  • Bạn có chấp nhận workflow phụ thuộc vào nhiều workaround cùng lúc không?

Nếu câu trả lời là “muốn dùng hằng ngày”, thì ưu tiên lớn nhất không phải là hack cho chạy bằng được một lần. Ưu tiên là độ lặp lại và khả năng debug.

Bước 2: chuẩn bị một access path tối thiểu

Thay vì bắt đầu ngay với workflow CLI dài, mình luôn test bằng một request ngắn trước.

Ví dụ với OpenAI Python SDK:

from openai import OpenAI

client = OpenAI(
    base_url="https://allrouter.ai/v1",
    api_key="YOUR_API_KEY"
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "user", "content": "Reply with one short sentence for a Vietnam developer testing Codex-like CLI setup."}
    ]
)

print(resp.choices[0].message.content)

Nếu request tối thiểu còn chưa chạy ổn, bạn đã biết lỗi chưa chắc nằm ở CLI. Nó có thể nằm ở:

  • API key
  • access path
  • model availability
  • billing/quota
  • network stability

Bước 3: lưu biến môi trường rõ ràng

Một nguồn lỗi rất thường gặp là terminal hiện tại đang dùng key khác với thứ bạn tưởng.

Vì vậy, ít nhất hãy giữ một cách export rõ ràng:

export ALLROUTER_API_KEY="your_api_key_here"

Nếu tool hoặc script của bạn đọc biến khác, hãy thống nhất ngay từ đầu và đừng đổi lung tung giữa nhiều tên biến.

Mục tiêu ở bước này là: khi fail, bạn biết chính xác terminal đang dùng key nào.

Bước 4: test bằng curl trước khi gắn vào CLI workflow dài

Đây là cách nhanh nhất để biết access path cơ bản có còn sống hay không.

curl https://allrouter.ai/v1/chat/completions   -H "Content-Type: application/json"   -H "Authorization: Bearer $ALLROUTER_API_KEY"   -d '{
    "model": "gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Say hello from a stable CLI setup in Vietnam."}
    ]
  }'

Nếu curl ổn mà CLI dài lại fail, phạm vi vấn đề đã thu hẹp rất nhiều. Khi đó bạn nên nhìn vào:

  • workflow length
  • streaming behavior
  • tool assumption
  • timeout
  • số request liên tiếp

chứ không cần nghi ngờ toàn bộ access path từ đầu.

Bước 5: chỉ cho CLI làm việc nhỏ trước

Đừng bắt đầu bằng một task kiểu:

  • quét cả codebase
  • sửa nhiều file một lúc
  • phân tích lỗi build rất dài
  • chạy nhiều vòng agent liên tiếp

Tốt hơn là đi theo thứ tự:

  1. hỏi một câu ngắn
  2. yêu cầu giải thích một file nhỏ
  3. yêu cầu sửa một block code đơn lẻ
  4. rồi mới tăng dần độ dài workflow

Rất nhiều người nghĩ CLI “không ổn”, nhưng thực ra họ chỉ đang đưa quá nhiều độ phức tạp vào trước khi biết access path cơ bản có bền không.

Bước 6: đừng đổi quá nhiều biến số trong cùng một buổi debug

Một buổi test mà bạn vừa:

  • đổi mạng
  • bật hoặc tắt VPN
  • đổi key
  • đổi model
  • đổi tool
  • đổi prompt style

thì gần như không thể biết gốc lỗi đến từ đâu.

Nguyên tắc mình thấy hiệu quả nhất là: mỗi lần chỉ đổi một biến.

Nếu bạn đang cố biến Codex CLI thành công cụ dùng hằng ngày, việc debug có trật tự còn quan trọng hơn việc “chạy được một lần cho xong”.

Một cấu trúc thư mục tối thiểu để giữ workflow gọn

Nếu bạn muốn dùng CLI hoặc các script test lặp đi lặp lại, nên gom một bộ tối thiểu như sau:

project/
  scripts/
    test_access.py
    test_access.sh
  prompts/
    debug_prompt.txt
  notes/
    setup_notes.md

Ý tưởng không phải là làm cho phức tạp hơn, mà là để bạn:

  • dễ lặp lại bài test
  • dễ so sánh kết quả giữa các lần thử
  • dễ biết mình đã đổi biến gì
  • đỡ phải nhớ bằng đầu

Khi nào không cần VPN nữa?

Câu trả lời thực tế là: khi workflow của bạn không còn phụ thuộc vào nó để duy trì nhịp làm việc.

Mục tiêu không phải là chứng minh rằng VPN “vô dụng”. Mục tiêu là giảm bớt số lớp có thể làm workflow gãy.

Nếu bạn giữ được một access path ngắn, quen và dễ kiểm tra, bạn sẽ thấy ba thứ cải thiện rõ rệt:

  • ít phải debug ngược từ đầu
  • dễ thay đổi công cụ hơn
  • đỡ mất nhịp khi cần dùng thật trong lúc bận

Từ góc nhìn đó, điều đáng giá nhất không phải là có thêm một workaround, mà là bớt đi một nguồn bất ổn.

Những hiểu nhầm mình thấy lặp lại nhiều nhất

1. “Chạy được một lần” đồng nghĩa với “setup xong”

Không đúng.

Workflow AI coding chỉ thật sự ổn khi bạn có thể lặp lại nó vào ngày mai mà không phải mở lại cả vòng debug.

2. “Nếu web dùng được thì CLI cũng phải dùng được”

Không đúng.

CLI thường stream dài hơn, giữ kết nối lâu hơn và dễ lộ vấn đề hơn so với web request ngắn.

3. “Lỗi chắc chắn nằm ở tool”

Không hẳn.

Nhiều lỗi nhìn giống bug của tool, nhưng gốc lại nằm ở access path, quota, network stability hoặc session behavior.

Kết luận

Nếu bạn ở Việt Nam và muốn dùng Codex CLI theo cách thực sự hữu ích, hãy tối ưu cho sự ổn định chứ không chỉ cho cảm giác “vừa chạy được”.

Một setup tốt thường có các đặc điểm này:

  • access path ngắn và dễ kiểm tra
  • key/base URL rõ ràng
  • test tối thiểu chạy ổn
  • workflow được tăng độ phức tạp từng bước
  • ít phụ thuộc vào workaround như VPN hơn trước

Sau một thời gian thử nhiều cách, mình thấy điều đáng giữ lại nhất là một luồng tích hợp đơn giản và đủ quen để không phải đập đi làm lại mỗi khi đổi model hoặc đổi công cụ. Gần đây mình ưu tiên test theo hướng OpenAI-compatible với allrouter.ai vì nó giúp mình giữ client flow gọn hơn và bớt lệ thuộc vào nhiều lớp workaround cùng lúc.


Tags gợi ý: ai, cli, codex, workflow, developer, api, vietnam


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí