Cài Codex CLI trên Windows

Một hướng dẫn tích hợp API nên giúp người đọc biết cách kiểm tra giả thuyết khi có lỗi. Nếu chỉ đưa cấu hình cuối cùng, người mới sẽ không biết phải làm gì khi kết quả trên máy mình khác ví dụ.

Bài này thực hành kết nối Codex CLI với Crazyrouter trên Windows theo cách đó. Ta chuẩn bị công cụ, xác định dữ liệu đầu vào của kết nối, thử một yêu cầu nhỏ rồi mới cho CLI tạo tệp. Mỗi phép kiểm tra có phạm vi rõ ràng: nó xác nhận điều gì, cần dữ liệu nào và còn để ngỏ điều gì.

Kết quả cuối là một trang HTML lọc danh sách chủ đề. Đây là bài tập cục bộ, không phải ứng dụng kiểm tra tình trạng API. Các điều kiện thành công cần được xác nhận bằng tài khoản và đầu ra thực tế của bạn; không có model ID hay API Key dùng chung để sao chép nguyên trạng.

1. Vẽ ranh giới của lỗi trước khi chạy lệnh

Ta có thể chia đường đi của tác vụ thành bốn ranh giới. Windows tìm chương trình; chương trình đọc cấu hình và biến môi trường; dịch vụ tiếp nhận yêu cầu; công cụ ghi kết quả vào dự án. Một lỗi ở ranh giới sau không làm mất hiệu lực của các quan sát đã có ở ranh giới trước.

Ranh giới	Ví dụ triệu chứng	Dữ liệu giúp chẩn đoán
Hệ điều hành → chương trình	Không nhận lệnh	Vị trí cài, PATH, tên launcher
Chương trình → cấu hình	Thiếu biến hoặc lỗi TOML	Đường dẫn tệp, tên trường, phiên đang mở
Yêu cầu → dịch vụ	HTTP từ chối hoặc không có đầu ra	Endpoint, model ID, phản hồi đã che bí mật
Công cụ → hệ thống tệp	Có câu trả lời nhưng không có tệp	Thư mục hiện tại, quyền ghi, yêu cầu lưu

Ví dụ, thông báo node không tồn tại xuất hiện trước khi có bất kỳ request mô hình nào. Thử một API Key khác không kiểm tra đúng giả thuyết trong trường hợp này. Ngược lại, khi chương trình khởi chạy bình thường và nhận 401, cài lại Node.js cũng không xác minh được khóa đang gửi.

CLI là giao diện dòng lệnh; provider là bộ thông tin nối client với API. Trong bài, Codex CLI là client và Crazyrouter là dịch vụ được cấu hình. Nắm được hai vai trò này đã đủ để theo dõi phần còn lại, chưa cần tìm hiểu kiến trúc của mọi coding agent.

Chuẩn bị một nơi ghi lại câu hỏi, thao tác và kết quả. Ghi “chưa kiểm tra” cũng là thông tin có giá trị. Không ghi trước một kết quả thành công chỉ vì đó là kết quả hướng dẫn mong đợi.

2. Hoàn tất điều kiện tiên quyết trên Windows

Trước hết phải có một shell nhập được lệnh và các chương trình cục bộ. Phần dưới dành cả cho người chưa từng dùng terminal: cách nhận biết prompt, chọn bộ cài và kiểm tra chương trình sau khi cài.

Làm quen với cách nhập lệnh trong PowerShell

Mở đúng cửa sổ

Tìm PowerShell trong Start. Nếu dùng Windows Terminal, hãy chọn tab PowerShell. Bắt đầu với cửa sổ người dùng thông thường; chỉ xem xét quyền bổ sung khi một bước cài đặt hoặc sandbox cụ thể yêu cầu và đã giải thích lý do.

Dòng như PS C:\Users\...> là dấu nhắc. Phần đường dẫn cho biết vị trí đang làm việc, còn ký tự > cho biết chương trình sẵn sàng nhận lệnh. Không sao chép cả dấu nhắc vào ô nhập. Trong các khối lệnh của bài, chỉ sao chép nội dung bên trong khối.

Lệnh đơn và khối nhiều dòng không giống nhau

Với các lệnh kiểm tra phiên bản, chạy từng dòng rồi đọc kết quả. Dán hai lệnh dính liền nhau sẽ tạo thành một chuỗi không hợp lệ. Ngược lại, một khối có if, dấu ngoặc nhọn hoặc bảng băm phải được sao chép đầy đủ, vì các dòng phụ thuộc nhau.

Bạn có thể thử Ctrl + V, nhấp chuột phải hoặc Ctrl + Shift + V tùy terminal. Nếu thấy dấu nhắc chuyển thành >>, PowerShell thường đang chờ phần còn lại của câu lệnh, chẳng hạn dấu nháy đóng. Nhấn Ctrl + C, kiểm tra lại khối rồi nhập lại; không cần khởi động lại Windows.

Vì sao các lệnh có đuôi .cmd?

Trên Windows, gói npm có thể tạo nhiều tệp khởi chạy. PowerShell đôi khi chọn bản .ps1 và chính sách thực thi chặn tệp đó. Bài này ghi rõ npm.cmd và codex.cmd để lựa chọn tệp khởi chạy tương ứng, tránh biến việc học công cụ thành bài chỉnh chính sách toàn hệ thống.

Nếu máy do công ty hoặc trường quản lý, vẫn cần tuân theo chính sách của đơn vị. Không dùng việc đổi tên lệnh để suy luận rằng mọi hạn chế quản trị đã được loại bỏ.

Một điểm dễ nhầm về sau: khi giao diện Codex đã mở, văn bản bạn gõ là đầu vào cho Codex. Muốn chạy lệnh PowerShell kiểm tra tệp, trước hết hãy thoát giao diện đó và quay lại dấu nhắc của shell.

Chuẩn bị Node.js và npm

Kiểm tra trước khi cài

node --version
npm.cmd --version

Nếu cả hai lệnh trả về phiên bản, hãy giữ môi trường hiện tại và chuyển sang phần tiếp theo. Môi trường chuẩn bị tài liệu từng ghi nhận Node.js v24.21.0, npm 11.19.0; các số này giúp mô tả bối cảnh, không yêu cầu bạn tìm đúng một bản cũ để giống ảnh.

Nếu báo không tìm thấy node, có hai hướng cần xét: chưa cài đặt hoặc terminal chưa nhận PATH mới. Đây là lỗi tìm chương trình trên máy, chưa liên quan tới model hay khóa API.

Ảnh dùng giao diện tiếng Trung; ý cần nhận biết là lệnh chưa được Windows tìm thấy. Không cần khớp từng chữ với ngôn ngữ trên máy của bạn.

Chọn bộ cài dành cho Windows

Mở trang tải Node.js. Chọn nhánh LTS, hệ điều hành Windows và kiến trúc phù hợp. Có thể xem loại hệ thống ở Settings → System → About để phân biệt x64 và ARM64.

Với cách làm ở đây, chọn bộ cài .msi. Trang tải có thể hiển thị cả hướng dẫn Docker; đó là một cách triển khai khác, không phải bước bắt buộc trước khi dùng npm trên Windows. Không cần tải mã nguồn để tự biên dịch.

Trong trình cài đặt, giữ các thành phần npm và tích hợp PATH. Gói công cụ biên dịch native là một nhu cầu khác; không cần chủ động thêm toàn bộ bộ công cụ chỉ để làm bài HTML này. Ghi nhớ thư mục cài đặt nếu bạn chọn khác mặc định, vì thông tin đó có ích khi tìm lỗi đường dẫn.

Mở terminal mới để kiểm tra lại

Đóng cửa sổ PowerShell cũ và mở cửa sổ mới. Nếu terminal nằm trong một trình soạn thảo đã mở từ trước, có thể cần khởi động lại trình soạn thảo để tiến trình mới nhận môi trường đã cập nhật.

Ảnh minh họa kết quả kiểm tra Node.js. Sau đó vẫn phải kiểm tra npm riêng; ảnh không thể xác nhận kết nối tới dịch vụ mô hình.

Chạy lại hai lệnh ở đầu phần này. Chỉ chuyển tiếp khi cả Node.js và npm được gọi thành công. Nếu chỉ Node.js hoạt động, hãy xem thành phần npm trong bộ cài và vị trí khởi chạy thay vì sửa cấu hình API chưa được sử dụng.

Cài CLI và xác nhận Windows gọi đúng chương trình

Cài đặt toàn cục bằng npm

npm.cmd install -g @openai/codex@latest

codex.cmd --version
codex.cmd --help

-g đặt gói vào vị trí công cụ dùng chung của npm, để bạn có thể gọi CLI từ các thư mục dự án khác nhau. Nó không có nghĩa là Codex được quyền sửa mọi thư mục trên máy. Quyền làm việc với tệp sẽ được xem ở phần sandbox.

Lệnh cài có thể in cảnh báo, tiến độ hoặc thông báo cập nhật npm. Đọc phần kết thúc và lỗi thực tế, không chỉ nhìn màu chữ. Hai lệnh sau dùng để kiểm tra xem chương trình có chạy và tự hiển thị trợ giúp hay không; chúng không thay cho phép thử tài khoản API.

Lúc chuẩn bị bài, CLI được ghi nhận ở phiên bản 0.158.0. Nếu bản hiện tại của bạn khác, một số menu và lựa chọn có thể thay đổi. Ghi lại phiên bản đang chạy để tra đúng tài liệu, thay vì cố tái tạo từng dòng trong một ảnh cũ.

Nếu cài xong nhưng chưa gọi được

Get-Command codex.cmd -ErrorAction SilentlyContinue
npm.cmd config get prefix

Lệnh đầu hỏi Windows tìm thấy codex.cmd ở đâu. Lệnh sau cho biết prefix toàn cục của npm. Hai thông tin này giúp phân biệt “gói chưa cài thành công” với “đã có tệp nhưng shell chưa tìm thấy”.

Trước hết mở terminal mới. Nếu vẫn lỗi, đối chiếu đường dẫn thực tế và PATH. Không thêm hàng loạt thư mục đoán được vào PATH, cũng không cần cài lặp lại nhiều lần khi chưa xác định lần trước thất bại ở đâu.

Nếu máy có nhiều cách cài Codex, hãy chú ý bản nào được gọi. Một lệnh cập nhật thành công ở vị trí A không đảm bảo terminal đang chạy bản A. Phần xử lý lỗi cuối bài có lệnh liệt kê các tệp khởi chạy để kiểm tra tình huống này.

Đến đây có thể kết luận công cụ cục bộ đã sẵn sàng khi phiên bản và trợ giúp hoạt động. Chưa nên kết luận rằng mô hình có quyền truy cập hoặc HTML đã được tạo.

Đến đây, câu hỏi cần trả lời chỉ là Windows có chạy được CLI không. Giữ lại phiên bản thực tế trên máy để tra tài liệu đúng ngữ cảnh. Các phiên bản được dùng khi chuẩn bị tài liệu không phải lời bảo đảm về tài khoản API của người đọc.

3. Giữ môi trường thử nghiệm nhỏ và ổn định

$projectDir = Join-Path $env:USERPROFILE 'CodexProjects\crazyrouter-demo'
New-Item -ItemType Directory -Path $projectDir -Force | Out-Null
Set-Location -LiteralPath $projectDir
Get-Location

Đọc kết quả Get-Location thay vì chỉ chờ lệnh kết thúc. Đường dẫn này là nơi ta sẽ kiểm tra tệp cuối cùng. Nếu vị trí khác dự kiến, sửa ngay để tránh chẩn đoán nhầm “không tạo được tệp” khi tệp thực ra nằm ở nơi khác.

$projectDir là biến của phiên PowerShell. Giữ cửa sổ hiện tại mở trong các bước tiếp theo. Đổi cửa sổ có thể làm mất những giá trị tạm thời, tạo ra một khác biệt không liên quan đến dịch vụ.

Thư mục đã tồn tại không bị xóa bởi khối trên. Kiểm tra nội dung cũ, đặc biệt là index.html, trước khi cho phép ghi. Trong một phép thử, dùng nhầm tệp còn lại từ lần trước sẽ khiến kết luận sai ngay cả khi thao tác kiểm tra đúng.

Tạm thời không dùng dự án công ty hoặc dữ liệu cá nhân làm đầu vào. Một thư mục nhỏ giúp bạn biết chính xác công cụ đã tạo và sửa gì. Việc giới hạn dữ liệu cũng làm cho một mô tả lỗi dễ chia sẻ hơn, vì không cần công khai cả dự án để người khác hiểu tình huống.

Nếu điều chỉnh kết nối, hãy thay từng yếu tố: địa chỉ, khóa hoặc mô hình. Sau mỗi thay đổi, chạy lại cùng phép thử. Khi nhiều yếu tố đổi cùng lúc, không thể chỉ từ kết quả sau đó suy ra thay đổi nào là nguyên nhân.

4. Xác định nguồn của ba đầu vào kết nối

Một request cần đích đến, quyền truy cập và đối tượng mô hình. Ta thu thập chúng trước khi sửa client.

Đầu vào	Nguồn lấy trong bài	Cách tránh nhầm
Base URL	Cấu hình API của dịch vụ	Không dùng trang chủ hoặc URL tài liệu
API Key	Token do tài khoản của bạn phát hành	Không lấy từ ảnh hay tài khoản khác
Model ID	Kết quả danh sách của tài khoản	Giữ nguyên định danh, không đoán theo tên thương mại

Tạo Key trong tài khoản Crazyrouter được phép sử dụng. Có thể đối chiếu tài liệu khởi đầu để tìm phần quản lý token. Đăng nhập ChatGPT hay có gói đăng ký của một dịch vụ khác không tạo thay quyền này.

$crazySecret = Read-Host 'Crazyrouter API Key' -AsSecureString
$env:CRAZYROUTER_API_KEY = [System.Net.NetworkCredential]::new('', $crazySecret).Password
$crazySecret.Dispose()
Remove-Variable crazySecret
[bool]$env:CRAZYROUTER_API_KEY

Khi nhập, khóa không xuất hiện như văn bản thông thường trên màn hình. True ở cuối chỉ xác nhận một giá trị đã nằm trong môi trường tiến trình. Câu hỏi “khóa có được dịch vụ chấp nhận không” chưa được trả lời.

$crazyBase = 'https://api.crazyrouter.com/v1'
$crazyHeaders = @{ Authorization = "Bearer $env:CRAZYROUTER_API_KEY" }
$crazyModels = Invoke-RestMethod -Method Get -Uri "$crazyBase/models" -Headers $crazyHeaders
$crazyModels.data | Select-Object -ExpandProperty id

$crazyModel = Read-Host 'Model ID'

Chọn một ID có quyền dùng và phù hợp với luồng Codex qua Responses, rồi nhập đầy đủ tại Model ID. Các mô hình khác loại tác vụ có thể xuất hiện trong cùng danh sách nhưng không phù hợp cho bài thực hành này.

Ở bước này, kết luận tối đa là đã đọc được catalog và chọn một ứng viên cần kiểm tra. Chưa có lý do kết luận nó hoàn thành được công việc của agent. Nếu catalog lỗi, lưu triệu chứng và xử lý thay vì bỏ qua bằng một ID đoán được.

Biến header chứa giá trị Key lúc được tạo. Nếu nhập khóa mới giữa chừng, chạy lại phần tạo $crazyHeaders. Đây là một phụ thuộc dữ liệu trong PowerShell; sửa biến môi trường không tự cập nhật mọi đối tượng đã tạo trước đó.

5. Biến thông tin kết nối thành cấu hình có thể đọc được

$codexConfigDir = if ($env:CODEX_HOME) { $env:CODEX_HOME } else { Join-Path $env:USERPROFILE '.codex' }
New-Item -ItemType Directory -Path $codexConfigDir -Force | Out-Null
$codexConfigFile = Join-Path $codexConfigDir 'config.toml'
if (Test-Path -LiteralPath $codexConfigFile) {
    $backupFile = $codexConfigFile + '.' + (Get-Date -Format 'yyyyMMdd-HHmmss') + '.bak'
    Copy-Item -LiteralPath $codexConfigFile -Destination $backupFile
}
notepad.exe $codexConfigFile

Vị trí được chọn dựa trên CODEX_HOME hoặc thư mục .codex mặc định của người dùng. Tạo bản sao trước khi sửa giúp so sánh nguyên nhân nếu hành vi thay đổi. Đây là cấu hình ở cấp người dùng, không phải cứ tạo tệp cùng tên trong dự án là áp dụng được mọi trường xác thực.

model = "MODEL_ID_FROM_YOUR_ACCOUNT"
model_provider = "crazyrouter"

[model_providers.crazyrouter]
name = "Crazyrouter"
base_url = "https://api.crazyrouter.com/v1"
env_key = "CRAZYROUTER_API_KEY"
wire_api = "responses"
requires_openai_auth = false

Đổi MODEL_ID_FROM_YOUR_ACCOUNT sang ID đã chọn. Không để nguyên chuỗi hướng dẫn rồi coi lỗi “không có mô hình” là sự cố dịch vụ. Đồng thời so sánh với $crazyModel trong PowerShell vì hai giá trị được đặt riêng.

Đọc cấu hình theo các liên kết: model_provider chọn bảng crazyrouter; bảng đó cung cấp địa chỉ; env_key gọi đúng tên biến chứa khóa. name chỉ là nhãn hiển thị, nên thay nhãn không thay được đích request.

Với đường xác thực này, requires_openai_auth là false. Nếu đặt true, Codex dùng xác thực OpenAI và bỏ qua env_key. Vì vậy, ghép nửa cấu hình đăng nhập chính thức với nửa cấu hình provider riêng có thể cho ra kết quả khác hẳn ý định.

Hai trường đầu đặt trước các tiêu đề bảng có dấu ngoặc vuông để nằm ở cấp cao nhất. Không khai báo lại cùng khóa hoặc cùng bảng. Nếu đang có cấu hình, sửa phần tương ứng và giữ những tùy chọn không liên quan.

Kiểm tra tên tệp thật là config.toml. Notepad có thể khiến người mới lưu nhầm thành .toml.txt. Địa chỉ API không có UTM; base chứa /v1 một lần và chưa gắn endpoint cuối. Đóng phiên Codex cũ sau khi lưu để phép thử sau đọc cấu hình mới.

6. Kiểm tra giả thuyết: API có tạo được một đầu ra ngắn không?

Phép thử này dùng các biến đã chuẩn bị và thực sự gọi tài khoản. Có thể phát sinh sử dụng theo điều kiện dịch vụ:

$crazyPayload = @{
    model = $crazyModel
    input = 'Reply with OK.'
    stream = $false
} | ConvertTo-Json -Depth 6

$crazyResponse = Invoke-RestMethod -Method Post -Uri "$crazyBase/responses" -Headers $crazyHeaders -ContentType 'application/json' -Body $crazyPayload
$crazyResponse | Select-Object id, status, error
$crazyResponse.output | ConvertTo-Json -Depth 8

Ta chọn đầu vào ngắn vì muốn giảm số yếu tố tham gia. Model ID lấy từ $crazyModel; đường gọi là /v1/responses; phản hồi không dùng streaming để dễ xem trong terminal.

Hãy quan sát cả id, status, error và output. Một mã HTTP thông thường chỉ nói về một phần giao tiếp. Nếu kết quả có lỗi nghiệp vụ hoặc không có nội dung cần thiết, giả thuyết chưa được xác nhận.

Nếu cấu trúc phản hồi khác tài liệu bạn đang đọc, ghi nhận dữ liệu thực và tìm cách diễn giải phù hợp. Không tự điền trạng thái hay response ID minh họa vào nhật ký thật. Khi cần trao đổi với dịch vụ, định danh phản hồi và thời gian gọi thường có ích; khóa trong header thì không được công khai.

Kết quả phép thử	Bước kế tiếp hợp lý
Không có biến cần thiết	Quay lại cửa sổ và khối chuẩn bị
Bị từ chối xác thực	So nguồn khóa với đích gửi và thông báo lỗi
Có catalog nhưng mô hình không tạo được	Kiểm tra quyền và khả năng của mô hình
Có trạng thái kết thúc hợp lệ cùng nội dung	Tiếp tục kiểm tra client

Không có phép thử đơn lẻ nào ở đây chứng minh toàn bộ khả năng của Codex. Responses không streaming là một phạm vi; streaming, công cụ và thao tác dự án là các phạm vi tiếp theo. Tương thích với Chat Completions cũng không tự chứng minh các phạm vi đó.

7. Kiểm tra giả thuyết: client đang dùng đúng cấu hình không?

Set-Location -LiteralPath $projectDir
codex.cmd

Trong Codex, yêu cầu một câu giải thích HTML bằng tiếng Việt, không dùng công cụ và không đọc tệp. Xem thông tin mô hình, provider mà phiên bản hiện tại cung cấp. Đây là phép thử cho đường gọi của client, khác với biến dùng trực tiếp trong PowerShell.

Nếu request trực tiếp bình thường còn CLI lỗi, đừng bỏ bằng chứng trước đó. So sánh model ID, base URL, đường dẫn cấu hình và cửa sổ khởi chạy. Phiên mở trước khi chỉnh tệp có thể chưa dùng lựa chọn mới.

Ảnh dùng tiếng Trung; hãy đọc mục tương ứng trên phiên bản của bạn. Vị trí lựa chọn và tên model trong ảnh không xác nhận kết quả API.

Khi hỏi về tin cậy thư mục, đối chiếu với đường dẫn đã chuẩn bị. Các câu hỏi sandbox thuộc quyền thao tác máy, không phải nguồn Key. Một API đã trả lời vẫn có thể đi kèm quyền ghi bị từ chối.

Đừng tắt toàn bộ bảo vệ để làm cho kiểm tra “dễ hơn”. Hãy xác định thao tác cụ thể cần cho bài: lưu một tệp trong thư mục này. Với máy được quản lý, những bước yêu cầu quyền bổ sung phải theo chính sách thiết bị.

Nếu công cụ đề nghị lệnh bạn chưa hiểu, hỏi đối tượng bị đọc hoặc sửa và lý do của lệnh. Giữ hành vi có thể giải thích là một phần của việc kiểm tra client, không chỉ là chuyện bảo mật ở cuối bài.

8. Đặt một tác vụ có cả trường hợp tìm thấy và không tìm thấy

Tạo duy nhất index.html trong thư mục thực hành, dùng tiếng Việt.
Trang có tiêu đề “Góc học lập trình” và danh sách ba mục: HTML, CSS, JavaScript.
Thêm ô nhập có nhãn “Tìm chủ đề”. Khi nhập, lọc theo nội dung chứa chuỗi đó, không phân biệt hoa thường.
Ô trống hiển thị đủ ba mục. Không có mục phù hợp thì hiện “Chưa có chủ đề này”.
Không tải dữ liệu từ API; đây chỉ là danh sách cục bộ trong tệp.
Đặt CSS và JavaScript trong HTML, không cài gói và không dùng tài nguyên mạng.
Không sửa tệp khác. Báo vị trí đã lưu hoặc lý do không thể ghi.

Danh sách lọc cho ta nhiều kết quả kiểm tra hơn một nút chỉ thay văn bản: trạng thái rỗng, từ khóa có kết quả, khác biệt chữ hoa và trường hợp không có mục nào. Tuy vậy, nó vẫn nhỏ để người mới kiểm tra thủ công mà không cần môi trường build.

Tên chủ đề là dữ liệu tĩnh. Trang này không dùng API để tìm kiếm, nên không được hiểu một lần lọc thành công là bằng chứng kết nối đến Crazyrouter. Việc kết nối đã có phép thử riêng; ở đây ta kiểm tra phần việc ghi và tạo hành vi giao diện.

Đọc đề nghị lưu tệp trước khi cho phép. Nếu công cụ muốn thêm nhiều tệp hoặc cài framework, nhắc lại phạm vi một HTML. Điều đó giữ thí nghiệm tập trung vào điều ta đã định nghĩa.

9. Đối chiếu tệp thật với bảng trường hợp kiểm tra

Thoát Codex bằng /quit hoặc chức năng tương ứng. Khi thấy lại prompt PowerShell, kiểm tra rồi mở tệp nếu nhận True:

Test-Path .\index.html

Start-Process .\index.html

Sau đó làm lần lượt:

Đầu vào trong ô tìm	Kết quả cần thấy
Để trống	HTML, CSS, JavaScript
html	HTML
SCRIPT	JavaScript
python	Thông báo không có mục phù hợp
Xóa nội dung sau lần trên	Cả ba mục trở lại

Bảng này là kỳ vọng của bài tập, không phải log chạy có sẵn. Bạn cần tự nhập và quan sát. Đặc biệt, kiểm tra xóa từ khóa sau trạng thái không tìm thấy giúp phát hiện giao diện không phục hồi danh sách.

Nếu có lỗi, cung cấp chuỗi đã nhập, mục đang hiện và mục đáng lẽ phải hiện. Yêu cầu sửa đúng index.html, rồi lặp lại các trường hợp. Điều này biến một nhận xét chung thành một mô tả có thể tái hiện.

Kiểm tra cả đường dẫn trên trình duyệt. Với hai bản trùng tên, có thể đang xem bản cũ. Làm mới sau mỗi lần lưu; đừng xem một trang chưa cập nhật rồi kết luận công cụ bỏ qua yêu cầu.

Tệp tồn tại chỉ vượt qua kiểm tra lưu. Tệp mở được vượt thêm kiểm tra hiển thị. Các trường hợp trong bảng mới kiểm tra được chức năng đã yêu cầu. Giữ ba kết luận riêng thay vì gom thành một chữ “xong”.

10. FAQ: từ thông báo lỗi đến câu hỏi đúng

Có cần mở PowerShell bằng quyền quản trị ngay từ đầu?

Không dùng quyền cao cho mọi thao tác theo thói quen. Bắt đầu bằng cửa sổ thông thường và đọc yêu cầu cụ thể khi bộ cài hoặc sandbox cần quyền. Máy tổ chức vẫn chịu quy định của tổ chức.

Bị chặn file .ps1 có nghĩa gói bị hỏng?

Chưa thể kết luận. Hãy gọi launcher .cmd như hướng dẫn, xem có chạy không. Lựa chọn launcher và chính sách script khác với trạng thái cài đặt của gói.

Cài đặt timeout thì kiểm tra ở đâu?

npm.cmd config get registry

Đọc nguồn tải và lỗi thật. Không tùy tiện thay registry nội bộ hoặc bỏ xác minh chứng chỉ. Đây là đường tải package, chưa phải request của mô hình.

Có giá trị Key nhưng vẫn 401?

[bool]$env:CRAZYROUTER_API_KEY

Kết quả Boolean chỉ chứng minh biến không rỗng. Hãy kiểm tra nguồn phát hành, hiệu lực, đích gửi và header có được tạo lại sau khi đổi khóa không. Không in nguyên khóa để hỏi cộng đồng.

403 có cách sửa chung bằng cấu hình không?

Không có một thay đổi bảo đảm cho mọi nguyên nhân. Quyền tài khoản, chính sách hoặc phạm vi cung cấp cần đọc từ phản hồi. URL sai là một khả năng khác và phải được xác định trước khi sửa.

Khi nào nên xem lại model ID thay vì cài lại?

Khi request đã đến dịch vụ nhưng báo không tìm thấy mô hình hoặc chọn sai đối tượng, đối chiếu catalog và hai nơi lưu ID. Lỗi TOML thì đọc cấu trúc tệp. Cài lại Node không sửa các dữ liệu này.

Cập nhật CLI rồi sao vẫn thấy phiên bản cũ?

npm.cmd install -g @openai/codex@latest
codex.cmd --version
Get-Command codex* -All

Các vị trí do lệnh cuối trả về giúp tìm bản đang được ưu tiên. Kiểm tra nguồn cài trước khi gỡ. Không cần cài lại cho mỗi dự án mới.

Lệnh đường dẫn từ CMD có dùng được không?

Không trộn cú pháp. Trong PowerShell, dùng $env:USERPROFILE và Set-Location; %USERPROFILE% cùng cd /d thuộc cách viết CMD. Giữ dấu nháy của đường dẫn có khoảng trắng và không sao chép cả prompt.

11. Viết kết luận đúng với phạm vi đã thử

Khi hoàn thành, ghi các quan sát theo trình tự phụ thuộc: chương trình chạy được; catalog đọc được; yêu cầu tạo nội dung có kết quả; CLI dùng cấu hình dự định; tệp được lưu; các trường hợp lọc được kiểm tra. Mục chưa làm vẫn để chưa làm.

Nếu cần nhờ hỗ trợ, cung cấp phần nhỏ nhất đủ tái hiện: phiên bản, endpoint, model ID, đầu vào ngắn, trạng thái và lỗi đã loại bỏ bí mật. Không phải lúc nào người hỗ trợ cũng cần mã nguồn riêng tư hoặc toàn bộ thư mục cấu hình.

Khi thay model hoặc endpoint, lặp lại phép thử phù hợp. Đừng giữ nguyên kết luận của cấu hình cũ cho cấu hình mới. Muốn quay lại, đóng phiên và dùng bản sao để phục hồi các trường đã sửa, không xóa toàn bộ lịch sử hay thông tin đăng nhập một cách tùy tiện.

Giá trị của cách làm này là mỗi lần thử đều kiểm tra một câu hỏi cụ thể. Crazyrouter được sử dụng như một trường hợp tích hợp có địa chỉ, xác thực và lựa chọn mô hình rõ ràng. Bài học kỹ thuật nằm ở việc tìm đúng ranh giới cần kiểm tra, không ở một lời khẳng định chung về mọi tài khoản của dịch vụ.

Các tùy chọn phụ thuộc phiên bản có thể đối chiếu tại tài liệu Codex.